Very Strange - TCP SWEEP Alerts / Inconsistent with traffic on system
khatfield at socllc.net
khatfield at socllc.net
Sun Jun 27 21:41:16 UTC 2010
That's what we believe we're seeing at this point but we're trying to convince our upstream. :) We have seen this in the past but proving it is occurring seems to be the primary issue we're running into at this point.
From: "Matt Hite" <lists at beatmixed.com>
Sent: Sunday, June 27, 2010 5:36pm
To: khatfield at socllc.net
Cc: nanog at nanog.org
Subject: Re: Very Strange - TCP SWEEP Alerts / Inconsistent with traffic on system
Someone may want to throw RST traffic your way by spoofing their own
source (as you) and machine gunning TCP ACK or SYN packets to Internet
hosts such as this AT&T customer. Just a nice way of throwing traffic
at you in a fairly undetectable manner.
Just a guess,
On Sun, Jun 27, 2010 at 2:22 PM, <khatfield at socllc.net> wrote:
> We have a strange situation occurring lately where we are getting some reports of TCP Sweeps from some one of our IP's, yet the IP is one of many specifically configured for inbound traffic and do not emit outbound traffic unless for response. Specifically, these are ddos mitigation IP's so they are attacked fairly frequently. With this in mind, the last few days one of the IP's being reported has been under constant attack.
> Here is an example report we received from AT&T:
> 04:29:27 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=23,dp=1024,min=22.214.171.124,max=126.96.36.199,Jun27-04:21:01,Jun27-04:29:26) (USI-amsxaid01)
> 04:29:27 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=16,dp=3072,min=188.8.131.52,max=184.108.40.206,Jun27-04:21:15,Jun27-04:29:09) (USI-amsxaid01)
> 04:36:44 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=16,dp=1024,min=220.127.116.11,max=18.104.22.168,Jun27-04:29:51,Jun27-04:35:53) (USI-amsxaid01)
> 04:20:47 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=25,dp=1024,min=22.214.171.124,max=126.96.36.199,Jun27-04:12:37,Jun27-04:20:40) (USI-amsxaid01)
> 04:20:47 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=18,dp=3072,min=188.8.131.52,max=184.108.40.206,Jun27-04:13:15,Jun27-04:20:37) (USI-amsxaid01)
> 04:12:36 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=34,dp=1024,min=220.127.116.11,max=18.104.22.168,Jun27-03:56:28,Jun27-04:12:29) (USI-amsxaid01)
> 04:12:36 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=28,dp=3072,min=22.214.171.124,max=126.96.36.199,Jun27-03:56:48,Jun27-04:11:45) (USI-amsxaid01)
> Report from DK*CERT:
> If nothing else mentioned below, timezone is believed to be UTC+0200(CEST)
> Destination address(es): Adresser i nettene 188.8.131.52/22 og 184.108.40.206/25
> Security logs:
> #Jun 27 18:13:40 2010 .. Jun 27 18:58:13 2010
> # Scan from x.x.x.x affecting at least
> # 81 addresses targeting TCP:1024, TCP:3072.
> I have removed our IP and replaced it with x.x.x.x. To be a bit more clear, this is a reverse-proxy IP address. This IP is in a NAT type configuration where it is sent back to filtering clusters. No outbound traffic is configured on these IP's except where requests / responses flow through it.
> I know a year or two ago there was a bug in Cisco IOS that would report a sweep when extreme packet load occurred or a burst hit. At the time of this report we saw an attack burst to around 310,000PPS on this IP (inbound). Is it simply likely the networks reporting have several IP's being used in the attack and that is what they are seeing? That's what we originally thought but the port scans throw that theory off... Our security team has gone through all PCAPs during the mentioned time frames and we are not showing any sort of outbound scan traffic.
> Any ideas why this would be showing as a sweep? Our IDS systems do not scan requesting IP's originating systems. Any help is appreciated, we're simply trying to get to the bottom of the reports.
More information about the NANOG