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@xxxxxxxxx 20040721 source: APNIC person: Chinanet Hostmaster nic-hdl: CH93-AP e-mail: anti-spam@xxxxxxxxxxxxxxxxxx address: No.31 ,jingrong street,beijing address: 100032 phone: +86-10-58501724 fax-no: +86-10-58501724 country: CN changed: dingsy@xxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx nic-hdl: JW89-AP mnt-by: MAINT-NEW changed: wang@xxxxxxxxxxxxxxxxxxxxx 19990818 source: APNIC Regards, Fail2Ban ----- Original Message ----- From: "/dev/rob0" <rob0@xxxxxxxxx> To: <netfilter@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
