lots of ACKs for DPT=1433

lots of ACKs for DPT=1433

[Olaf Zaplinski]

Hi,

I see lots of ACKs for DPT=1433 in my logs. Anyone else?

Any idea what is the reason for this?

Olaf

Re: lots of ACKs for DPT=1433

[Rob Sterenborg (Lists)]

On 04-08-16 12:46, Olaf Zaplinski wrote:
> Hi,
>
> I see lots of ACKs for DPT=1433 in my logs. Anyone else?
>
> Any idea what is the reason for this?
>
> Olaf

A lot of scans for a vulnerable MSSQL server.


-- 
Rob

Re: lots of ACKs for DPT=1433

[Olaf Zaplinski]

Am 2016-08-07 17:29, schrieb Rob Sterenborg (Lists):
> On 04-08-16 12:46, Olaf Zaplinski wrote:
>> Hi,
>> 
>> I see lots of ACKs for DPT=1433 in my logs. Anyone else?
>> 
>> Any idea what is the reason for this?
>> 
>> Olaf
> 
> A lot of scans for a vulnerable MSSQL server.

That would be true if that were SYN requests. But 90% of these requests 
or so are ACK requests.

Olaf

RE: lots of ACKs for DPT=1433

[André Paulsberg-Csibi (IBM Consultant)]

From the details you gave , it would be natural to assume you are talking about multiple sources sending traffic
to your Internet exposed IP's which would normally be some version of PORTSCANNING .
( Even if the packets are 90%-100% ACK packets , they can still be some attempt of portscanning )

In any case it would be helpful if you add some complete logfiles entries (10-20) , 
if you need you can just "MANGLE" your exposed IP's target but please leave the rest of the logfiles as original as possible .


Best regards
André Paulsberg-Csibi
Senior Network Engineer 
Fault Handling
IBM Services AS
andre.paulsberg-csibi@evry.com
M +47 9070 5988




-----Original Message-----
From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Olaf Zaplinski
Sent: 8. august 2016 10:16
To: netfilter@vger.kernel.org
Subject: Re: lots of ACKs for DPT=1433

Am 2016-08-07 17:29, schrieb Rob Sterenborg (Lists):
> On 04-08-16 12:46, Olaf Zaplinski wrote:
>> Hi,
>> 
>> I see lots of ACKs for DPT=1433 in my logs. Anyone else?
>> 
>> Any idea what is the reason for this?
>> 
>> Olaf
> 
> A lot of scans for a vulnerable MSSQL server.

That would be true if that were SYN requests. But 90% of these requests 
or so are ACK requests.

Olaf
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: lots of ACKs for DPT=1433

[Olaf Zaplinski]

Am 2016-08-08 11:35, schrieb André Paulsberg-Csibi:
> In any case it would be helpful if you add some complete logfiles
> entries (10-20)

Okay, here are some examples:


Aug  4 14:39:59 binky kernel: [2609148.849905] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=109.170.163.174 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=117 ID=26474 DF 
PROTO=TCP SPT=4886 DPT=1433 WINDOW=65535 RES=0x00 ACK URGP=0
Aug  4 14:40:10 binky kernel: [2609159.677601] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=109.170.163.174 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=117 ID=2554 DF 
PROTO=TCP SPT=3381 DPT=1433 WINDOW=65535 RES=0x00 ACK URGP=0
Aug  4 14:40:16 binky kernel: [2609165.361891] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:2d:55:53:08:00 SRC=95.9.252.66 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=115 ID=31945 DF 
PROTO=TCP SPT=58633 DPT=1433 WINDOW=65340 RES=0x00 ACK URGP=0
Aug  4 14:40:17 binky kernel: [2609166.281294] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=172.87.192.33 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=121 ID=24321 DF 
PROTO=TCP SPT=5171 DPT=1433 WINDOW=65535 RES=0x00 ACK URGP=0
Aug  4 14:40:19 binky kernel: [2609168.447578] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=104.247.220.211 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=121 ID=3380 DF 
PROTO=TCP SPT=5240 DPT=1433 WINDOW=65535 RES=0x00 ACK URGP=0
Aug  4 14:40:38 binky kernel: [2609187.895943] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=23.228.81.116 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=117 ID=22249 DF 
PROTO=TCP SPT=1716 DPT=1433 WINDOW=65535 RES=0x00 ACK URGP=0
Aug  4 14:40:42 binky kernel: [2609192.177811] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:2d:55:53:08:00 SRC=58.96.177.123 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=232 ID=28264 DF 
PROTO=TCP SPT=55416 DPT=1433 WINDOW=65392 RES=0x00 ACK URGP=0
Aug  4 14:40:47 binky kernel: [2609196.469551] iptables tarpit IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=172.87.192.33 
DST=109.75.188.214 LEN=41 TOS=0x00 PREC=0x00 TTL=121 ID=29753 DF 
PROTO=TCP SPT=5171 DPT=1433 WINDOW=65535 RES=0x00 ACK URGP=0


