Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[Secure-SIP-Server]

Hi,

I'm suffering on a Denial-of-Service attack on my SIP(VoIP) UDP port 5060, 
getting more then 70 REGISTER requests per second since yesterday. All 
comming from the Japanese IP 59.146.75.111:5088.

First I wrote into my iptable:
....
/sbin/iptables -P INPUT DROP
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
....
/sbin/iptables -A INPUT -p udp --dport 5060 -s 59.146.75.111 -j REJECT
....

but it didn't work.
1st Question:
Why??

Then I wrote:
....
/sbin/iptables -P INPUT DROP
/sbin/iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 5060 -s 59.146.75.111 -j REJECT
/sbin/iptables -A INPUT -m state --state RELATED -j ACCEPT
....

Nothing changed, still receiving this REGISTER requests on my server.
Then I did:
....
/sbin/iptables -P INPUT DROP
/sbin/iptables -A INPUT -p udp --dport 5060 -s 59.146.75.111 -j REJECT
/sbin/iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT -m state --state RELATED -j ACCEPT
....

This worked! All requests from that IP are rejected, all others reach my 
server as ever.

/sbin/iptables -L --line-numbers -v -n
shows me an rapidly increasing number of packages and bytes rejected by the 
first statement.

Now my 2nd question:
How can this requests (UDP) be from a ESTABLISHED connection??? They passed 
the firewall in the first two examples and therefore they must be 
ESTABLISHED!?!

3rd question:
Is there a way to tell iptables to lock only a specific IP:PORT for a while 
if this IP transmits more then 50 requests per second? If so, how?

Thanks and regards

Detlef Pilzecker
Weitlahnerstrafle 8
D - 83209 Prien am Chiemsee 

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[Pascal Hambourg]

Hello,

Secure-SIP-Server a écrit :
> 
> I'm suffering on a Denial-of-Service attack on my SIP(VoIP) UDP port 5060, 
> getting more then 70 REGISTER requests per second since yesterday. All 
> comming from the Japanese IP 59.146.75.111:5088.
[...]
> Now my 2nd question:
> How can this requests (UDP) be from a ESTABLISHED connection??? They passed 
> the firewall in the first two examples and therefore they must be 
> ESTABLISHED!?!

UDP being connectionless by nature, the notion of "UDP connection" is
rather loose. Therefore a continuous flow of packets with the same ports
and addresses can be considered as one sigle connection even if they are
actually unrelated requests.

> 3rd question:
> Is there a way to tell iptables to lock only a specific IP:PORT for a while 
> if this IP transmits more then 50 requests per second? If so, how?

Check the "recent" match. Be sure you read carefully the man page about
its default limits.

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[Secure-SIP-Server]

@ Pascal Hambourg

> > I'm suffering on a Denial-of-Service attack on my SIP(VoIP) UDP port
> > 5060,
> > getting more then 70 REGISTER requests per second since yesterday. All
> > comming from the Japanese IP 59.146.75.111:5088.
> [...]
> > How can this requests (UDP) be from a ESTABLISHED connection??? They
> > passed
> > the firewall in the first two examples and therefore they must be
> > ESTABLISHED!?!
>
> UDP being connectionless by nature, the notion of "UDP connection" is
> rather loose. Therefore a continuous flow of packets with the same ports
> and addresses can be considered as one sigle connection even if they are
> actually unrelated requests.

Yes, looks like. I discovered that this only happens if I add the FW-rule
later then the first connection of the attacker to my SIP-server happened.
When I install the rule to DROP this requests behind
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
I must reboot the server before it works. If I don't want to reboot I must
put the DROP rule before this rule.

> > Is there a way to tell iptables to lock only a specific IP:PORT for a
> > while
> > if this IP transmits more then 50 requests per second? If so, how?
>
> Check the "recent" match. Be sure you read carefully the man page about
> its default limits.

Thanks for this!!! But ...
The author of "recent" writes:
"If the '--update' rule is before this check for ! NEW,INVALID packets then
ESTABLISHED connection or those in the process of becoming ESTABLISHED could
be disrupted by a malicious person who can modify his/her source address."
So in his opinion my
iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds
1 --hitcount 20 -j DROP
must come behind
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
and this leads me to the problem from above. This ACCEPT rule lets pass all
packages, because the first 19 packets in the first second are accepted and
therefore the FW considers the continuous flow of packets with the same port
and address as a single connection - and let them pass here.

Is there a way to tell the FW that this continuous flow of packets is not to
be considered a ESTABLISHED connection?


----------
@marcos

> i had the same  trouble in the past , and beyond  the  rules for your FW
> on
> itself there  is " other consideration"  to get on mind  , all people that
> are trying to steal  Voip   deploy you "brute force attack"  first trying
> with  few packets,  then  if they were not blocked , the real attacks
> begins
> later .  because don't have any sense keep attack to a blocked server,
> thay
> are  bad no dummies . so  the speed with  you blocks  these tries are so
> critical and will defines to your  intruder how  effective is the defense
> that you have.
>
> So will be so helpfull install some script that inspect your logs to
> detect
> the intrusion attack , i have very well result with   FAIL2BABN, [...]

Thank you for this idea and your other considerations!!!


Regards

Detlef Pilzecker
Weitlahnerstrafle 8
D - 83209 Prien am Chiemsee

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[SISINT BA]

dear friends here again :

Sorry about misstyping.   the script name  well typed is

 FAIL2BAN .

 it's so easy to configure  and use ,  just a few steps to put it to work.

need to define  a rule to detect  Fails in the  log file  ( ie   choose what
log inspect  asterisk.log o, or syslog, or messages. and so on  )  for
looking  some reg expressions inside them  ( like " wrong password " , .. an
son on )   and to define   an action to take when an attack was detected (
ie add  iptables rule ) and Voilá!,  that is it!!.  That's all!!!.  you will
find examples there with the script

take a look here
http://www.voip-info.org/wiki/view/Fail2Ban+%28with+iptables%29+And+Asterisk
 this may guide quickly  to setup on asterisk


This script  will  work fine with other services too,     vsftp, httpd,
SSH,  or any user log that you got
you can define how many fails will be assumed like attack and  how many time
leave EACH  host banned ,
also can  send a mail to any address using the mta  to  NOTIFY EVENTS ,
included start and stop  the defense ,
this   so helpfull to larm when  rebooting,,,,,, power failrudes ,,,,


Believe me , You will find this script so  helpfull.
i really hope that this may help you too.

Join together  to keep bad people banned!!!!    :-)

Think about this :
This schema  keep in sight to detetct intruders a neturalize your action
quickly , and no matters  to dive into the nature of the networks. because
of for the thieves  it's more easy to steal any  people that don't have any
"alarm"  that fight against  guys that were alerted and armed !!! and they
just  will leave us alone when they had seen that were dsicovered. .


Good luck, ....and ....... "That the force be with You!" .......or better
....... with "Us"

marcos





----- Original Message -----
From: "Secure-SIP-Server" <info@secure-sip-server.net>
To: <netfilter@vger.kernel.org>
Sent: Sunday, November 28, 2010 6:31 PM
Subject: Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)


> @ Pascal Hambourg
>
> > > I'm suffering on a Denial-of-Service attack on my SIP(VoIP) UDP port
> > > 5060,
> > > getting more then 70 REGISTER requests per second since yesterday. All
> > > comming from the Japanese IP 59.146.75.111:5088.
> > [...]
> > > How can this requests (UDP) be from a ESTABLISHED connection??? They
> > > passed
> > > the firewall in the first two examples and therefore they must be
> > > ESTABLISHED!?!
> >
> > UDP being connectionless by nature, the notion of "UDP connection" is
> > rather loose. Therefore a continuous flow of packets with the same ports
> > and addresses can be considered as one sigle connection even if they are
> > actually unrelated requests.
>
> Yes, looks like. I discovered that this only happens if I add the FW-rule
> later then the first connection of the attacker to my SIP-server happened.
> When I install the rule to DROP this requests behind
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> I must reboot the server before it works. If I don't want to reboot I must
> put the DROP rule before this rule.
>
> > > Is there a way to tell iptables to lock only a specific IP:PORT for a
> > > while
> > > if this IP transmits more then 50 requests per second? If so, how?
> >
> > Check the "recent" match. Be sure you read carefully the man page about
> > its default limits.
>
> Thanks for this!!! But ...
> The author of "recent" writes:
> "If the '--update' rule is before this check for ! NEW,INVALID packets
then
> ESTABLISHED connection or those in the process of becoming ESTABLISHED
could
> be disrupted by a malicious person who can modify his/her source address."
> So in his opinion my
> iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds
> 1 --hitcount 20 -j DROP
> must come behind
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> and this leads me to the problem from above. This ACCEPT rule lets pass
all
> packages, because the first 19 packets in the first second are accepted
and
> therefore the FW considers the continuous flow of packets with the same
port
> and address as a single connection - and let them pass here.
>
> Is there a way to tell the FW that this continuous flow of packets is not
to
> be considered a ESTABLISHED connection?
>
>
> ----------
> @marcos
>
> > i had the same  trouble in the past , and beyond  the  rules for your FW
> > on
> > itself there  is " other consideration"  to get on mind  , all people
that
> > are trying to steal  Voip   deploy you "brute force attack"  first
trying
> > with  few packets,  then  if they were not blocked , the real attacks
> > begins
> > later .  because don't have any sense keep attack to a blocked server,
> > thay
> > are  bad no dummies . so  the speed with  you blocks  these tries are so
> > critical and will defines to your  intruder how  effective is the
defense
> > that you have.
> >
> > So will be so helpfull install some script that inspect your logs to
> > detect
> > the intrusion attack , i have very well result with   FAIL2BABN, [...]
>
> Thank you for this idea and your other considerations!!!
>
>
> Regards
>
> Detlef Pilzecker
> Weitlahnerstraße 8
> D - 83209 Prien am Chiemsee
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[/dev/rob0]

On Sun, Nov 28, 2010 at 10:31:24PM +0100, Secure-SIP-Server wrote:
> @ Pascal Hambourg
>
>> > I'm suffering on a Denial-of-Service attack on my SIP(VoIP) UDP 
>> > port 5060, getting more then 70 REGISTER requests per second 
>> > since yesterday. All comming from the Japanese IP 
>> > 59.146.75.111:5088.
>> [...]
>> > How can this requests (UDP) be from a ESTABLISHED connection??? 
>> > They passed the firewall in the first two examples and therefore 
>> > they must be ESTABLISHED!?!
>>
>> UDP being connectionless by nature, the notion of "UDP connection" 
>> is rather loose. Therefore a continuous flow of packets with the 
>> same ports and addresses can be considered as one sigle connection 
>> even if they are actually unrelated requests.

