SME 7.4 with SAIL 2.x with 20 extensions and only 5 of them active - all remote SIP clients.
Lastweek there was a spate of dictionary attacks and sniffing for phpmyadmin. This week there is a continuing spate of SIP Register messages that increased the ping latency from 50ms to 1300ms. Servers in Amazon EC2 cloud and Linode.com were used to mount the attacks. Informed Amazon EC2 of the Abuse and await their action.
Ref:
http://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/Ref:
http://blog.sipvicious.org/Ref: Don't drown in Registration Flood:
http://www.inchalbase.com/waket02/img/pdf/datasheets/lab_ot_dditrfnote.pdfRef: Whitelist for SIP Reg:
http://www.ieee-cqr.org/2010/Day%202/Technical%20Session%20-%202/%283%29EricChen.pdfRef: SNOM SIP Flood Tracing:
http://wiki.snom.com/Settings/flood_tracingRef:
http://wiki.contribs.org/SME_Server:Documentation:FAQ#Block_incoming_IP_addressRef:
http://www.dslreports.com/forum/r24116233-General-Amazon-EC2-SIP-Flood-Attack-Complaints-Remain-Unanswer/var/log/asterisk/messages shows that SIP Scans created DoS from 4 IPs:
64.34.165.112 : sb103.successfulmatch.com / ns1.datingopinions.com - godaddy
109.74.193.250 : li140-250.members.linode.com - ns1.linode.com
184.106.64.217 : 184-106-64-217.static.cloud-ips.com - NS1.SLICEHOST.NET - tucowsdomains
184.106.95.80 : 184-106-95-80.static.cloud-ips.com - NS1.SLICEHOST.NET - tucowsdomains
188.72.203.179 - Bora Ismen, c/o Dynaceron LLC, Canada & Simon Roehl, netdirekt e. K., Frankfurt
88.208.193.245 - server88-208-193-245.live-servers.net - NS1.LIVE-SERVERS.NET - Mark Wood, Fasthosts Internet Limited, UK
122.224.135.163 - ZHEJIANG SHANGLIAN Enterprise Business Services Ltd.
The log file was over 700 MB in size.
Downloaded it after:
tar -zcvf messages-0.tar.gz /var/log/asterisk/messages
Used LTFViewer to view it. Get it at:
http://www.swiftgear.com/service sark stop
nano /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/40DenyRiffRaff
# contents of /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/40DenyRiffRaff
/sbin/iptables -I INPUT -s 184.106.0.0/16 -j REJECT
/sbin/iptables -I INPUT -s 109.74.0.0/16 -j REJECT
/sbin/iptables -I INPUT -s 64.34.165.112/32 -j REJECT
/sbin/iptables -I INPUT -s 194.44.43.0/24 -j REJECT
/sbin/iptables -I INPUT -s 195.38.0.0/16 -j REJECT
/sbin/iptables -I INPUT -s 59.66.0.0/16 -j REJECT
/sbin/iptables -I INPUT -s 91.121.0.0/19 -j REJECT
/sbin/iptables -I INPUT -s 122.224.135.160/29 -j REJECT
/sbin/iptables -I INPUT -s 188.72.203.0/24 -j REJECT
/sbin/iptables -I INPUT -s 88.208.193.0/24 -j REJECT
chmod 755 /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/40DenyRiffRaff
/sbin/e-smith/expand-template /etc/rc.d/init.d/masq
/etc/init.d/masq restart
service sark start
# Verification:
iptables -L > /var/log/asterisk/iptablesvalues.txt
iptables -L -vn > filter-iptables.txt
iptables -t nat -L -vn > nat.txt
While the above managed to stem the effect of the attack, the REJECT packets were still causing a DoS by bandwidth denial. DROP packets were not used as it would bloat the logs. The ping rate still remains the same though - very high indeed.