Interesting is that the number of those log entries have decreased a lot 
meanwhile. On 6th of August there were only 3 instead of 4664 the day 
before:

Aug  6 04:26:17 binky kernel: [2745127.016759] iptables-geoip-cn IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=61.191.59.179 
DST=109.75.188.214 LEN=40 TOS=0x04 PREC=0x00 TTL=113 ID=4715 DF 
PROTO=TCP SPT=1144 DPT=1433 WINDOW=65535 RES=0x00 ACK URGP=0
Aug  6 04:26:17 binky kernel: [2745127.016816] iptables-geoip-cn IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=61.191.59.179 
DST=109.75.188.214 LEN=40 TOS=0x04 PREC=0x00 TTL=113 ID=4716 DF 
PROTO=TCP SPT=1144 DPT=1433 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Aug  6 04:26:26 binky kernel: [2745136.157327] iptables-geoip-cn IN=eth0 
OUT= MAC=00:f1:70:00:58:f0:fc:fb:fb:21:67:58:08:00 SRC=61.191.59.179 
DST=109.75.188.214 LEN=40 TOS=0x04 PREC=0x00 TTL=113 ID=14158 DF 
PROTO=TCP SPT=1144 DPT=1433 WINDOW=65535 RES=0x00 ACK FIN URGP=0


Yesterday there were none.

Olaf

RE: lots of ACKs for DPT=1433

[André Paulsberg-Csibi (IBM Consultant)]

I adjusted logs to keep only "smallest crital" data left :)

[iptables tarpit]
Aug  4 14:39:59 IN=eth0 SRC=109.170.163.174 LEN=41 TTL=117 ID=26474 SPT=4886  DPT=1433 ACK
Aug  4 14:40:10 IN=eth0 SRC=109.170.163.174 LEN=41 TTL=117 ID=2554  SPT=3381  DPT=1433 ACK
Aug  4 14:40:16 IN=eth0 SRC=95.9.252.66     LEN=41 TTL=115 ID=31945 SPT=58633 DPT=1433 ACK
Aug  4 14:40:17 IN=eth0 SRC=172.87.192.33   LEN=41 TTL=121 ID=24321 SPT=5171  DPT=1433 ACK
Aug  4 14:40:19 IN=eth0 SRC=104.247.220.211 LEN=41 TTL=121 ID=3380  SPT=5240  DPT=1433 ACK
Aug  4 14:40:38 IN=eth0 SRC=23.228.81.116   LEN=41 TTL=117 ID=22249 SPT=1716  DPT=1433 ACK
Aug  4 14:40:42 IN=eth0 SRC=58.96.177.123   LEN=41 TTL=232 ID=28264 SPT=55416 DPT=1433 ACK
Aug  4 14:40:47 IN=eth0 SRC=172.87.192.33   LEN=41 TTL=121 ID=29753 SPT=5171  DPT=1433 ACK

Aug  6 04:26:17 IN=eth0 SRC=61.191.59.179   LEN=40 TTL=113 ID=4715  SPT=1144 DPT=1433 ACK
Aug  6 04:26:17 IN=eth0 SRC=61.191.59.179   LEN=40 TTL=113 ID=4716  SPT=1144 DPT=1433 ACK FIN
Aug  6 04:26:26 IN=eth0 SRC=61.191.59.179   LEN=40 TTL=113 ID=14158 SPT=1144 DPT=1433 ACK FIN

From what I can see these logs show , you have 2 things happening :
the last from AUG 6 seem like a normal session that is no longer responding ( maybe timed-out )
but this can also be some host who tried to scan that port but seems more like some accidental
access attempt .

The first log entries are pretty sure some kind of port-scan , even if the packets are ACK without SYN .
Maybe the attackers are looking for systems behind old non-stateful FW who only block SYN packets and
allows any other flaged packets into their systems assuming they are "safe" ...
... most likely ( and you can try ) if you grep for "SRC=109.170.163.174" you will most likely find
3-8 tries , and maybe 1 or 2 with SYN first .



Best regards
André Paulsberg-Csibi
Senior Network Engineer 
Fault Handling
IBM Services AS
andre.paulsberg-csibi@evry.com
M +47 9070 5988

RE: lots of ACKs for DPT=1433

[Olaf Zaplinski]

Am 2016-08-08 13:14, schrieb André Paulsberg-Csibi:
> I adjusted logs to keep only "smallest crital" data left :)

Hmm, I think I should filter that a bit. ;-)

> From what I can see these logs show , you have 2 things happening :
> the last from AUG 6 seem like a normal session that is no longer
> responding ( maybe timed-out )

No outbound connections to TCP 1433 here, and no inbound either.

> Maybe the attackers are looking for systems behind old non-stateful FW
> who only block SYN packets and
> allows any other flaged packets into their systems assuming they are 
> "safe" ...
> ... most likely ( and you can try ) if you grep for
> "SRC=109.170.163.174" you will most likely find
> 3-8 tries , and maybe 1 or 2 with SYN first .

Actually that have been 53 connections, berhaps because I am tarpitting 
instead of rejecting.

Olaf