This is the problem I too am having in trying to block SIP attacks, 
which I posted about ever so long ago, back in 2010 November: 

http://www.spinics.net/lists/netfilter/msg49598.html

The brute forcing generally seems to come with the same --sport, and 
since my Asterisk had replied with SIP rejections to the first few, 
it's ESTABLISHED.

Since that post, however, I have seen a few of these being detected 
and blocked, which makes me think there might be multiple attack bots 
(different code and owners) in the wild.

I think that the -m recent approach is not enough. We might also need 
something with -m limit. At this point I don't know enough about SIP 
and how it works, but I'm guessing that the SIP dialogue for a 
successful call is relatively short, so a --limit of 20 packets or so 
might help, preceding any --ctstate ESTABLISHED,RELATED -j ACCEPT 
rule, of course.

The bulk of a SIP call would be the RTP, which would be on ports 
other than 5060, in --ctstate RELATED (courtesy of the 
nf_conntrack_sip module.)

> Yes, looks like. I discovered that this only happens if I add the 
> FW-rule later then the first connection of the attacker to my 
> SIP-server happened. When I install the rule to DROP this requests 
> behind
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> I must reboot the server before it works. If I don't want to reboot 
> I must put the DROP rule before this rule.

Reboot is never necessary for this, unless you did something foolish 
with your kernel (built-in rather than modules?) See conntrack(8), 
and even without conntrack you can simply flush your rules, set all 
policies to ACCEPT, and remove the modules.

>> > Is there a way to tell iptables to lock only a specific IP:PORT 
>> > for a while if this IP transmits more then 50 requests per 
>> > second? If so, how?
>>
>> Check the "recent" match. Be sure you read carefully the man page 
>> about its default limits.
>
> Thanks for this!!! But ...
> The author of "recent" writes:
> "If the '--update' rule is before this check for ! NEW,INVALID 
> packets then ESTABLISHED connection or those in the process of 
> becoming ESTABLISHED could be disrupted by a malicious person who 
> can modify his/her source address."
> So in his opinion my
> iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds
> 1 --hitcount 20 -j DROP
> must come behind
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> and this leads me to the problem from above. This ACCEPT rule lets 
> pass all packages, because the first 19 packets in the first second 
> are accepted and therefore the FW considers the continuous flow of 
> packets with the same port and address as a single connection - and 
> let them pass here.
>
> Is there a way to tell the FW that this continuous flow of packets 
> is not to be considered a ESTABLISHED connection?

We precede the ESTABLISHED --> ACCEPT rule with something to handle 
SIP specially. Ugly, but probably the only choice.

> ----------
> @marcos
>
>> i had the same trouble in the past , and beyond the rules for your 
>> FW on itself there is " other consideration" to get on mind , all 
>> people that are trying to steal Voip deploy you "brute force 
>> attack" first trying with few packets, then if they were not 
>> blocked , the real attacks begins later .  because don't have any 
>> sense keep attack to a blocked server, thay are bad no dummies .

This fits with my experience as well, but don't count on it always 
being like this. Remember, the vast majority of these attack bots are 
operating from stolen resources (compromised systems.) It doesn't 
matter to them if they waste those resources, because the bots are 
out there continually working to steal more.

That's why abuse reports might still be worth the trouble. If the 
REAL owners of the attacking machines are alerted to the problem, 
they might take action to fix it. At least in a small portion of 
cases, don't get your hopes up.

>> so the speed with you blocks these tries are so critical and will 
>> defines to your intruder how effective is the defense that you 
>> have.
>>
>> So will be so helpfull install some script that inspect your logs 
>> to detect the intrusion attack , i have very well result with 
>> FAIL2BABN, [...]
>
> Thank you for this idea and your other considerations!!!

I have complaints with fail2ban. Yes, I know it works, and it's 
simple, but it doesn't feel like the right approach to me. Why do we 
need another daemon running to scan log files? Logs are for humans. 
I'd like to see network services with the ability to trigger external 
events when they're under attack.

Failing that, -m recent is pretty effective, but in the case of SIP, 
apparently not quite enough. (It works very well for SSH.)
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[SISINT BA]

I think that  any undesired packets  must be  DROPPED  and not REJECTED
becasue in some way  REJECT  is  REPLY  WITH ..... and  DROP  is  just
UNREPLIED . less effort for FW , don't consume bandwith  and more important
don't give any reponse to source ip!!.

I read the post that you have mention  iptables Log , and  the info that you
got ON CLI  CONSOLE is the same  put on the log file for  asterisk too , so
both action must be taken , all that you need on FW and  all that you can on
Logfiles ,

I  agree , with you about bot attacks  and resources stolen o server /hosts
hacked,
 I have had    300 , or even more,  ip address blocked on my list at the
same time , because of them .  But like i said , if you block them after a
few packets , the attacks changes the ip source  to anotherone , keep trying
but  after  enough tries they left you to search onother server  more easy
to attack.  and believeme!!! , there are on the network server more
insecure that ours own , so more easy to be under attack .Except that the
attacks  wants to blcok your server by another reason ,,,, ie beacuse very
angry with you :-)...

  on the opposite way , when an attack were not blocked quickly,  the robot
