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

Keywords: packets Scan Activity
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

Anonymous

Jan 31st 2014
1 decade ago

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.

Anonymous

Feb 1st 2014
1 decade ago

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

Anonymous

Feb 1st 2014
1 decade ago

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.

Anonymous

Feb 1st 2014
1 decade ago

Observing the same behavior from 178.32.13.108 in the last hour.

Anonymous

Feb 1st 2014
1 decade ago

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"

Anonymous

Feb 2nd 2014
1 decade ago

Seeing loads of port 80 traffic from 178.32.13.108 (FR) to port 80.

Anonymous

Feb 2nd 2014
1 decade ago

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

Anonymous

Feb 2nd 2014
1 decade ago

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.

Anonymous

Feb 2nd 2014
1 decade ago

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.

Anonymous

Feb 2nd 2014
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives