LinuxQuestions.org
Review your favorite Linux distribution.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
Reload this Page ddos problems (udp)
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 03-22-2008, 12:40 PM   #1
comby
LQ Newbie
 
Registered: Mar 2008
Posts: 5

Rep: Reputation: 0
ddos problems (udp)

Hi,

my server is being ddosed the past few days..

I was able to get some logfiles through tcpdump..it seems that they attack randomly udp ports.. I even blocked ALL udp packets through iptables.. no results..

Quote:
18:16:07.630793 IP car75-7-88-160-251-40.fbx.proxad.net.56065 > MYIP.fsp: UDP, length 1024
18:16:07.647791 IP alf94-12-88-161-73-155.fbx.proxad.net.21763 > MYIP.fsp: UDP, length 1024
18:16:07.700783 IP lns-bzn-60-82-254-206-231.adsl.proxad.net.42498 > MYIP.fsp: UDP, length 1024
18:16:07.720779 IP alf94-12-88-161-73-155.fbx.proxad.net.6147 > MYIP.fsp: UDP, length 1024
18:16:07.731778 IP n172-u39.cabletel.bg.5377 > MYIP.fsp: UDP, length 1024
18:16:07.732778 IP car75-7-88-160-251-40.fbx.proxad.net.43523 > MYIP.fsp: UDP, length 1024
18:16:07.732778 IP alf94-12-88-161-73-155.fbx.proxad.net.60160 > MYIP.fsp: UDP, length 1024
18:16:07.742776 IP car75-7-88-160-251-40.fbx.proxad.net.8451 > MYIP.fsp: UDP, length 1024
18:16:07.768772 IP 193.68.179.153.14851 > MYIP.fsp: UDP, length 1024
18:16:07.775771 IP alf94-12-88-161-73-155.fbx.proxad.net.1025 > MYIP.fsp: UDP, length 1024
18:16:07.786769 IP car75-7-88-160-251-40.fbx.proxad.net.60930 > MYIP.fsp: UDP, length 1024
18:16:07.803767 IP d83-187-15-9.cust.tele2.pt.58556 > MYIP.fsp: UDP, length 1024
18:16:07.806766 IP car75-7-88-160-251-40.fbx.proxad.net.41728 > MYIP.fsp: UDP, length 1024
18:16:07.807766 IP 83.11.193.76.31234 > MYIP.fsp: UDP, length 1024
18:16:07.812765 IP 88.160.42.64.20993 > MYIP.fsp: UDP, length 1024
18:16:07.815765 IP lns-bzn-53-82-65-58-147.adsl.proxad.net.32513 > MYIP.fsp: UDP, length 1024
18:16:07.820764 IP lns-bzn-60-82-254-206-231.adsl.proxad.net.25858 > MYIP.fsp: UDP, length 1024
18:16:07.824764 IP lns-bzn-53-82-65-58-147.adsl.proxad.net.47617 > MYIP.fsp: UDP, length 1024
18:16:07.834762 IP i60-36-27-78.s04.a014.ap.plala.or.jp.29697 > MYIP.fsp: UDP, length 1024
18:16:07.847760 IP 60.36.27.69.10497 > MYIP.fsp: UDP, length 1024
18:16:07.847760 IP 193.68.179.195.56065 > MYIP.fsp: UDP, length 1024
18:16:07.850760 IP p3159-ipbf1302hodogaya.kanagawa.ocn.ne.jp.35586 > MYIP.fsp: UDP, length 1024
18:16:07.851759 IP 122.26.146.43.3328 > MYIP.fsp: UDP, length 1024
18:16:07.851759 IP 60.36.27.22.17411 > MYIP.fsp: UDP, length 1024
18:16:07.852759 IP 122.26.146.32.44289 > MYIP.fsp: UDP, length 1024
Anyone has a fast solution or idea?? :-(

thanks!!
 
Old 03-22-2008, 03:01 PM   #2
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
There's not much else you can do on your side if you're already sending all those packets to DROP. You can either wait for the storm to pass, or contact your ISP to see if they'll do some filtering upstream from you. How much bandwidth is the DDoS taking-up?
 
Old 03-23-2008, 06:37 PM   #3
comby
LQ Newbie
 
Registered: Mar 2008
Posts: 5

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by win32sux View Post
There's not much else you can do on your side if you're already sending all those packets to DROP. You can either wait for the storm to pass, or contact your ISP to see if they'll do some filtering upstream from you. How much bandwidth is the DDoS taking-up?
Only 12 mbits at all.

But it takes the whole line down.

I'm not sure our iptables is good enough, but this should block all INCOMMING udp packets?

Code:
Chain INPUT (policy DROP 5169 packets, 1112K bytes)
 pkts bytes target     prot opt in     out     source               destination
 677K  309M ACCEPT     0    --  eth1   *       192.168.0.0/16       0.0.0.0/0
   52  2084 ACCEPT     0    --  lo     *       127.0.0.1            0.0.0.0/0
    0     0 ACCEPT     0    --  lo     *       192.168.1.183        0.0.0.0/0
11972  854K ACCEPT     0    --  lo     *       89.163.y.x       0.0.0.0/0
    0     0 ACCEPT     0    --  lo     *       89.163.x.y       0.0.0.0/0
    0     0 ACCEPT     udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           udp spt:68 dpt:67
 185K   26M ACCEPT     0    --  *      *       0.0.0.0/0            89.163.y.x      state RELATED,ESTABLISHED
 8983  477K tcp_packets  tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0
 5142 1110K udp_packets  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0
  199 15522 icmp_packets  icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0
  141 16366 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT INPUT packet died: '
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x03 LOG flags 0 level 4 prefix `SYN/FIN packet'
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x03
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: avg 10/sec burst 5

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 bad_tcp_packets  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  eth1   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT FORWARD packet died: '

Chain OUTPUT (policy ACCEPT 6 packets, 3278 bytes)
 pkts bytes target     prot opt in     out     source               destination
 824K  375M bad_tcp_packets  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
   52  2084 ACCEPT     0    --  *      *       127.0.0.1            0.0.0.0/0
 648K   92M ACCEPT     0    --  *      *       192.168.1.183        0.0.0.0/0
 177K  283M ACCEPT     0    --  *      *       89.163.y.x       0.0.0.0/0
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT OUTPUT packet died: '

Chain allowed (13 references)
 pkts bytes target     prot opt in     out     source               destination
 8608  442K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x17/0x02
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  365 35197 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain bad_tcp_packets (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with tcp-reset
   32 33065 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW LOG flags 0 level 4 prefix `New not syn:'
   32 33065 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW

Chain icmp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
  199 15522 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8

Chain tcp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22222
 8698  450K allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22224
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:50000:50500
  148  7696 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22223
    3   156 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:25
   13   676 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110
   88  5348 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:113
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:6667
   22 12455 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:6800
    1    52 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3001
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:7001

Chain udp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
 
Old 03-23-2008, 07:16 PM   #4
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by comby View Post
Only 12 mbits at all.

But it takes the whole line down.

I'm not sure our iptables is good enough, but this should block all INCOMMING udp packets?

Code:
Chain INPUT (policy DROP 5169 packets, 1112K bytes)
 pkts bytes target     prot opt in     out     source               destination
 677K  309M ACCEPT     0    --  eth1   *       192.168.0.0/16       0.0.0.0/0
   52  2084 ACCEPT     0    --  lo     *       127.0.0.1            0.0.0.0/0
    0     0 ACCEPT     0    --  lo     *       192.168.1.183        0.0.0.0/0
11972  854K ACCEPT     0    --  lo     *       89.163.y.x       0.0.0.0/0
    0     0 ACCEPT     0    --  lo     *       89.163.x.y       0.0.0.0/0
    0     0 ACCEPT     udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           udp spt:68 dpt:67
 185K   26M ACCEPT     0    --  *      *       0.0.0.0/0            89.163.y.x      state RELATED,ESTABLISHED
 8983  477K tcp_packets  tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0
 5142 1110K udp_packets  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0
  199 15522 icmp_packets  icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0
  141 16366 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT INPUT packet died: '
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x03 LOG flags 0 level 4 prefix `SYN/FIN packet'
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x03
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: avg 10/sec burst 5

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 bad_tcp_packets  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  eth1   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT FORWARD packet died: '

Chain OUTPUT (policy ACCEPT 6 packets, 3278 bytes)
 pkts bytes target     prot opt in     out     source               destination
 824K  375M bad_tcp_packets  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
   52  2084 ACCEPT     0    --  *      *       127.0.0.1            0.0.0.0/0
 648K   92M ACCEPT     0    --  *      *       192.168.1.183        0.0.0.0/0
 177K  283M ACCEPT     0    --  *      *       89.163.y.x       0.0.0.0/0
    0     0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 3 LOG flags 0 level 7 prefix `IPT OUTPUT packet died: '

Chain allowed (13 references)
 pkts bytes target     prot opt in     out     source               destination
 8608  442K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x17/0x02
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
  365 35197 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain bad_tcp_packets (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x12/0x12 state NEW reject-with tcp-reset
   32 33065 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW LOG flags 0 level 4 prefix `New not syn:'
   32 33065 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW

Chain icmp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
  199 15522 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8

Chain tcp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22222
 8698  450K allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22224
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:50000:50500
  148  7696 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22223
    3   156 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:25
   13   676 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110
   88  5348 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:113
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:6667
   22 12455 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:6800
    1    52 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3001
    0     0 allowed    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:7001

Chain udp_packets (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
Yeah, it looks fine to me. Any UDP packets coming into eth0 get sent to the udp_packets chain, where they are sent to ACCEPT if they are --dport 53. Those that aren't --dport 53 get returned to the INPUT chain, where they don't match any other rules (aside from the LOG one) and end-up getting sent to DROP by the INPUT chain's policy.
Last edited by win32sux; 03-23-2008 at 07:21 PM.
 
Old 03-23-2008, 07:25 PM   #5
comby
LQ Newbie
 
Registered: Mar 2008
Posts: 5

Original Poster
Rep: Reputation: 0
Yes.. but it wont help at all

We're just being flooded..

Incoming rates:

11998.8 kbytes/sec
8754.8 packets/sec

Not really much, isnt it? All UDP packets..

Iptables wont help obviously, guess the only way is to upgrade to a bigger line or adding a hardware firewall?
 
Old 03-23-2008, 07:55 PM   #6
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by comby View Post
Yes.. but it wont help at all
Correct.

Quote:
We're just being flooded..

Incoming rates:

11998.8 kbytes/sec
8754.8 packets/sec

Not really much, isnt it? All UDP packets..
Well, "much" is subjective so I don't know.

But if it's bringing your whole connection down then, yeah, it sounds pretty bad.

Quote:
Iptables wont help obviously, guess the only way is to upgrade to a bigger line or adding a hardware firewall?
Upgrading to a bigger line might help, but it depends on the size of the botnet (or whatever) which has you under attack. As long as your attacker has more bandwidth than you she can keep denying your services. A "hardware firewall" won't help at all, for the same reasons iptables isn't helping you. No amount of firewalling on your side is going to be of any help. The attack needs to be dealt with further upstream (which normally means at your ISP's routers). It's the nature of a DDoS bandwidth attack.
 
Old 03-24-2008, 03:27 PM   #7
comby
LQ Newbie
 
Registered: Mar 2008
Posts: 5

Original Poster
Rep: Reputation: 0
Thanks for your help!

I'm wondering, because we have 8754.8 packets/sec, and iptables chain blocked only 1292 packets.. even when I block ALL udp packets..

how can that be ? Do the other udp packets never receive iptables ? or do they skip iptables ?
 
Old 03-24-2008, 06:11 PM   #8
win32sux
LQ Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
Quote:
Originally Posted by comby View Post
I'm wondering, because we have 8754.8 packets/sec, and iptables chain blocked only 1292 packets.. even when I block ALL udp packets..

how can that be ? Do the other udp packets never receive iptables ? or do they skip iptables ?
Well, in what you posted you technically weren't blocking "all" UDP packets, since you were indeed sending the DNS (UDP port 53) ones to ACCEPT. So maybe your DNS daemon is getting hit too? Perhaps you are also getting DDoSed by TCP packets? Or perhaps the difference in packet counts can be attributed to normal traffic? Right now I'm not sure what to make of the apparent packet count difference.
 
Old 03-24-2008, 07:17 PM   #9
beadyallen
Member
 
Registered: Mar 2008
Location: UK
Distribution: Fedora, Gentoo
Posts: 209

Rep: Reputation: 36
I'm not a networking expert, but are you sure those rates youreported are accurate? If you've only got a 12mbit internet line, then you can't be getting 11998.8 kbytes/sec coming in. Are you sure that the rates aren't for the whole network (LAN and WAN)?

I don't think iptables is a limiting factor, but in case it is, you could drop the udp packets earlier (such as explicitly within the udp_packets chain), instead of sending them through the whole input chain and then just using the default rule to drop them at the end. It'd save a bit of cpu time if you dropped them as soon as possible. But as win32sux has said, the only thing you can really do is either ask you isp to drop the traffic, or just weather the attack.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
uknown url type udp when using a udp tracker fakie_flip Linux - Software 1 08-03-2006 05:03 AM
UDP: Short Packets: and UDP bad checksum: entries in dmesg minutes2memories Linux - Networking 2 02-26-2006 07:28 PM
NFS problems with UDP tingdahl Linux - Networking 0 12-29-2005 01:50 PM
RFC 868 udp 37 time-udp gpl SUSE / openSUSE 2 03-31-2005 10:07 AM
How to receive UDP and ICMP packets, by one UDP socket(PMTUD) myself_rajat Linux - Networking 0 05-28-2004 05:43 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 12:44 PM.

Contact Us - Advertising Info - Rules - Privacy - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration