[127406] in North American Network Operators' Group
Re: Very Strange - TCP SWEEP Alerts / Inconsistent with traffic on
daemon@ATHENA.MIT.EDU (khatfield@socllc.net)
Sun Jun 27 17:41:43 2010
Date: Sun, 27 Jun 2010 17:41:16 -0400 (EDT)
From: khatfield@socllc.net
To: "Matt Hite" <lists@beatmixed.com>
In-Reply-To: <AANLkTilJi7ulIwGtRqn4bg3lWeCemwn5dwRPr1mQwwX6@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Thanks Matt,=0A 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 prov=
ing it is occurring seems to be the primary issue we're running into at thi=
s point.=0A=0A-Kevin=0A=0A-----Original Message-----=0AFrom: "Matt Hite" <l=
ists@beatmixed.com>=0ASent: Sunday, June 27, 2010 5:36pm=0ATo: khatfield@so=
cllc.net=0ACc: nanog@nanog.org=0ASubject: Re: Very Strange - TCP SWEEP Aler=
ts / Inconsistent with traffic on system=0A=0AHi Kevin,=0A=0ASomeone may wa=
nt to throw RST traffic your way by spoofing their own=0Asource (as you) an=
d machine gunning TCP ACK or SYN packets to Internet=0Ahosts such as this A=
T&T customer. Just a nice way of throwing traffic=0Aat you in a fairly unde=
tectable manner.=0A=0AJust a guess,=0A=0A-M=0A=0AOn Sun, Jun 27, 2010 at 2:=
22 PM, <khatfield@socllc.net> wrote:=0A> Folks,=0A> =C2=A0We have a strang=
e situation occurring lately where we are getting some reports of TCP Sweep=
s from some one of our IP's, yet the IP is one of many specifically configu=
red for inbound traffic and do not emit outbound traffic unless for respons=
e. 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 rep=
orted has been under constant attack.=0A>=0A> Here is an example report we =
received from AT&T:=0A> 04:29:27 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=3D23,dp=
=3D1024,min=3D212.1.185.6,max=3D212.1.191.127,Jun27-04:21:01,Jun27-04:29:26=
) (USI-amsxaid01)=0A> 04:29:27 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=3D16,dp=
=3D3072,min=3D212.1.189.1,max=3D212.1.188.118,Jun27-04:21:15,Jun27-04:29:09=
) (USI-amsxaid01)=0A> 04:36:44 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=3D16,dp=
=3D1024,min=3D212.1.188.1,max=3D212.1.185.126,Jun27-04:29:51,Jun27-04:35:53=
) (USI-amsxaid01)=0A> 04:20:47 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=3D25,dp=
=3D1024,min=3D212.1.190.11,max=3D212.1.189.120,Jun27-04:12:37,Jun27-04:20:4=
0) (USI-amsxaid01)=0A> 04:20:47 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=3D18,dp=
=3D3072,min=3D212.1.189.3,max=3D212.1.186.118,Jun27-04:13:15,Jun27-04:20:37=
) (USI-amsxaid01)=0A> 04:12:36 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=3D34,dp=
=3D1024,min=3D212.1.191.8,max=3D212.1.191.121,Jun27-03:56:28,Jun27-04:12:29=
) (USI-amsxaid01)=0A> 04:12:36 x.x.x.x 0.0.0.0 [TCP-SWEEP] (total=3D28,dp=
=3D3072,min=3D212.1.186.6,max=3D213.244.176.119,Jun27-03:56:48,Jun27-04:11:=
45) (USI-amsxaid01)=0A> ------------------------=0A> Report from DK*CERT:=
=0A> If nothing else mentioned below, timezone is believed to be UTC+0200(C=
EST)=0A> Destination address(es): Adresser i nettene 130.225.16.0/22 og 130=
.225.2.128/25=0A>=0A> Security logs:=0A> #Jun 27 18:13:40 2010 .. Jun 27 18=
:58:13 2010=0A> # Scan from x.x.x.x affecting at least=0A> # 81 addresses t=
argeting TCP:1024, TCP:3072.=0A> #=0A> ------------------------=0A> I have =
removed our IP and replaced it with x.x.x.x. =C2=A0To 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 configu=
red on these IP's except where requests / responses flow through it.=0A>=0A=
> 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 thi=
s 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 thou=
ght 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 a=
ny sort of outbound scan traffic.=0A>=0A> Any ideas why this would be showi=
ng as a sweep? Our IDS systems do not scan requesting IP's originating syst=
ems. Any help is appreciated, we're simply trying to get to the bottom of t=
he reports.=0A>=0A> Kevin=0A>=0A>=0A>=0A
