Linux Netfilter discussions
 help / color / mirror / Atom feed
* Watched a DDoS attack for hours and couldn't do much :S
@ 2006-11-27  6:36 AntiProxy
  2006-11-27  7:59 ` Danny
  2006-11-27  8:03 ` Danny
  0 siblings, 2 replies; 7+ messages in thread
From: AntiProxy @ 2006-11-27  6:36 UTC (permalink / raw)
  To: netfilter

Dear all,


One of my servers was hit by a DDoS attack earlier today,
and the pattern was different to these i've seen before.

netstat doesn't show any TCP or UDP connections in any state.

however, TCPDUMP shows the following (i'm posting a few lines of
millions): 
00:51:08.279876 IP 199.28.0.228.1136 > My.Victim.IP.1060: S 3605427625:3605427625(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.279905 IP My.Victim.IP.1060 > 199.28.0.228.1136: R 0:0(0) ack 3605427626 win 0
00:51:08.279945 IP 202.227.64.177.1027 > My.Victim.IP.1277: S 361765779:361765779(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.279977 IP My.Victim.IP.1277 > 202.227.64.177.1027: R 0:0(0) ack 361765780 win 0
00:51:08.280014 IP 205.22.254.231.1080 > My.Victim.IP.1036: S 1599573484:1599573484(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280043 IP My.Victim.IP.1036 > 205.22.254.231.1080: R 0:0(0) ack 1599573485 win 0
00:51:08.280082 IP 202.238.89.100.1137 > My.Victim.IP.1158: S 3844747271:3844747271(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280111 IP My.Victim.IP.1158 > 202.238.89.100.1137: R 0:0(0) ack 3844747272 win 0
00:51:08.280152 IP 210.16.241.153.1074 > My.Victim.IP.1273: S 2749255844:2749255844(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280182 IP My.Victim.IP.1273 > 210.16.241.153.1074: R 0:0(0) ack 2749255845 win 0
00:51:08.280220 IP 202.37.165.2.1143 > My.Victim.IP.1106: S 1963715017:1963715017(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280250 IP My.Victim.IP.1106 > 202.37.165.2.1143: R 0:0(0) ack 1963715018 win 0
00:51:08.280289 IP 211.225.4.65.1043 > My.Victim.IP.1031: S 1558151020:1558151020(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280426 IP 199.75.254.153.1258 > My.Victim.IP.1026: S 1190926252:1190926252(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280496 IP 199.250.149.61.1099 > My.Victim.IP.1111: S 2527588092:2527588092(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280633 IP 210.155.122.67.1078 > My.Victim.IP.1248: S 1669627316:1669627316(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280710 IP 199.43.54.188.1144 > My.Victim.IP.1167: S 4133488145:4133488145(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280908 IP 211.231.52.59.1100 > My.Victim.IP.1107: S 3438491552:3438491552(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.280976 IP 198.0.6.165.1172 > My.Victim.IP.1036: S 1294249773:1294249773(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.281114 IP 211.86.244.159.1268 > My.Victim.IP.1186: S 3158078860:3158078860(0) win 16384 <mss 1460,nop,[bad opt]>
00:51:08.281189 IP 210.137.244.254 > My.Victim.IP: icmp 36: time exceeded in-transit
00:51:08.281265 IP 202.93.103.38 > My.Victim.IP: icmp 36: 202.93.103.38 tcp port 1046 unreachable
00:51:08.281334 IP 129.228.28.125.1135 > My.Victim.IP.1068: S 4066000806:4066000806(0) win 16384 <mss 1460,nop,[bad opt]>

what does it tell you?

the only thing that shows up in my syslog is the following:
Nov 27 05:52:30 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
Nov 27 05:52:30 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
Nov 27 05:52:32 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
Nov 27 05:52:32 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
Nov 27 05:52:39 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0

although my IPTABLES script should have logged the DDoS..

following is a snippet of my IPTables script:

$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle
$IPTABLES -F -t filter
$IPTABLES -X SRC_FILTER
$IPTABLES -N SRC_FILTER
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -p TCP --tcp-flags ! ALL SYN -j DROP

# had this bit from before.. i just noticed it's in the FORWARD chain, so i doubt it does anything in my setup
$IPTABLES -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
$IPTABLES -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
$IPTABLES -A FORWARD -d 216.133.73.152/32 -p tcp --syn -m limit --limit 20/minute -j ACCEPT

#i added this yesterday during an attack, but it didn't do anything:
$IPTABLES -X syn-flood
$IPTABLES -N syn-flood
$IPTABLES -A syn-flood -m limit --limit 10/second --limit-burst 15 -j RETURN
$IPTABLES -A syn-flood -j LOG --log-prefix "SYN flood: "
$IPTABLES -A syn-flood -j DROP

The system has one NIC with 24 virtual interfaces (24 IPs)
no NAT is being done, the public IPs are assigned directly to the interfaces.

it runs Debian Sarge (Stable), 2.6.8-2-k7 kernel, IPTables v1.2.11-10 debian package

any help would really be appreciated!

Regards,

AntiProxy



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Watched a DDoS attack for hours and couldn't do much :S
  2006-11-27  6:36 Watched a DDoS attack for hours and couldn't do much :S AntiProxy
@ 2006-11-27  7:59 ` Danny
  2006-11-27  8:03 ` Danny
  1 sibling, 0 replies; 7+ messages in thread
From: Danny @ 2006-11-27  7:59 UTC (permalink / raw)
  To: admin, netfilter

Hi,

Hmm,,, this seems to a different version of SYN attack. All the SYN 
requests were violating TCP/IP stack. Hence there were no SYN_RECEIVED 
state in netstat output.

Try figuring out the complete TCP option field, using tcpdump or snort.

Try using this ! [ might work !! ] 

$IPTABLES -A INPUT -p tcp --syn -m limit --limit 10/second --limit-burst 15 -j LOG --log-prefix "SYN flood: "
 

All the best.


- Danny

AntiProxy wrote:
> Dear all,
>
>
> One of my servers was hit by a DDoS attack earlier today,
> and the pattern was different to these i've seen before.
>
> netstat doesn't show any TCP or UDP connections in any state.
>
> however, TCPDUMP shows the following (i'm posting a few lines of
> millions): 
> 00:51:08.279876 IP 199.28.0.228.1136 > My.Victim.IP.1060: S 3605427625:3605427625(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.279905 IP My.Victim.IP.1060 > 199.28.0.228.1136: R 0:0(0) ack 3605427626 win 0
> 00:51:08.279945 IP 202.227.64.177.1027 > My.Victim.IP.1277: S 361765779:361765779(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.279977 IP My.Victim.IP.1277 > 202.227.64.177.1027: R 0:0(0) ack 361765780 win 0
> 00:51:08.280014 IP 205.22.254.231.1080 > My.Victim.IP.1036: S 1599573484:1599573484(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280043 IP My.Victim.IP.1036 > 205.22.254.231.1080: R 0:0(0) ack 1599573485 win 0
> 00:51:08.280082 IP 202.238.89.100.1137 > My.Victim.IP.1158: S 3844747271:3844747271(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280111 IP My.Victim.IP.1158 > 202.238.89.100.1137: R 0:0(0) ack 3844747272 win 0
> 00:51:08.280152 IP 210.16.241.153.1074 > My.Victim.IP.1273: S 2749255844:2749255844(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280182 IP My.Victim.IP.1273 > 210.16.241.153.1074: R 0:0(0) ack 2749255845 win 0
> 00:51:08.280220 IP 202.37.165.2.1143 > My.Victim.IP.1106: S 1963715017:1963715017(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280250 IP My.Victim.IP.1106 > 202.37.165.2.1143: R 0:0(0) ack 1963715018 win 0
> 00:51:08.280289 IP 211.225.4.65.1043 > My.Victim.IP.1031: S 1558151020:1558151020(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280426 IP 199.75.254.153.1258 > My.Victim.IP.1026: S 1190926252:1190926252(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280496 IP 199.250.149.61.1099 > My.Victim.IP.1111: S 2527588092:2527588092(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280633 IP 210.155.122.67.1078 > My.Victim.IP.1248: S 1669627316:1669627316(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280710 IP 199.43.54.188.1144 > My.Victim.IP.1167: S 4133488145:4133488145(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280908 IP 211.231.52.59.1100 > My.Victim.IP.1107: S 3438491552:3438491552(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280976 IP 198.0.6.165.1172 > My.Victim.IP.1036: S 1294249773:1294249773(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.281114 IP 211.86.244.159.1268 > My.Victim.IP.1186: S 3158078860:3158078860(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.281189 IP 210.137.244.254 > My.Victim.IP: icmp 36: time exceeded in-transit
> 00:51:08.281265 IP 202.93.103.38 > My.Victim.IP: icmp 36: 202.93.103.38 tcp port 1046 unreachable
> 00:51:08.281334 IP 129.228.28.125.1135 > My.Victim.IP.1068: S 4066000806:4066000806(0) win 16384 <mss 1460,nop,[bad opt]>
>
> what does it tell you?
>
> the only thing that shows up in my syslog is the following:
> Nov 27 05:52:30 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
> Nov 27 05:52:30 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
> Nov 27 05:52:32 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
> Nov 27 05:52:32 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
> Nov 27 05:52:39 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
>
> although my IPTABLES script should have logged the DDoS..
>
> following is a snippet of my IPTables script:
>
> $IPTABLES -F
> $IPTABLES -F -t nat
> $IPTABLES -F -t mangle
> $IPTABLES -F -t filter
> $IPTABLES -X SRC_FILTER
> $IPTABLES -N SRC_FILTER
> $IPTABLES -A INPUT -m state --state INVALID -j DROP
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A INPUT -m state --state NEW -p TCP --tcp-flags ! ALL SYN -j DROP
>
> # had this bit from before.. i just noticed it's in the FORWARD chain, so i doubt it does anything in my setup
> $IPTABLES -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
> $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
> $IPTABLES -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
> $IPTABLES -A FORWARD -d 216.133.73.152/32 -p tcp --syn -m limit --limit 20/minute -j ACCEPT
>
> #i added this yesterday during an attack, but it didn't do anything:
> $IPTABLES -X syn-flood
> $IPTABLES -N syn-flood
> $IPTABLES -A syn-flood -m limit --limit 10/second --limit-burst 15 -j RETURN
> $IPTABLES -A syn-flood -j LOG --log-prefix "SYN flood: "
> $IPTABLES -A syn-flood -j DROP
>
> The system has one NIC with 24 virtual interfaces (24 IPs)
> no NAT is being done, the public IPs are assigned directly to the interfaces.
>
> it runs Debian Sarge (Stable), 2.6.8-2-k7 kernel, IPTables v1.2.11-10 debian package
>
> any help would really be appreciated!
>
> Regards,
>
> AntiProxy
>
>
>
>   



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Watched a DDoS attack for hours and couldn't do much :S
  2006-11-27  6:36 Watched a DDoS attack for hours and couldn't do much :S AntiProxy
  2006-11-27  7:59 ` Danny
@ 2006-11-27  8:03 ` Danny
  2006-11-27 17:15   ` AntiProxy
  1 sibling, 1 reply; 7+ messages in thread
From: Danny @ 2006-11-27  8:03 UTC (permalink / raw)
  To: admin, netfilter

Hey !

also : what does 'netstat -s -t' show ?


Danny

AntiProxy wrote:
> Dear all,
>
>
> One of my servers was hit by a DDoS attack earlier today,
> and the pattern was different to these i've seen before.
>
> netstat doesn't show any TCP or UDP connections in any state.
>
> however, TCPDUMP shows the following (i'm posting a few lines of
> millions): 
> 00:51:08.279876 IP 199.28.0.228.1136 > My.Victim.IP.1060: S 3605427625:3605427625(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.279905 IP My.Victim.IP.1060 > 199.28.0.228.1136: R 0:0(0) ack 3605427626 win 0
> 00:51:08.279945 IP 202.227.64.177.1027 > My.Victim.IP.1277: S 361765779:361765779(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.279977 IP My.Victim.IP.1277 > 202.227.64.177.1027: R 0:0(0) ack 361765780 win 0
> 00:51:08.280014 IP 205.22.254.231.1080 > My.Victim.IP.1036: S 1599573484:1599573484(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280043 IP My.Victim.IP.1036 > 205.22.254.231.1080: R 0:0(0) ack 1599573485 win 0
> 00:51:08.280082 IP 202.238.89.100.1137 > My.Victim.IP.1158: S 3844747271:3844747271(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280111 IP My.Victim.IP.1158 > 202.238.89.100.1137: R 0:0(0) ack 3844747272 win 0
> 00:51:08.280152 IP 210.16.241.153.1074 > My.Victim.IP.1273: S 2749255844:2749255844(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280182 IP My.Victim.IP.1273 > 210.16.241.153.1074: R 0:0(0) ack 2749255845 win 0
> 00:51:08.280220 IP 202.37.165.2.1143 > My.Victim.IP.1106: S 1963715017:1963715017(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280250 IP My.Victim.IP.1106 > 202.37.165.2.1143: R 0:0(0) ack 1963715018 win 0
> 00:51:08.280289 IP 211.225.4.65.1043 > My.Victim.IP.1031: S 1558151020:1558151020(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280426 IP 199.75.254.153.1258 > My.Victim.IP.1026: S 1190926252:1190926252(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280496 IP 199.250.149.61.1099 > My.Victim.IP.1111: S 2527588092:2527588092(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280633 IP 210.155.122.67.1078 > My.Victim.IP.1248: S 1669627316:1669627316(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280710 IP 199.43.54.188.1144 > My.Victim.IP.1167: S 4133488145:4133488145(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280908 IP 211.231.52.59.1100 > My.Victim.IP.1107: S 3438491552:3438491552(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.280976 IP 198.0.6.165.1172 > My.Victim.IP.1036: S 1294249773:1294249773(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.281114 IP 211.86.244.159.1268 > My.Victim.IP.1186: S 3158078860:3158078860(0) win 16384 <mss 1460,nop,[bad opt]>
> 00:51:08.281189 IP 210.137.244.254 > My.Victim.IP: icmp 36: time exceeded in-transit
> 00:51:08.281265 IP 202.93.103.38 > My.Victim.IP: icmp 36: 202.93.103.38 tcp port 1046 unreachable
> 00:51:08.281334 IP 129.228.28.125.1135 > My.Victim.IP.1068: S 4066000806:4066000806(0) win 16384 <mss 1460,nop,[bad opt]>
>
> what does it tell you?
>
> the only thing that shows up in my syslog is the following:
> Nov 27 05:52:30 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
> Nov 27 05:52:30 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
> Nov 27 05:52:32 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
> Nov 27 05:52:32 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
> Nov 27 05:52:39 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
>
> although my IPTABLES script should have logged the DDoS..
>
> following is a snippet of my IPTables script:
>
> $IPTABLES -F
> $IPTABLES -F -t nat
> $IPTABLES -F -t mangle
> $IPTABLES -F -t filter
> $IPTABLES -X SRC_FILTER
> $IPTABLES -N SRC_FILTER
> $IPTABLES -A INPUT -m state --state INVALID -j DROP
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A INPUT -m state --state NEW -p TCP --tcp-flags ! ALL SYN -j DROP
>
> # had this bit from before.. i just noticed it's in the FORWARD chain, so i doubt it does anything in my setup
> $IPTABLES -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
> $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
> $IPTABLES -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
> $IPTABLES -A FORWARD -d 216.133.73.152/32 -p tcp --syn -m limit --limit 20/minute -j ACCEPT
>
> #i added this yesterday during an attack, but it didn't do anything:
> $IPTABLES -X syn-flood
> $IPTABLES -N syn-flood
> $IPTABLES -A syn-flood -m limit --limit 10/second --limit-burst 15 -j RETURN
> $IPTABLES -A syn-flood -j LOG --log-prefix "SYN flood: "
> $IPTABLES -A syn-flood -j DROP
>
> The system has one NIC with 24 virtual interfaces (24 IPs)
> no NAT is being done, the public IPs are assigned directly to the interfaces.
>
> it runs Debian Sarge (Stable), 2.6.8-2-k7 kernel, IPTables v1.2.11-10 debian package
>
> any help would really be appreciated!
>
> Regards,
>
> AntiProxy
>
>
>
>   



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Watched a DDoS attack for hours and couldn't do much :S
       [not found] <200611270803.kAR81k2Y030892@mail3.jubileegroup.co.uk>
@ 2006-11-27  8:38 ` G.W. Haywood
  2006-11-27 17:16   ` AntiProxy
  0 siblings, 1 reply; 7+ messages in thread
From: G.W. Haywood @ 2006-11-27  8:38 UTC (permalink / raw)
  To: netfilter

Hi there,

On Mon, 27 Nov 2006 AntiProxy wrote:

> One of my servers was hit by a DDoS attack earlier today,
> and the pattern was different to these i've seen before.
>
> netstat doesn't show any TCP or UDP connections in any state.
>
> however, TCPDUMP shows the following (i'm posting a few lines of
> millions):
> [...]
> what does it tell you?

Somebody is trying to spoof a machine on your network?

I'd have thought a reasonable box could drop 15k packets/second OK but
you might need to put rules in the INPUT chain to drop everything from
the offending IPs.  For this kind of thing I use a Perl script to scan
the logs and insert rules into iptables in real time.  Its input is
piped from syslog-ng.  It takes a bit of setting up but it's worth it.
If there are large numbers (thousands) of attacking IPs you'll need to
look at something like ipset as iptables will begin to creak a bit.

If this continues you might want to contact your upstream provider.
They will want to help if they're at all reputable.

--

73,
Ged.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Watched a DDoS attack for hours and couldn't do much :S
  2006-11-27  8:03 ` Danny
@ 2006-11-27 17:15   ` AntiProxy
  0 siblings, 0 replies; 7+ messages in thread
From: AntiProxy @ 2006-11-27 17:15 UTC (permalink / raw)
  To: Danny; +Cc: netfilter

# netstat -s -t
Tcp:
    1027398 active connections openings
    11890681 passive connection openings
    44099 failed connection attempts
    973380 connection resets received
    10 connections established
    398498004 segments received
    480376567 segments send out
    8243661 segments retransmited
    18151 bad segments received.
    125830205 resets sent
TcpExt:
    289 invalid SYN cookies received
    54146 resets received for embryonic SYN_RECV sockets
    85 packets pruned from receive queue because of socket buffer overrun
    1017 ICMP packets dropped because they were out-of-window
    4 ICMP packets dropped because socket was locked
    6601012 TCP sockets finished time wait in fast timer
    22 time wait sockets recycled by time stamp
    11652 packets rejects in established connections because of timestamp
    2380302 delayed acks sent
    34526 delayed acks further delayed because of locked socket
    Quick ack mode was activated 286657 times
    8266 times the listen queue of a socket overflowed
    8266 SYNs to LISTEN sockets ignored
    66518316 packets directly queued to recvmsg prequeue.
    2047327 of bytes directly received from backlog
    1191423710 of bytes directly received from prequeue
    13171145 packet headers predicted
    16152546 packets header predicted and directly queued to user
    110781629 acknowledgments not containing data received
    96063476 predicted acknowledgments
    86569 times recovered from packet loss due to fast retransmit
    1325651 times recovered from packet loss due to SACK data
    2358 bad SACKs received
    Detected reordering 3212 times using FACK
    Detected reordering 379 times using SACK
    Detected reordering 2741 times using reno fast retransmit
    Detected reordering 7979 times using time stamp
    31360 congestion windows fully recovered
    31972 congestion windows partially recovered using Hoe heuristic
    TCPDSACKUndo: 286
    68272 congestion windows recovered after partial ack
    1129586 TCP data loss events
    TCPLostRetransmit: 519
    23481 timeouts after reno fast retransmit
    474514 timeouts after SACK recovery
    281322 timeouts in loss state
    2037777 fast retransmits
    70180 forward retransmits
    1324268 retransmits in slow start
    1343261 other TCP timeouts
    TCPRenoRecoveryFail: 17395
    386987 sack retransmits failed
    20642 times receiver scheduled too late for direct processing
    8445 packets collapsed in receive queue due to low socket buffer
    272157 DSACKs sent for old packets
    3594 DSACKs sent for out of order packets
    113395 DSACKs received
    389 DSACKs for out of order packets received
    34913 connections reset due to unexpected data
    188473 connections reset due to early user close
    173747 connections aborted due to timeout


On Mon, 2006-11-27 at 13:33 +0530, Danny wrote:
> Hey !
> 
> also : what does 'netstat -s -t' show ?
> 
> 
> Danny
> 
> AntiProxy wrote:
> > Dear all,
> >
> >
> > One of my servers was hit by a DDoS attack earlier today,
> > and the pattern was different to these i've seen before.
> >
> > netstat doesn't show any TCP or UDP connections in any state.
> >
> > however, TCPDUMP shows the following (i'm posting a few lines of
> > millions): 
> > 00:51:08.279876 IP 199.28.0.228.1136 > My.Victim.IP.1060: S 3605427625:3605427625(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.279905 IP My.Victim.IP.1060 > 199.28.0.228.1136: R 0:0(0) ack 3605427626 win 0
> > 00:51:08.279945 IP 202.227.64.177.1027 > My.Victim.IP.1277: S 361765779:361765779(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.279977 IP My.Victim.IP.1277 > 202.227.64.177.1027: R 0:0(0) ack 361765780 win 0
> > 00:51:08.280014 IP 205.22.254.231.1080 > My.Victim.IP.1036: S 1599573484:1599573484(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280043 IP My.Victim.IP.1036 > 205.22.254.231.1080: R 0:0(0) ack 1599573485 win 0
> > 00:51:08.280082 IP 202.238.89.100.1137 > My.Victim.IP.1158: S 3844747271:3844747271(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280111 IP My.Victim.IP.1158 > 202.238.89.100.1137: R 0:0(0) ack 3844747272 win 0
> > 00:51:08.280152 IP 210.16.241.153.1074 > My.Victim.IP.1273: S 2749255844:2749255844(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280182 IP My.Victim.IP.1273 > 210.16.241.153.1074: R 0:0(0) ack 2749255845 win 0
> > 00:51:08.280220 IP 202.37.165.2.1143 > My.Victim.IP.1106: S 1963715017:1963715017(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280250 IP My.Victim.IP.1106 > 202.37.165.2.1143: R 0:0(0) ack 1963715018 win 0
> > 00:51:08.280289 IP 211.225.4.65.1043 > My.Victim.IP.1031: S 1558151020:1558151020(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280426 IP 199.75.254.153.1258 > My.Victim.IP.1026: S 1190926252:1190926252(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280496 IP 199.250.149.61.1099 > My.Victim.IP.1111: S 2527588092:2527588092(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280633 IP 210.155.122.67.1078 > My.Victim.IP.1248: S 1669627316:1669627316(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280710 IP 199.43.54.188.1144 > My.Victim.IP.1167: S 4133488145:4133488145(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280908 IP 211.231.52.59.1100 > My.Victim.IP.1107: S 3438491552:3438491552(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.280976 IP 198.0.6.165.1172 > My.Victim.IP.1036: S 1294249773:1294249773(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.281114 IP 211.86.244.159.1268 > My.Victim.IP.1186: S 3158078860:3158078860(0) win 16384 <mss 1460,nop,[bad opt]>
> > 00:51:08.281189 IP 210.137.244.254 > My.Victim.IP: icmp 36: time exceeded in-transit
> > 00:51:08.281265 IP 202.93.103.38 > My.Victim.IP: icmp 36: 202.93.103.38 tcp port 1046 unreachable
> > 00:51:08.281334 IP 129.228.28.125.1135 > My.Victim.IP.1068: S 4066000806:4066000806(0) win 16384 <mss 1460,nop,[bad opt]>
> >
> > what does it tell you?
> >
> > the only thing that shows up in my syslog is the following:
> > Nov 27 05:52:30 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
> > Nov 27 05:52:30 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
> > Nov 27 05:52:32 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
> > Nov 27 05:52:32 iihs kernel: ll header: 00:50:fc:29:94:2d:00:14:f2:89:bb:1c:08:00
> > Nov 27 05:52:39 iihs kernel: martian source My.Victim.IP from 0.0.0.0, on dev eth0
> >
> > although my IPTABLES script should have logged the DDoS..
> >
> > following is a snippet of my IPTables script:
> >
> > $IPTABLES -F
> > $IPTABLES -F -t nat
> > $IPTABLES -F -t mangle
> > $IPTABLES -F -t filter
> > $IPTABLES -X SRC_FILTER
> > $IPTABLES -N SRC_FILTER
> > $IPTABLES -A INPUT -m state --state INVALID -j DROP
> > $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > $IPTABLES -A INPUT -m state --state NEW -p TCP --tcp-flags ! ALL SYN -j DROP
> >
> > # had this bit from before.. i just noticed it's in the FORWARD chain, so i doubt it does anything in my setup
> > $IPTABLES -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
> > $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
> > $IPTABLES -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
> > $IPTABLES -A FORWARD -d 216.133.73.152/32 -p tcp --syn -m limit --limit 20/minute -j ACCEPT
> >
> > #i added this yesterday during an attack, but it didn't do anything:
> > $IPTABLES -X syn-flood
> > $IPTABLES -N syn-flood
> > $IPTABLES -A syn-flood -m limit --limit 10/second --limit-burst 15 -j RETURN
> > $IPTABLES -A syn-flood -j LOG --log-prefix "SYN flood: "
> > $IPTABLES -A syn-flood -j DROP
> >
> > The system has one NIC with 24 virtual interfaces (24 IPs)
> > no NAT is being done, the public IPs are assigned directly to the interfaces.
> >
> > it runs Debian Sarge (Stable), 2.6.8-2-k7 kernel, IPTables v1.2.11-10 debian package
> >
> > any help would really be appreciated!
> >
> > Regards,
> >
> > AntiProxy
> >
> >
> >
> >   
> 



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Watched a DDoS attack for hours and couldn't do much :S
  2006-11-27  8:38 ` G.W. Haywood
@ 2006-11-27 17:16   ` AntiProxy
  2006-11-27 18:57     ` Taylor, Grant
  0 siblings, 1 reply; 7+ messages in thread
From: AntiProxy @ 2006-11-27 17:16 UTC (permalink / raw)
  To: G.W. Haywood; +Cc: netfilter

Actually, it's an external attack, apparently from a whole bunch of
compromised machines..

One thing i thought off, was to pipe tcpdump's output into a couple awks
and seds and generate IPTABLE rules on the fly..

let's see how this goes

On Mon, 2006-11-27 at 08:38 +0000, G.W. Haywood wrote:
> Hi there,
> 
> On Mon, 27 Nov 2006 AntiProxy wrote:
> 
> > One of my servers was hit by a DDoS attack earlier today,
> > and the pattern was different to these i've seen before.
> >
> > netstat doesn't show any TCP or UDP connections in any state.
> >
> > however, TCPDUMP shows the following (i'm posting a few lines of
> > millions):
> > [...]
> > what does it tell you?
> 
> Somebody is trying to spoof a machine on your network?
> 
> I'd have thought a reasonable box could drop 15k packets/second OK but
> you might need to put rules in the INPUT chain to drop everything from
> the offending IPs.  For this kind of thing I use a Perl script to scan
> the logs and insert rules into iptables in real time.  Its input is
> piped from syslog-ng.  It takes a bit of setting up but it's worth it.
> If there are large numbers (thousands) of attacking IPs you'll need to
> look at something like ipset as iptables will begin to creak a bit.
> 
> If this continues you might want to contact your upstream provider.
> They will want to help if they're at all reputable.
> 
> --
> 
> 73,
> Ged.
> 



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Watched a DDoS attack for hours and couldn't do much :S
  2006-11-27 17:16   ` AntiProxy
@ 2006-11-27 18:57     ` Taylor, Grant
  0 siblings, 0 replies; 7+ messages in thread
From: Taylor, Grant @ 2006-11-27 18:57 UTC (permalink / raw)
  To: Mail List - Netfilter

AntiProxy wrote:
> Actually, it's an external attack, apparently from a whole bunch of
> compromised machines..

Do you have any idea who initiated the attack and / or why?

> One thing i thought off, was to pipe tcpdump's output into a couple awks
> and seds and generate IPTABLE rules on the fly..

Something you might consider would be to look at either how the ULog daemon
works, or possibly NetLink (CONFIG_IP_NF_QUEUE) directly.  Either way, I
believe it would be possible to write a daemon that can have the kernel
communicate which packets it is seeing that are not already (explicitly)
processed by IPTables rules and then use a different method (NetFilter
APIs?) to dynamically update the firewall rule(s) on the fly.

I have no experience in this area, probably evident by using the wrong terms
/ names for the existing resources to communicate with the kernel.  However
I think there is at least a direction to go with this.  If you would like
help developing such, I'm willing to try to help.



Grant. . . .



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2006-11-27 18:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-27  6:36 Watched a DDoS attack for hours and couldn't do much :S AntiProxy
2006-11-27  7:59 ` Danny
2006-11-27  8:03 ` Danny
2006-11-27 17:15   ` AntiProxy
     [not found] <200611270803.kAR81k2Y030892@mail3.jubileegroup.co.uk>
2006-11-27  8:38 ` G.W. Haywood
2006-11-27 17:16   ` AntiProxy
2006-11-27 18:57     ` Taylor, Grant

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox