|It looks like someone is spoofing your address to make these connections. This is a common technique to either DDoS these targets, or DDoS you with the reply traffic. Some devices will flood a network with SYN-ACKs if you don't reply with a Reset (try to configure your firewall to not just drop the packets, but to send a reset back. this may reduce the attack volume)||
Dec 20th 2016
9 months ago
Thank you for your fast reply. |
I will try to force an IP change. Hope it will help.
Dec 24th 2016
9 months ago
|Did you consider setting syn-cookies if available on this device ?||
Dec 28th 2016
9 months ago
|As I work in Co-Sharing Work place. T do blogging and writing. But when i try to reach more sites of blog or articles, some show we don't allow 2 account on same IP and some times they show your IP is blacklisted. I mailed them but they didn't respond. Any solution for this. Maybe other colleagues in this working place done something terrible on these sites. but is there anyway by that i can Get one new unique ip by that i can access those sites.||
Dec 30th 2016
9 months ago
I wrote a long and detailed reply yesterday and again today, but neither make it through. Attempt #3...|
It is similar to Mirai. We have been seeing that pattern of SynAcks also since 18th/September - first seen from CloudFlare (CF):
Timestamp (UTC) Action I/F SrcIP [:Port] -> DstIP[:Port] Proto [Flags]
2016-09-18 07:56:59 block in on wan from 126.96.36.199:80 -> MyIP:32840 tcp flags:SA
2016-09-18 08:03:42 block in on wan from 188.8.131.52:80 -> MyIP:32840 tcp flags:SA
2016-09-18 08:14:57 block in on wan from 184.108.40.206:80 -> MyIP:32840 tcp flags:SA
Found: 3 Displayed: 3
First seen: 2016-09-18 07:56:59 Active: 0:17:58
Last seen : 2016-09-18 08:14:57 ( 121 days, 14:22:46 ago )
1) We made *no* outbound connections to that CF IP at that time.
2) The destination port on our side (32840) was extremely common for exactly this pattern of SynAck behaviour (Found 3,848 messages)
3) Obviously they are reflected SA's from someone else spoofing our IP - given point (1) above and the very unlikely proposition that CF would be performing this type of behaviour intentionally.
Volume started very low:
35 from 18-31st September (23 of which arrived on 2 separate days on 21st and 23rd),
29 in October (25 on the last day of the month) and then it ramped up significantly to...
1194 in November and
2590 in December.
Then it stopped using port 32840 and switched to random ports (maybe they saw your post;) - but the ack# remains static.
Up until 1 Nov this is the breakdown:
Value % Count
220.127.116.11 39.06% 25 <- GoDady hosted site
18.104.22.168 7.81% 5
22.214.171.124 4.69% 3
126.96.36.199 4.69% 3 <- First seen from here.
188.8.131.52 4.69% 3
184.108.40.206 4.69% 3
220.127.116.11 4.69% 3
18.104.22.168 3.13% 2
22.214.171.124 3.13% 2
126.96.36.199 3.13% 2
188.8.131.52 1.56% 1
184.108.40.206 1.56% 1
220.127.116.11 1.56% 1
18.104.22.168 1.56% 1
22.214.171.124 1.56% 1
126.96.36.199 1.56% 1
188.8.131.52 1.56% 1
184.108.40.206 1.56% 1
220.127.116.11 1.56% 1
18.104.22.168 1.56% 1
22.214.171.124 1.56% 1
126.96.36.199 1.56% 1
188.8.131.52 1.56% 1
We labelled it MiraiV2, because if you examine the acknowledgement number you may notice a very interesting pattern.
The Ack# can be calculated directly from _our_ IP address with this formula:
SynAck Ack# = ( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4
Note: o1.o2.o3.o4 is our IP address, not the source IP.
We would expect a MiraiV1 SynAck response from a spoofed packet to have Ack# = Mirai + 1, not (o1 -1)...
[Mirai version 1 is simply seq # (o1 << 24) + (o2 << 16) + (o3 << 8) + o4, as detailed at line 225 in mirai/bot/scanner.c in github's copy]
Hence we believe this traffic serves 2 purposes:
1) (D)DoS the web server at target1 (CF in this case) using our spoofed IP address with the intention of also...
2) ...(D)DoS'ing the real IP owner (us) with SA traffic. Why else would the Ack be pre-calculated from your IP address?
Perhaps a 3rd purpose is to distract both parties (CF and us) so as to hide their real intent/location for a longer period.
If you calculate the ack from your IP, you can create a suricata/snort rule for it thus:
alert tcp any any -> any any (ack=( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4; msg:"MiraiV2 scan";....)
Contrast that with the MiraiV1 rule:
alert tcp any any -> any any (seq=( o1 << 24) + (o2 << 16) + (o3 << 8) + o4; msg:"MiraiV1 scan";....)
FYI we have noted the following other variants, each using slightly modified sequence or acknowledgement numbers calculated directly from our IP:
Version Calculated Seq/Ack #
v1 (o1 << 24) + (o2 << 16) + (o3 << 8) + o4
v2 ( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4
v3 ( (o1 - 1) << 24) + (o2 << 16) + ((o3 - 64) << 8) + o4
v4 ( (o1 - 12) << 24) + (o2 << 16) + (o3 << 8) + o4
v5 (o4 << 24) + (o2 << 16) + (o3 << 8) + o4
(I doubt my alignment will carry through - apologies for non-alignment but outside my control)
Most recently we have witnessed a more adventurous manipulation:
v6 ( bitflip( (v1 >> 16 ) + 1 ) << 16
We have seen many more where the lowest 16 bits were all 0, a very unlikely scenario for most TCP stacks, and clearly a calculated value.
We live in interesting times.
Jan 17th 2017
8 months ago