[146247] in North American Network Operators' Group
Re: XO blocking individual IP's
daemon@ATHENA.MIT.EDU (Leigh Porter)
Tue Nov 8 03:51:27 2011
From: Leigh Porter <leigh.porter@ukbroadband.com>
To: "Blake T. Pfankuch" <blake@pfankuch.me>
Date: Tue, 8 Nov 2011 08:52:38 +0000
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C846D95307F@SHSBS.shenrons-house.local>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
So if you want to launch a DoS attack against a specific IP address you sp=
oof TCP3389 SYNs to networks single homed to XO and they will null it for =
you.
--=20
Leigh
On 8 Nov 2011, at 04:36, "Blake T. Pfankuch" <blake@pfankuch.me> wrote:
> Oh yes! Good lord I about went insane with this. I was working with a =
customer single homed to cBeyond. I spent 3 hours on the phone with cBeyo=
nd to figure out what was going on, it looks like a broken route. Come to=
find out it was an XO "security null". The engineer on the phone from cB=
eyond said to me "Well, I have learned 2 things today. 1, XO nulls for 's=
ecurity purposes' at random. 2, I am no longer shocked by any ridiculous =
policy I will ever come across again."
>=20
> In this case majority traffic was going from cBeyond to anywhere (via XO=
) and being eaten, however it was VERY tough to diagnose as all parties in=
volved assumed this would not be occurring between source and destination =
without good public documentation or at least any record of this happening=
to someone else. Also I guess we all assumed that major bandwidth player=
s don't filter anything.
>=20
> I personally think its good on paper, but very bad real life until there=
is a way to notify the end customer of the violation quickly. This issue=
literally took 3 full weeks to figure out what was going on. Yes this wo=
rks great in a colo datacenter as you have the customer contact info (hope=
fully). But in the case where my customers provider was having the IP fil=
tered by their transit it was hell to diagnose. In my case the customer h=
ad a single infected machine that was making outbound connections on TCP33=
89 in the range of about 100 connections every 5 minutes and because of th=
is was entirely being "security nulled".
>=20
> Blake
>=20
> -----Original Message-----
> From: clayton@haydel.org [mailto:clayton@haydel.org]=20
> Sent: Monday, November 07, 2011 7:43 PM
> To: nanog@nanog.org
> Subject: XO blocking individual IP's
>=20
>=20
> I'm hoping someone has had the same experiences, and is further toward a=
resolution on this than I am. About 6 months ago, we noticed that XO was =
blackholing one specific IP out of a /24. Traces to that IP stopped on XO=
's network, traces to anything else out of the block went through fine.
> XO finally admitted that they had a new security system that identifies =
suspicious traffic and automatically blocks the IP for 30 minutes. We had=
to get the IP in question "whitelisted" by their security guys. The traf=
fic was all legit, it was just on a high port # that they considered suspi=
cious.
>=20
> There have several more cases like this, and XO has not been forthcoming=
with information. We're either looking to be exempted from this filtering=
or at least get a detailed description of how the system works. I'm not =
sure how they think this is acceptable from a major transit provider.
> Anybody else had similar problems?
>=20
>=20
> Clayton Haydel
>=20
>=20
>=20
>=20
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email=20
> ______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email=20
______________________________________________________________________