can keep yours tries for days and beyond that you block them  and  can't
reach the VoIP service  because is being blocked ,  in this situation you
can't  avoid that the UDP voip registers packets arrives  to your  network
because don't  require any connection,  because of  UDP nature on itself ,
and i promess that thay will be " hugh bunch"  Flooding  your connection if
dont stop quickly.  In eralier times i had robots keep trying to steal over
one week at rates 2 MBits, obviusly blocked can't stole. limit can't stop
the server  Voip.... but injury me borrowing  bandwith that i need for mi
clients. :-(
 coming from CHINA, Korea, URSS, Brazil, USA, Detuchalnd,Australia  .. an
some others USA included)

So we  could  think in restrict the access to a cloud of IP well konwn ,
from where we expect  user will be conected. it's so helpfull too. in our
FW, drop any unkown, accept known and  jump  to onother Chain  any packets
on doubt , there we can log, mark, limit, and so forth  and at last, if this
progress an reach our server and  these tries   fails to register  then will
be blocked  trough our log analisis script ( in my case fail2ban)

Another help that fal2ban provides is that the info for abuse compliant are
mailed to we ( info are taken from ARIN,APNIC.... as correpond to ip soruce
that attacks ) this may be helpfull with some cases . to make the complaint
, may work with some ISP, but is solwwwwww and lonnnng way  below  i put
copy from mail sent by failt2ban when block an ip

Beyond all these .. NEVER nothig that we are doing will be  enough about
take care about security.
all that we can , must be made  to assure our server , any combination of
rules, services, configurations,  Yeap! it's a very hard work!!!

On other  thread  i have comment about a simple try to allow access based on
iptbales + ip sorce  identified by DDNS domain , i mean

the user that  need to access to your  server must be identified trough
source ip , ( ideal for fixed ip but not everyone has one ) , over dymamics
ip,   the user needs to run a ddns client   keeping  user  source domain
updated, ie over DYNDNS.

  client.domain.dyndns.org  and your connection to internet trough
input-eth-dev


iptables -I INPUT  -i input-eth-dev  -s  client.domain.dyndns.org  -j ACCEPT
iptables -I INPUT  -i input-eth-dev  -p udp  --dport 5060 -j DROP

this has some trouble with DNS caches refresehing when the client  ip
changes very often on  many cases where the ISP force disconects changing ip
on the users may be so hard and don't be usefull , like on some ADSL
providers ,  becasue any source change will require that your iptables
modules must be reloaded  at least so often like  you re-register  your
Voip sucscription on asterisk  (  beacause in FW rules based on domains will
be resolved to  the real ip that had at those moment (or that were cached
too)  when  the rule was loaded , here big trouble ) . it's a trouble  may
be handled with cron , but  it's a trouble in any way.


I hope that can help anynone
Thank you all .


like said  before here is the Copy of mail from  fal2ban notifyingme about
ip that was blcked

VERY IMPORTANT

PLEASE NOTE THAT HE INFO IS ABOUT THE  ISP PROVIDER THAT  HAVE THE  SOURCE
IP  UNDER YOUR ADMINSITRATION  , NOT THE IDENTITY OF  PEOPLE THAT MADE THE
ATTACK
BUT HAS THE  MAIL ADDRESS WHERE SEND THE DISCLAIM/COMPLAINT FOR ABUSE


###############################################################

Hi,

The IP 60.171.75.147 has just been banned by Fail2Ban after
237 attempts against ASTERISK-METRO1.


Here are more information about 60.171.75.147:

[Preguntando whois.apnic.net]
[whois.apnic.net]
% [whois.apnic.net node-2]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:      60.166.0.0 - 60.175.255.255
netname:      CHINANET-AH
descr:        CHINANET anhui province network
descr:        China Telecom
descr:        A12,Xin-Jie-Kou-Wai Street
descr:        Beijing 100088
country:      CN
admin-c:      CH93-AP
tech-c:       JW89-AP
mnt-by:       APNIC-HM
mnt-routes:   MAINT-CHINANET-AH
mnt-lower:    MAINT-CHINANET-AH
status:       ALLOCATED PORTABLE
changed:      hm-changed@apnic.net 20040721
source:       APNIC

person:       Chinanet Hostmaster
nic-hdl:      CH93-AP
e-mail:       anti-spam@ns.chinanet.cn.net
address:      No.31 ,jingrong street,beijing
address:      100032
phone:        +86-10-58501724
fax-no:       +86-10-58501724
country:      CN
changed:      dingsy@cndata.com 20070416
mnt-by:       MAINT-CHINANET
source:       APNIC

person:       Jinneng Wang
address:      17/F, Postal Building No.120 Changjiang
address:      Middle Road, Hefei, Anhui, China
country:      CN
phone:        +86-551-2659073
fax-no:       +86-551-2659287
e-mail:       wang@mail.hf.ah.cninfo.net
nic-hdl:      JW89-AP
mnt-by:       MAINT-NEW
changed:      wang@mail.hf.ah.cninfo.net 19990818
source:       APNIC

Regards,

Fail2Ban


----- Original Message -----
From: "/dev/rob0" <rob0@gmx.co.uk>
To: <netfilter@vger.kernel.org>
Sent: Sunday, November 28, 2010 11:50 PM
Subject: Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)


> On Sun, Nov 28, 2010 at 10:31:24PM +0100, Secure-SIP-Server wrote:
> > @ Pascal Hambourg
> >
> >> > I'm suffering on a Denial-of-Service attack on my SIP(VoIP) UDP
> >> > port 5060, getting more then 70 REGISTER requests per second
> >> > since yesterday. All comming from the Japanese IP
> >> > 59.146.75.111:5088.
> >> [...]
> >> > How can this requests (UDP) be from a ESTABLISHED connection???
> >> > They passed the firewall in the first two examples and therefore
> >> > they must be ESTABLISHED!?!
> >>
> >> UDP being connectionless by nature, the notion of "UDP connection"
> >> is rather loose. Therefore a continuous flow of packets with the
> >> same ports and addresses can be considered as one sigle connection
> >> even if they are actually unrelated requests.
>
> This is the problem I too am having in trying to block SIP attacks,
> which I posted about ever so long ago, back in 2010 November:
>
> http://www.spinics.net/lists/netfilter/msg49598.html
>
> The brute forcing generally seems to come with the same --sport, and
> since my Asterisk had replied with SIP rejections to the first few,
> it's ESTABLISHED.
>
> Since that post, however, I have seen a few of these being detected
> and blocked, which makes me think there might be multiple attack bots
> (different code and owners) in the wild.
>
> I think that the -m recent approach is not enough. We might also need
> something with -m limit. At this point I don't know enough about SIP
> and how it works, but I'm guessing that the SIP dialogue for a
> successful call is relatively short, so a --limit of 20 packets or so
> might help, preceding any --ctstate ESTABLISHED,RELATED -j ACCEPT
> rule, of course.
>
> The bulk of a SIP call would be the RTP, which would be on ports
> other than 5060, in --ctstate RELATED (courtesy of the
> nf_conntrack_sip module.)
>
> > Yes, looks like. I discovered that this only happens if I add the
> > FW-rule later then the first connection of the attacker to my
> > SIP-server happened. When I install the rule to DROP this requests
> > behind
> > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > I must reboot the server before it works. If I don't want to reboot
> > I must put the DROP rule before this rule.
>
> Reboot is never necessary for this, unless you did something foolish
> with your kernel (built-in rather than modules?) See conntrack(8),
> and even without conntrack you can simply flush your rules, set all
> policies to ACCEPT, and remove the modules.
>
> >> > Is there a way to tell iptables to lock only a specific IP:PORT
> >> > for a while if this IP transmits more then 50 requests per
> >> > second? If so, how?
> >>
> >> Check the "recent" match. Be sure you read carefully the man page
> >> about its default limits.
> >
> > Thanks for this!!! But ...
> > The author of "recent" writes:
> > "If the '--update' rule is before this check for ! NEW,INVALID
> > packets then ESTABLISHED connection or those in the process of
> > becoming ESTABLISHED could be disrupted by a malicious person who
> > can modify his/her source address."
> > So in his opinion my
> > iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds
> > 1 --hitcount 20 -j DROP
> > must come behind
> > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > and this leads me to the problem from above. This ACCEPT rule lets
> > pass all packages, because the first 19 packets in the first second
> > are accepted and therefore the FW considers the continuous flow of
> > packets with the same port and address as a single connection - and
> > let them pass here.
> >
> > Is there a way to tell the FW that this continuous flow of packets
> > is not to be considered a ESTABLISHED connection?
>
> We precede the ESTABLISHED --> ACCEPT rule with something to handle
> SIP specially. Ugly, but probably the only choice.
>
> > ----------
> > @marcos
> >
> >> i had the same trouble in the past , and beyond the rules for your
> >> FW on itself there is " other consideration" to get on mind , all
> >> people that are trying to steal Voip deploy you "brute force
> >> attack" first trying with few packets, then if they were not
> >> blocked , the real attacks begins later .  because don't have any
> >> sense keep attack to a blocked server, thay are bad no dummies .
>
> This fits with my experience as well, but don't count on it always
> being like this. Remember, the vast majority of these attack bots are
> operating from stolen resources (compromised systems.) It doesn't
> matter to them if they waste those resources, because the bots are
> out there continually working to steal more.
>
> That's why abuse reports might still be worth the trouble. If the
> REAL owners of the attacking machines are alerted to the problem,
> they might take action to fix it. At least in a small portion of
> cases, don't get your hopes up.
>
> >> so the speed with you blocks these tries are so critical and will
> >> defines to your intruder how effective is the defense that you
> >> have.
> >>
> >> So will be so helpfull install some script that inspect your logs
> >> to detect the intrusion attack , i have very well result with
> >> FAIL2BABN, [...]
> >
> > Thank you for this idea and your other considerations!!!
>
> I have complaints with fail2ban. Yes, I know it works, and it's
> simple, but it doesn't feel like the right approach to me. Why do we
> need another daemon running to scan log files? Logs are for humans.
> I'd like to see network services with the ability to trigger external
> events when they're under attack.
>
> Failing that, -m recent is pretty effective, but in the case of SIP,
> apparently not quite enough. (It works very well for SSH.)
> --
>     Offlist mail to this address is discarded unless
>     "/dev/rob0" or "not-spam" is in Subject: header
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[Secure-SIP-Server]

Thanks to all your thoughts!

