Looking for packets from three particular subnets

Published: 2014-01-31
Last Updated: 2014-01-31 21:14:55 UTC
by Chris Mohan (Version: 1)
18 comment(s)
A reader wrote in reporting seeing a large amount odd activity from three subnets across a large number of disparate networks he managed. Addresses from these subnets have been generating between 100,000 - 500,000 inbound connections a day apiece, primarily targeting port 80 however, he had also seen a very small amount of inbound port 25 and port 443 as well. Sadly he wasn't able to capture any packets.
 
The Subnets in question are:
 
5.254.116.32-5.254.116.63 ("AppLayer_Anti-DDoS_Hosting" located in Russia)
94.23.97.196-94.23.97.199 ("GAMESPROTECT AntiDDoS Network" located in Germany)
5.254.105.16-5.254.105.31 ("WooServers" located in Germany)
 
If you have any packet captures of this traffic or know why theses subnets are making apparently unsolicited, random connections, please write in and let us know!
 

Chris Mohan --- Internet Storm Center Handler on Duty

18 comment(s)

Comments

Chris, this may seem off topic at first, but what happens when you reverse these IPs? I am thinking this may be a case of dynamically-assigned reverse DNS entries being used by botnets. Here's an example of results from robtex's blacklist from one of the IPs you've listed when reversed. Just a thought.
https://www.robtex.com/ip/63.116.254.5.html#blacklists
I've seen traffic to my /16 from a total of 4 hosts spread across all three of the listed subnets over the past few weeks. The initial packets are sourced from tcp/25 with destinations of tcp/80. Within a few hours, we see very large numbers of SYN packets from the source IP address. I don't have any real ideas about the purpose, but sourcing the original packets from tcp/25 seems pretty odd.
This could be a backdoor from any number of trojans, including Zeus. This might be helpful: http://www.adminsub.net/tcp-udp-port-finder/control
Reminds me of packets seen from 190.115.23.35 (BZ/Belize/ddos-guard.net) for several hours:
Jan 24 09:39:57 SRC=190.115.23.35 DST=5.9.x.y LEN=61 TOS=0x00 PREC=0x00 TTL=121 ID=27 DF PROTO=UDP SPT=53 DPT=37313 LEN=41
Jan 24 09:39:57 SRC=190.115.23.35 DST=5.9.x.y LEN=61 TOS=0x00 PREC=0x00 TTL=121 ID=0 DF PROTO=UDP SPT=53 DPT=37313 LEN=41
Jan 24 09:39:57 SRC=190.115.23.35 DST=5.9.x.y LEN=61 TOS=0x00 PREC=0x00 TTL=121 ID=27 DF PROTO=UDP SPT=53 DPT=37313 LEN=41
Jan 24 09:39:57 SRC=190.115.23.35 DST=5.9.x.y LEN=61 TOS=0x00 PREC=0x00 TTL=121 ID=0 DF PROTO=UDP SPT=53 DPT=37313 LEN=41
Jan 24 09:39:57 SRC=190.115.23.35 DST=5.9.x.y LEN=61 TOS=0x00 PREC=0x00 TTL=121 ID=27 DF PROTO=UDP SPT=53 DPT=37313 LEN=41

Possibly it is backscatter from an attack against that IP, spoofing my server's IP as the source. Possibly something more nefarious though, unfortunately I only have the packet headers.
Observing the same behavior from 178.32.13.108 in the last hour.
Same here, getting it from178.32.13.108 . It started about 3.5 hours ago.

I sent a email to the abuse@ovh.net, not response yet.

At the moment, our firewall is holding it back the brunt of it and we have the pipe to spare fortunately.
I'm on Cogent's backbone and will be reporting it to them if I don't hear anything back soon.

From my sonicwall logs:

