[opensuse] firewall/iptables suggestion for preventing brute-force SIP attempts?
Our asterisk server is seeing numerous brute force attempts to get access to a SIP account. I've tried setting up a 'prevent flood' config with iptables, but wihtout much success. fail2ban et al does not work, so I was hoping someone might have a hint wrt an iptables setup to stop such brute force attacks? thanks Per -- Per Jessen, Zürich (4.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2013 10:47 AM, Per Jessen wrote:
Our asterisk server is seeing numerous brute force attempts to get access to a SIP account. I've tried setting up a 'prevent flood' config with iptables, but wihtout much success. fail2ban et al does not work, so I was hoping someone might have a hint wrt an iptables setup to stop such brute force attacks?
Well not the answer you are looking for, but don't find yourself alone in this game, as my server is also under brute force attack, and no till now I have not been able to find any solution also, I have tried all the approaches you have tried but no success. I can't find a way to block as most of these attacks are logged as below where XXX is my servers own address, hence fail2ban unfortunately fails , or I can't find a better way to get the attackers' ip address. 100000<sip:100000@XXX.XXX.XXX.XX>;tag=eb6db4c6 So if you find a solution please share, as this issue is nerving me for a long time now Togan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 04, 2013 at 11:18:09AM +0200, Togan Muftuoglu wrote:
On 04/04/2013 10:47 AM, Per Jessen wrote:
Our asterisk server is seeing numerous brute force attempts to get access to a SIP account. I've tried setting up a 'prevent flood' config with iptables, but wihtout much success. fail2ban et al does not work, so I was hoping someone might have a hint wrt an iptables setup to stop such brute force attacks?
Well not the answer you are looking for, but don't find yourself alone in this game, as my server is also under brute force attack, and no till now I have not been able to find any solution also, I have tried all the approaches you have tried but no success. I can't find a way to block as most of these attacks are logged as below where XXX is my servers own address, hence fail2ban unfortunately fails , or I can't find a better way to get the attackers' ip address.
100000<sip:100000@XXX.XXX.XXX.XX>;tag=eb6db4c6
So if you find a solution please share, as this issue is nerving me for a long time now
Is this always the same TCP/UDP port? Then add a filter like the ssh "recent" filtering? remove it from the generic FW_SERVICES_EXT_TCP line, and add to the FW_SERVICES_ACCEPT_EXT line: something like the ssh example: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2013 01:19 PM, Marcus Meissner wrote:
remove it from the generic FW_SERVICES_EXT_TCP line, and add to the FW_SERVICES_ACCEPT_EXT line: something like the ssh example: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Been there already does not work and of course EXT_UDP is not including 5060 :( FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh 0/0,udp,5060,,hitcount=3,blockseconds=180,recentname=voip" Togan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Togan Muftuoglu wrote:
On 04/04/2013 01:19 PM, Marcus Meissner wrote:
remove it from the generic FW_SERVICES_EXT_TCP line, and add to the FW_SERVICES_ACCEPT_EXT line: something like the ssh example:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Been there already does not work and of course EXT_UDP is not including 5060 :(
Hi Togan do you remember why it doesn't work? It's been a while since I disabled my attempts, I can't remember why it didn't work. -- Per Jessen, Zürich (7.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Been there already does not work and of course EXT_UDP is not including 5060 :(
Hi Togan
do you remember why it doesn't work? It's been a while since I disabled my attempts, I can't remember why it didn't work.
Can't remember it either, it has been a while but it is not the case that the rule does not catch because it does Apr 4 06:26:11 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=773 TOS=0x00 PREC=0x00 TTL=120 ID=1888 PROTO=UDP SPT=5078 DPT=5060 LEN=753 Apr 4 06:26:12 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=778 TOS=0x00 PREC=0x00 TTL=120 ID=1963 PROTO=UDP SPT=5073 DPT=5060 LEN=758 Apr 4 06:26:26 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=781 TOS=0x00 PREC=0x00 TTL=120 ID=2836 PROTO=UDP SPT=5070 DPT=5060 LEN=761 Apr 4 06:26:32 whale kernel: SFW2-INext-DROPr IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=784 TOS=0x00 PREC=0x00 TTL=120 ID=3157 PROTO=UDP SPT=5071 DPT=5060 LEN=764 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 04, 2013 at 02:10:58PM +0200, Togan Muftuoglu wrote:
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Been there already does not work and of course EXT_UDP is not including 5060 :(
Hi Togan
do you remember why it doesn't work? It's been a while since I disabled my attempts, I can't remember why it didn't work.
Can't remember it either, it has been a while but it is not the case that the rule does not catch because it does
Apr 4 06:26:11 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=773 TOS=0x00 PREC=0x00 TTL=120 ID=1888 PROTO=UDP SPT=5078 DPT=5060 LEN=753
Apr 4 06:26:12 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=778 TOS=0x00 PREC=0x00 TTL=120 ID=1963 PROTO=UDP SPT=5073 DPT=5060 LEN=758
Apr 4 06:26:26 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=781 TOS=0x00 PREC=0x00 TTL=120 ID=2836 PROTO=UDP SPT=5070 DPT=5060 LEN=761
Apr 4 06:26:32 whale kernel: SFW2-INext-DROPr IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=91.121.0.209 DST=XXX.XXX.XXX.XX LEN=784 TOS=0x00 PREC=0x00 TTL=120 ID=3157 PROTO=UDP SPT=5071 DPT=5060 LEN=764
There is the first drop... Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2013 02:19 PM, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 02:10:58PM +0200, Togan Muftuoglu wrote:
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote: There is the first drop...
I guess dropping was not the issue but keeping the dropped attacker for a long time in hold was the issue for me Togan PS. please keep replies to list only -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Togan Muftuoglu wrote:
On 04/04/2013 02:19 PM, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 02:10:58PM +0200, Togan Muftuoglu wrote:
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote: There is the first drop...
I guess dropping was not the issue but keeping the dropped attacker for a long time in hold was the issue for me
Togan
Here is what used to have: ## SIP flood protection $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --set $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SIP attack: ' $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j DROP I don't currently have any external SIP users, but I'm pretty certain the above also gave legitimate users a problem. I'm wondering if it is because the firewall needs to look into the SIP packet to be able to determine what it is. -- Per Jessen, Zürich (8.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2013 03:49 PM, Per Jessen wrote:
Here is what used to have:
## SIP flood protection $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --set $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SIP attack: ' $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j DROP
I don't currently have any external SIP users, but I'm pretty certain the above also gave legitimate users a problem. I'm wondering if it is because the firewall needs to look into the SIP packet to be able to determine what it is.
In addition I have FW_EXT_UDP=10000:20000 since my rtf.conf is rtpstart=10000 rtpend=20000 On the other hand today is (touch wood) relatively silent day Togan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Togan Muftuoglu wrote:
On 04/04/2013 03:49 PM, Per Jessen wrote:
Here is what used to have:
## SIP flood protection $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --set $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SIP attack: ' $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j DROP
I don't currently have any external SIP users, but I'm pretty certain the above also gave legitimate users a problem. I'm wondering if it is because the firewall needs to look into the SIP packet to be able to determine what it is.
In addition I have FW_EXT_UDP=10000:20000 since my rtf.conf is
rtpstart=10000 rtpend=20000
Yes, I also have those open # SIP traffic $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -j ACCEPT # these are STUN ports $IPTABLES -A INPUT -p udp --dport 3478:3479 -i $EXTERNALIF -j ACCEPT # IAX2 traffic $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 4569 -j ACCEPT # $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 10000:20000 -j ACCEPT /Per -- Per Jessen, Zürich (9.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 04, 2013 at 05:39:53PM +0200, Per Jessen wrote:
Togan Muftuoglu wrote:
On 04/04/2013 03:49 PM, Per Jessen wrote:
Here is what used to have:
## SIP flood protection $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --set $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SIP attack: ' $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j DROP
I don't currently have any external SIP users, but I'm pretty certain the above also gave legitimate users a problem. I'm wondering if it is because the firewall needs to look into the SIP packet to be able to determine what it is.
In addition I have FW_EXT_UDP=10000:20000 since my rtf.conf is
rtpstart=10000 rtpend=20000
Yes, I also have those open
# SIP traffic $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -j ACCEPT
Well if you do this, they are of course not hitting the RECENT matcher. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 05:39:53PM +0200, Per Jessen wrote:
Togan Muftuoglu wrote:
On 04/04/2013 03:49 PM, Per Jessen wrote:
Here is what used to have:
## SIP flood protection $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --set $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SIP attack: ' $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j DROP
I don't currently have any external SIP users, but I'm pretty certain the above also gave legitimate users a problem. I'm wondering if it is because the firewall needs to look into the SIP packet to be able to determine what it is.
In addition I have FW_EXT_UDP=10000:20000 since my rtf.conf is
rtpstart=10000 rtpend=20000
Yes, I also have those open
# SIP traffic $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -j ACCEPT
Well if you do this, they are of course not hitting the RECENT matcher.
No, my SIP flood protect rules are placed before that accept-rule. -- Per Jessen, Zürich (8.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Togan Muftuoglu wrote:
On 04/04/2013 02:19 PM, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 02:10:58PM +0200, Togan Muftuoglu wrote:
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote: There is the first drop...
I guess dropping was not the issue but keeping the dropped attacker for a long time in hold was the issue for me
Togan
Here is what used to have:
## SIP flood protection $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --set $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SIP attack: ' $IPTABLES -A INPUT -i $EXTERNALIF -p udp --dport 5060 -m recent --name sipattack --update --seconds 60 --hitcount 6 -j DROP
Update - the above does in fact work, it was triggered quite a few times last night. However, as I said yesterday, I don't currently have any external SIP users, but I'm pretty certain the above also gave legitimate users a problem. -- Per Jessen, Zürich (3.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2013 02:30 PM, Togan Muftuoglu wrote:
On 04/04/2013 02:19 PM, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 02:10:58PM +0200, Togan Muftuoglu wrote:
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote: There is the first drop...
I guess dropping was not the issue but keeping the dropped attacker for a long time in hold was the issue for me
Ok here we go again and in addition to the attacker not being held for a long time, the problem is in dictionary attacks SuSEfirewall2 fails, or I haven't been able to find a better way, since it takes quite a time for fail2ban to act. Fail2ban was in action The IP 62.75.202.56 has just been banned by Fail2Ban after 58 attempts against ASTERISK. So wandering what the hell SuSEfirewall2 doing Apr 13 03:56:10 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=62.75.202.56 DST=XXX.XXX.XXX.XX LEN=442 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=5098 DPT=5060 LEN=422 Apr 13 03:56:10 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=62.75.202.56 DST=XXX.XXX.XXX.XX LEN=463 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=5068 DPT=5060 LEN=443 So there are two packets and they are both accepted. There are no droped packets from this attacker Looking to asterisk this is again a brute force dictionary attack and SuSEfirewall2 is not sufficient with FW_SERVICES_ACCEPT_EXT="0/0,udp,5060,,hitcount=3,blockseconds=60,recentname=voip" [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"2276679141"<sip:2276679141@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"1"<sip:1@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"2"<sip:2@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"3"<sip:3@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"10"<sip:10@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"11"<sip:11@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"12"<sip:12@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"13"<sip:13@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"20"<sip:20@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"21"<sip:21@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"22"<sip:22@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"30"<sip:30@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"31"<sip:31@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"40"<sip:40@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"41"<sip:41@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"50"<sip:50@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"51"<sip:51@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"60"<sip:60@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"61"<sip:61@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"70"<sip:70@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"71"<sip:71@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"80"<sip:80@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"81"<sip:81@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"90"<sip:90@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"91"<sip:91@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"100"<sip:100@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"101"<sip:101@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"102"<sip:102@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"103"<sip:103@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"104"<sip:104@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"105"<sip:105@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"106"<sip:106@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"200"<sip:200@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"201"<sip:201@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"202"<sip:202@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"203"<sip:203@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"300"<sip:300@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"301"<sip:301@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"302"<sip:302@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"303"<sip:303@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"400"<sip:400@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"401"<sip:401@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"402"<sip:402@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"403"<sip:403@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"500"<sip:500@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"501"<sip:501@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"502"<sip:502@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"503"<sip:503@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"600"<sip:600@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"601"<sip:601@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"602"<sip:602@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"603"<sip:603@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"700"<sip:700@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"701"<sip:701@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"702"<sip:702@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"703"<sip:703@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"800"<sip:800@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"801"<sip:801@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"802"<sip:802@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"803"<sip:803@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"900"<sip:900@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"901"<sip:901@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"902"<sip:902@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"903"<sip:903@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"1000"<sip:1000@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"1001"<sip:1001@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"1002"<sip:1002@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"1003"<sip:1003@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"2000"<sip:2000@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found [2013-04-13 03:56:10] NOTICE[20816] chan_sip.c: Registration from '"2001"<sip:2001@XXX.XXX.XXX.XX>' failed for '62.75.202.56' - No matching peer found -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Apr 13, 2013 at 11:08:59AM +0200, Togan Muftuoglu wrote:
On 04/04/2013 02:30 PM, Togan Muftuoglu wrote:
On 04/04/2013 02:19 PM, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 02:10:58PM +0200, Togan Muftuoglu wrote:
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote: There is the first drop...
I guess dropping was not the issue but keeping the dropped attacker for a long time in hold was the issue for me
Ok here we go again and in addition to the attacker not being held for a long time, the problem is in dictionary attacks SuSEfirewall2 fails, or I haven't been able to find a better way, since it takes quite a time for fail2ban to act.
Fail2ban was in action
The IP 62.75.202.56 has just been banned by Fail2Ban after 58 attempts against ASTERISK.
So wandering what the hell SuSEfirewall2 doing
Apr 13 03:56:10 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=62.75.202.56 DST=XXX.XXX.XXX.XX LEN=442 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=5098 DPT=5060 LEN=422
Apr 13 03:56:10 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=62.75.202.56 DST=XXX.XXX.XXX.XX LEN=463 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=5068 DPT=5060 LEN=443
So there are two packets and they are both accepted. There are no droped packets from this attacker
Looking to asterisk this is again a brute force dictionary attack and SuSEfirewall2 is not sufficient with
FW_SERVICES_ACCEPT_EXT="0/0,udp,5060,,hitcount=3,blockseconds=60,recentname=voip"
We have found one issue with this.. Can you look at or better post _all_ above "dmesg" entries? Check especially if the TTL changes for the same SRC IP. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/13/2013 11:24 AM, Marcus Meissner wrote:
On Sat, Apr 13, 2013 at 11:08:59AM +0200, Togan Muftuoglu wrote:
On 04/04/2013 02:30 PM, Togan Muftuoglu wrote:
On 04/04/2013 02:19 PM, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 02:10:58PM +0200, Togan Muftuoglu wrote:
Hi Per, On 04/04/2013 01:41 PM, Per Jessen wrote: There is the first drop...
I guess dropping was not the issue but keeping the dropped attacker for a long time in hold was the issue for me
Ok here we go again and in addition to the attacker not being held for a long time, the problem is in dictionary attacks SuSEfirewall2 fails, or I haven't been able to find a better way, since it takes quite a time for fail2ban to act.
Fail2ban was in action
The IP 62.75.202.56 has just been banned by Fail2Ban after 58 attempts against ASTERISK.
So wandering what the hell SuSEfirewall2 doing
Apr 13 03:56:10 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=62.75.202.56 DST=XXX.XXX.XXX.XX LEN=442 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=5098 DPT=5060 LEN=422
Apr 13 03:56:10 whale kernel: SFW2-INext-ACC IN=eth0 OUT= MAC=00:19:66:3f:7f:fe:00:0d:65:ec:6e:ae:08:00 SRC=62.75.202.56 DST=XXX.XXX.XXX.XX LEN=463 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=5068 DPT=5060 LEN=443
So there are two packets and they are both accepted. There are no droped packets from this attacker
Looking to asterisk this is again a brute force dictionary attack and SuSEfirewall2 is not sufficient with
FW_SERVICES_ACCEPT_EXT="0/0,udp,5060,,hitcount=3,blockseconds=60,recentname=voip"
We have found one issue with this..
Can you look at or better post _all_ above "dmesg" entries?
As I said for that time window there are only two log messages from SuSEfirewall2 which I posted before they are same for dmesg also. Asterisk messages do not show anything about TTL,
Check especially if the TTL changes for the same SRC IP.
TTL is in all cases the same TTL=57 What else should I configure in maybe in asterisk ? Togan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Apr 04, 2013 at 01:31:35PM +0200, Togan Muftuoglu wrote:
On 04/04/2013 01:19 PM, Marcus Meissner wrote:
remove it from the generic FW_SERVICES_EXT_TCP line, and add to the FW_SERVICES_ACCEPT_EXT line: something like the ssh example: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Been there already does not work and of course EXT_UDP is not including 5060 :(
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh 0/0,udp,5060,,hitcount=3,blockseconds=180,recentname=voip"
Is this two lines or one? I just tried to block zeroconf: FW_SERVICES_ACCEPT_EXT="0/0,udp,5353,,hitcount=3,blockseconds=180,recentname=zeroconf" dmesg|grep 5353 gives e.g entries like: [1392831.200160] SFW2-INext-DROPr IN=eth0 OUT= MAC=01:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:SRC=<ip> DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44 "SFW2-INext-DROPr" is the drop target. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2013 01:58 PM, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 01:31:35PM +0200, Togan Muftuoglu wrote:
On 04/04/2013 01:19 PM, Marcus Meissner wrote:
remove it from the generic FW_SERVICES_EXT_TCP line, and add to the FW_SERVICES_ACCEPT_EXT line: something like the ssh example: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Been there already does not work and of course EXT_UDP is not including 5060 :(
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh 0/0,udp,5060,,hitcount=3,blockseconds=180,recentname=voip"
Is this two lines or one?
One line -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 11:18:09AM +0200, Togan Muftuoglu wrote:
On 04/04/2013 10:47 AM, Per Jessen wrote:
Our asterisk server is seeing numerous brute force attempts to get access to a SIP account. I've tried setting up a 'prevent flood' config with iptables, but wihtout much success. fail2ban et al does not work, so I was hoping someone might have a hint wrt an iptables setup to stop such brute force attacks?
Well not the answer you are looking for, but don't find yourself alone in this game, as my server is also under brute force attack, and no till now I have not been able to find any solution also, I have tried all the approaches you have tried but no success. I can't find a way to block as most of these attacks are logged as below where XXX is my servers own address, hence fail2ban unfortunately fails , or I can't find a better way to get the attackers' ip address.
100000<sip:100000@XXX.XXX.XXX.XX>;tag=eb6db4c6
So if you find a solution please share, as this issue is nerving me for a long time now
Is this always the same TCP/UDP port?
Yes, always UDP port 5060.
Then add a filter like the ssh "recent" filtering?
remove it from the generic FW_SERVICES_EXT_TCP line, and add to the FW_SERVICES_ACCEPT_EXT line: something like the ssh example: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
I've tried that, but had to disable it. I can't remember why, but it somehow interfered with legitimate SIP traffic. -- Per Jessen, Zürich (7.3°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Marcus Meissner -
Per Jessen -
Togan Muftuoglu