I found a solution on how to tell iptables not to see the continuous flow of 
SIP-packets as an ESTABLISHED connection. I split
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
into
# iptables -A INPUT -p ! udp -m state --state ESTABLISHED -j ACCEPT
# iptables -A INPUT -m state --state RELATED -j ACCEPT
The ESTABLISHED rule has not to work for UDP, so I excluded it.
I don't know why iptables does not exclude it by default! Someone knows???

Now I can put below:
# iptables -A INPUT -p udp --dport 5060 -m recent --name 
DENIAL_OF_SERVICE --update --seconds 1 --hitcount 20 -j REJECT --reject-with 
icmp-admin-prohibited
# iptables -A INPUT -p udp --dport 5060 -m recent --name 
DENIAL_OF_SERVICE --set -j ACCEPT

This works for me!!! < I'm happy!!! :-)) >
Now the malicious UDP-packet stream
- always pass the ESTABLISHED rule
- first pass the upper DENIAL_OF_SERVICE rule
- and some packets are accepted by the second DENIAL_OF_SERVICE rule (about 
4 or 5 REGISTER requests)
- but then the first DENIAL_OF_SERVICE rule rejects all following spam from 
this IP (requests from other IPs are still accepted!), and it is doing this 
now since hours rejecting several hundred MB traffic received. All others 
with normal traffic can pass to my SIP-Server without problems!
@  marcos: Of course I could also drop the packets instead of rejecting 
them, but I prefer this for the moment with: icmp-admin-prohibited.

----

I also noticed weeks before this attack happened that someone sends me 
SIP-REGISTER requests, always with the same
User-Agent: friendly-scanner
and I didn't know why. I suppose it was the one that started the attack now, 
but I don't know because I don't remember the IPs of those first requests.

In the following links I found some interesting thoughts about this attacks 
and a program to do those too!

blog of SIP-vicious
http://blog.sipvicious.org/

FAQ to SIP-vicious:
http://code.google.com/p/sipvicious/wiki/FrequentlyAskedQuestions

Storming SIP Security (pdf-discussion on the problem):
http://resources.enablesecurity.com/resources/22_29_storming_sip.pdf


Programs like FAIL2BAN are a good idea to use in addition to the above 
iptables rules, but fortunately I'm one of two coders writing scripts for a 
SIP-server in Perl (Net::SIP available at CPAN). I think I will write a 
module to check the incoming SIP messages for recurring possibly malicious 
intentions, that module should drop identified attacks not rejected before 
by the firewall. I will think about the best way to do this.

Regards

Detlef Pilzecker
Weitlahnerstrafle 8
D - 83209 Prien am Chiemsee 

Re: Using iptables for throttling SMTP traffic

[Secure-SIP-Server]

Hi Alex!

> I've set up a few basic rules to throttle SMTP traffic from an
> individual host should they make more than 10 connections in ten
> seconds:
>
> iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m 
> recent --set
> iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m
> recent --update --seconds 10 --hitcount 10 -j LOG
> iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m
> recent --update --seconds 10 --hitcount 10 -j DROP
>
> Is this the correct way to do this? I notice the seconds value can't
> be any greater than 20. What is the reason for this? I'd like to do
> something like permit up to 100 messages/connections over any
> 60-second period. Is this possible?

It is possible, but if your kernel supports it I don't know.

You can do:
# rmmod ipt_recent
# modprobe ipt_recent ip_pkt_list_tot=100

If you get the info that ipt_recent can't be removed because it's in use you 
must remove all 'recent' rules in your firewall table first. Then try it 
again.