Feb 1 17:59:58 1102grand id=firewall sn=0017C565342E time="2014-02-01 17:59:36" fw=38.104.86.118 pri=5 c=0 m=760 msg="TCP handshake violation detected; TCP connection dropped" n=5579626 src=178.32.13.108:12550:X1: dst=x.x.x.199:80:X3:shared-hosting-2.xyz.net note="Handshake Timeout"
Feb 1 18:00:09 1102grand id=firewall sn=0017C565342E time="2014-02-01 18:00:11" fw=38.104.86.118 pri=5 c=0 m=760 msg="TCP handshake violation detected; TCP connection dropped" n=5580170 src=178.32.13.108:42974:X1: dst=x.x.x.207:80:X3: note="Handshake Timeout"
Feb 1 18:00:46 1102grand id=firewall sn=0017C565342E time="2014-02-01 18:00:48" fw=38.104.86.118 pri=5 c=0 m=760 msg="TCP handshake violation detected; TCP connection dropped" n=5582062 src=178.32.13.108:43313:X1: dst=x.x.x.199:80:X3:shared-hosting-2.xyz.net note="Handshake Timeout"
Feb 1 18:01:24 1102grand id=firewall sn=0017C565342E time="2014-02-01 18:01:26" fw=38.104.86.118 pri=5 c=0 m=760 msg="TCP handshake violation detected; TCP connection dropped" n=5584036 src=178.32.13.108:2562:X1: dst=x.x.x.199:80:X3:shared-hosting-2.xyz.net note="Handshake Timeout"
Feb 1 18:02:04 1102grand id=firewall sn=0017C565342E time="2014-02-01 18:02:00" fw=38.104.86.118 pri=5 c=0 m=760 msg="TCP handshake violation detected; TCP connection dropped" n=5586152 src=178.32.13.108:20143:X1: dst=x.x.x.207:80:X3: note="Handshake Timeout"
Feb 1 18:02:34 1102grand id=firewall sn=0017C565342E time="2014-02-01 18:02:35" fw=38.104.86.118 pri=5 c=0 m=760 msg="TCP handshake violation detected; TCP connection dropped" n=5587659 src=178.32.13.108:57797:X1: dst=x.x.x.207:80:X3: note="Handshake Timeout"
Feb 1 18:03:10 1102grand id=firewall sn=0017C565342E time="2014-02-01 18:03:11" fw=38.104.86.118 pri=5 c=0 m=760 msg="TCP handshake violation detected; TCP connection dropped" n=5589364 src=178.32.13.108:58326:X1: dst=x.x.x.200:80:X3:shared-hosting-1.xyz.net note="Handshake Timeout"
Seeing loads of port 80 traffic from 178.32.13.108 (FR) to port 80.
We've been enormous amounts of backscatter from several
European ISPs for the last two weeks.

IPs we've seen from OVH are:
94.23.97.196
37.187.195.49
5.254.116.46
5.254.105.21

178.32.13.108

This last has generated 80+M on port 80
in 5 hours since midnight UTC Feb 2
I don't have packet captures from 178.32.13.108 (GAMESPROTECT Inc AntiDDos Network), but I do have netstat records. All I see is half-open SYN_RECV, so I assume there's not much info in those packets and the IP address is spoofed (it wouldn't be a good advert for an anti-DDos network). Don't normally need SYN cookies, but will leave on if the eedjits continue to misbehave.
Oh, in case my above reply wasn't clear, so far as I can see the subnets mentioned above are the /targets/ and this is a massive DDoS attack, presumably launched from a botnet, and using large numbers of web servers for a SYN reflection attack.

To avoid suffering collateral damage, if you're using netfilter, SYN cookies should help, and reducing the value of net.netfilter.nf_conntrack_tcp_timeout_syn_recv . To actually avoid participating in the attack, probably lowering net.ipv4.tcp_synack_retries to 2 would reduce the "amplification factor". I haven't tested it, but possibly using iptables -m connlimit --connlimit-upto 50 would effectively mean your server is no longer useful to the attackers.

Diary Archives