But be careful !!!!!!!
I had set the values to hight. First everything worked fine. No error 
message when I did
# iptables -A INPUT -p udp --dport 5060 -m recent --name 
DENIAL_OF_SERVICE --update --rttl --seconds     1 --hitcount   10 -j DROP
# iptables -A INPUT -p udp --dport 5060 -m recent --name 
DENIAL_OF_SERVICE --update --rttl --seconds 100 --hitcount 200 -j DROP
# iptables -A INPUT -p udp --dport 5060 -m recent --name 
DENIAL_OF_SERVICE --set -j ACCEPT
and
# /sbin/iptables -L --line-numbers -v -n
also showed that this was installed.
Then I rebooted the server and ... nothing. I wasn't able to get in contact 
with my server again!!!!!!!!!
I had to access the Hard-disk booting from other system to fix it back to 
the default values. Then it worked again, but only with the default max 
of --hitcount 20   :-(

Regards

Detlef Pilzecker
Weitlahnerstrafle 8
D - 83209 Prien am Chiemsee 

Re: Using iptables for throttling SMTP traffic

[Jan Engelhardt]

On Tuesday 2010-11-30 14:14, Secure-SIP-Server wrote:
> It is possible, but if your kernel supports it I don't know.
>
> You can do:
> # rmmod ipt_recent
> # modprobe ipt_recent ip_pkt_list_tot=100

It's called xt_recent.

Re: Using iptables for throttling SMTP traffic

[lst_hoe02]

Zitat von Secure-SIP-Server <info@secure-sip-server.net>:

> Hi Alex!
>
>> I've set up a few basic rules to throttle SMTP traffic from an
>> individual host should they make more than 10 connections in ten
>> seconds:
>>
>> iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m  
>> recent --set
>> iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m
>> recent --update --seconds 10 --hitcount 10 -j LOG
>> iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m
>> recent --update --seconds 10 --hitcount 10 -j DROP
>>
>> Is this the correct way to do this? I notice the seconds value can't
>> be any greater than 20. What is the reason for this? I'd like to do
>> something like permit up to 100 messages/connections over any
>> 60-second period. Is this possible?

You can't at TCP/IP level. Modern Mailserver are able to push a lot of  
messages in *one* TCP/IP session (ESMTP). You can handle the max.  
number of new connections/time (recent) and the max. number of  
parallel connections at a given time (connlimit), but not the number  
of messages with iptables or any other TCP/IP based filter.

Regards

Andreas

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[/dev/rob0]

On Mon, Nov 29, 2010 at 10:38:32PM +0100, Secure-SIP-Server wrote:
> Thanks to all your thoughts!

Unfortunately due to power problems I have had daily shutdowns 
resulting in IP address changes, so my Asterisk console is staying 
quiet until the searchbots find me. I'm hoping for a week or two on
the same IP, so I can accumulate some results.

At this point I will just share my ruleset, in relevant part:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

:AllowHosts - [0:0]
:BadGuy - [0:0]
:Brake - [0:0]
:DropHosts - [0:0]
:Rejects - [0:0]
:State - [0:0]
:WAN - [0:0]

-A INPUT -j DropHosts
-A INPUT -j State
-A INPUT -j AllowHosts

# This chain allows known external hosts and my own networks
-A AllowHosts -i lo -j ACCEPT
-A AllowHosts -i eth0 -j ACCEPT
-A AllowHosts -i tun+ -j ACCEPT
-A AllowHosts -i wlan+ -j ACCEPT
-A AllowHosts -s x.y.z.48/29 -j ACCEPT
-A AllowHosts -s p.q.r.72/29 -j ACCEPT
# following is a SIP origination provider
-A AllowHosts -s 66.54.140.0/23 -m comment --comment "ipkall" -j ACCEPT
# following are SIP termination providers
-A AllowHosts -s 204.8.45.222 -m comment --comment "tfg" -j ACCEPT
-A AllowHosts -s 64.2.142.0/24 -m comment --comment "vitelity" -j ACCEPT
# and for anything which remains, from the Internet interface:
-A AllowHosts -i eth1 -j WAN

# Packets come here when we have determined that they are an attack
-A BadGuy -p tcp --dport 22 -j LOG --log-prefix "SSH attacker: "
-A BadGuy -p udp --dport 5060 -j LOG --log-prefix "SIP attacker: "
-A BadGuy -m recent --set --name BADGUY -j DROP

# Brake means "slow down" a possible attack. We allow 3 in 0:30 for 
# SSH attempts, 9 in 0:30 for SIP, then reject the next few up to 6
# in 0:45 for SSH and 18 in 0:45 for SIP. A host who has exceeded
# those limits is deemed an attacker (-j BadGuy).
-A Brake -p tcp -m recent --rcheck --hitcount 6 --name BRAKE --seconds 45 -j BadGuy -m comment --comment "SSH attacker"
-A Brake -p udp -m recent --rcheck --hitcount 18 --name BRAKE --seconds 45 -j BadGuy -m comment --comment "SIP attacker"
-A Brake -p tcp -m recent --update --hitcount 3 --name BRAKE --seconds 30 -j REJECT --reject-with tcp-reset -m comment --comment "probable SSH attack"
-A Brake -p udp -m recent --update --hitcount 9 --name BRAKE --seconds 30 -j REJECT --reject-with icmp-port-unreachable -m comment --comment "probable SIP attack"
-A Brake -m recent --set --name BRAKE -j ACCEPT -m comment --comment "adds source IP to BRAKE list"

# This chain comes first, and drops known attackers
-A DropHosts -m recent --rcheck --name BADGUY -j DROP -m comment --comment "checks to see if source IP has attacked us"
-A DropHosts -m mac --mac-source 00:0F:9F:6F:14:F0 -m comment --comment "example DropHosts rule" -j DROP

-A Rejects -i eth0 -m comment --comment "from LAN"
-A Rejects -i wlan+ -m comment --comment "from Wifi"
-A Rejects -i eth1 -m comment --comment "from WAN"
-A Rejects -i tun+ -m comment --comment "from VPN"
-A Rejects -p tcp -j REJECT --reject-with tcp-reset
-A Rejects -m comment --comment "This takes the place of a default DROP policy" -j DROP
-A Rejects -m comment --comment "This should always be [0:0]" -j DROP

# The second chain, has the SIP bypass
-A State -m conntrack --ctstate INVALID -j DROP
-A State -m conntrack --ctstate RELATED -j ACCEPT
-A State -i eth1 -p udp --dport 5060 -j AllowHosts -m comment --comment "later goes to WAN"
-A State -m conntrack --ctstate ESTABLISHED -j ACCEPT

# Packets coming in the external interface come here
-A WAN -p tcp --dport 22 -j Brake
-A WAN -p udp --dport 1194 -j ACCEPT -m comment --comment "openvpn"
-A WAN -m conntrack --ctstate NEW -p udp --dport 5060 -j LOG --log-prefix "NEW SIP: "
-A WAN -p udp --dport 5060 -j Brake
-A WAN -p icmp -m icmp --icmp-type 0 -m limit --limit 5/min --limit-burst 3 -j ACCEPT
-A WAN -p icmp -m icmp --icmp-type 0 -j DROP
-A WAN -p icmp -j ACCEPT
-A WAN -i eth1 -m comment --comment "from WAN" -j Rejects

> I found a solution on how to tell iptables not to see the 
> continuous flow of SIP-packets as an ESTABLISHED connection. I 
> split
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> into
> # iptables -A INPUT -p ! udp -m state --state ESTABLISHED -j ACCEPT

This is wrong. You probably want UDP ESTABLISHED packets, in general, 
my ruleset above only separates out SIP.

> # iptables -A INPUT -m state --state RELATED -j ACCEPT
> The ESTABLISHED rule has not to work for UDP, so I excluded it. I 
> don't know why iptables does not exclude it by default! Someone 
> knows???

This is wrong too. ESTABLISHED is fine for UDP; our problem here 
being that the attack bots use the same --source-port for the whole 
attack, and that by having sent our SIP reply to the initial few 
registration attempts, connection tracking considers these to be in
ESTABLISHED state.

> Now I can put below:
> # iptables -A INPUT -p udp --dport 5060 -m recent --name  
> DENIAL_OF_SERVICE --update --seconds 1 --hitcount 20 -j REJECT 
> --reject-with icmp-admin-prohibited
> # iptables -A INPUT -p udp --dport 5060 -m recent --name  
> DENIAL_OF_SERVICE --set -j ACCEPT
>
> This works for me!!! < I'm happy!!! :-)) >

We're trying with different numbers. After I've accumulated some 
results with my numbers, I might try shorter --seconds values.

> Now the malicious UDP-packet stream
> - always pass the ESTABLISHED rule
> - first pass the upper DENIAL_OF_SERVICE rule
> - and some packets are accepted by the second DENIAL_OF_SERVICE rule 
> (about 4 or 5 REGISTER requests)
> - but then the first DENIAL_OF_SERVICE rule rejects all following 
> spam from this IP (requests from other IPs are still accepted!), 
> and it is doing this now since hours rejecting several hundred MB 
> traffic received.

You might find that the same host will continue to bombard you 
indefinitely. I think there is a bug in the malware. :)

> All others with normal traffic can pass to my SIP-Server without 
> problems! @ marcos: Of course I could also drop the packets instead 
> of rejecting them, but I prefer this for the moment with: 
> icmp-admin-prohibited.

I think you should DROP known attackers. When I was under that attack 
from mid-November, the ICMP would have significantly hurt my limited 
upstream bandwidth (cheap rural consumer-grade DSL here.)

If I ever convert to business-class DSL here, which I might, I'd 
demand service from the ISP when my static IP is under such attack. 
I'd insist to have it blocked upstream.
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header

Re: Denial-of-Service attack on UDP-port 5060 (SIP/VoIP)

[Secure-SIP-Server]

@ /dev/rob0

> > I found a solution on how to tell iptables not to see the
> > continuous flow of SIP-packets as an ESTABLISHED connection. I
> > split
> > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > into
> > # iptables -A INPUT -p ! udp -m state --state ESTABLISHED -j ACCEPT
>
> This is wrong. You probably want UDP ESTABLISHED packets ....

Hmmm, it might not be the optimum but it works very well. All ESTABLISHED
UDP "connections" can go down the ruleset until they are ACCEPTed or DROPed
by other rule.

> We're trying with different numbers. After I've accumulated some
> results with my numbers, I might try shorter --seconds values.

I think this depends on your non-DoS traffic. My attacker is sending up to
70 packets per second. So
--seconds 10 --hitcount 20
is enough for me at the moment and the othe traffic can pass without
problems.

> I think you should DROP known attackers. When I was under that attack
> from mid-November, the ICMP would have significantly hurt my limited
> upstream bandwidth (cheap rural consumer-grade DSL here.)

You are right and I did it already, but for other consideration:
If the attacker is doing IP-spoofing my REJECT packets will be send to an
innocent IP. That is not what I want, because then unintentionally I become
an attacker on this server with my reject-packets.

If you want to see my ruleset, I attached it below.
In particular I would like to make aware of:
-A OUTPUT -s ! XXX.XXX.XXX.XXX/32 -j DROP
Add to prevent other users of the server from doing IP-spoofing.
I think every server admin should add this by default!

Detlef Pilzecker
Weitlahnerstrafle 8
D - 83209 Prien am Chiemsee

---------------------------------------

# Generated by iptables-save v1.4.2 on Wed Dec  1 18:31:18 2010
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p ! udp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j
REJECT --reject-with tcp-reset
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 5060 -m recent --update --seconds
10 --hitcount 20 --rttl --name DOS_5060 --rsource -j DROP
-A INPUT -p udp -m udp --dport 5060 -m recent --set --name
DOS_5060 --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds
300 --hitcount 5 --rttl --name DOS_22 --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m recent --set --name DOS_22 --rsource -j
ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8/0 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j
REJECT --reject-with tcp-reset
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i lo -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j
REJECT --reject-with tcp-reset
-A OUTPUT -m state --state INVALID -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -s ! XXX.XXX.XXX.XXX/32 -j DROP
COMMIT
# Completed on Wed Dec  1 18:31:18 2010
# Generated by iptables-save v1.4.2 on Wed Dec  1 18:31:18 2010
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Wed Dec  1 18:31:18 2010
# Generated by iptables-save v1.4.2 on Wed Dec  1 18:31:18 2010
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Wed Dec  1 18:31:18 2010