lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200403100204.11390.fulldisc@ultratux.org>
From: fulldisc at ultratux.org (Maarten)
Subject: Comcast using IPS to protect the Internet from their home user clients?

On Tuesday 09 March 2004 17:42, TroyC wrote:
> Yep noticed very similar things as well during scanning.  At the time I
> thought it might be due to the time of day or such.
>
> I also noticed another behavior::: Different IP blocks based [seemingly]
> upon OS. My netgear rtr/ap gets a 24.x.x.x, however, my debian fw gets a
> 64.x.x.x adder... I spun up a different linux box and rcvd 64.x.x.x while a
> win2k vmware session on that same linux box rcvd a 24.x.x.x  ::: seems to
> be picking something up on the dhcp requests...

That's a weird coincidence.  I'm in Europe, and the cable-ISP known here as 
"Chello/UPC" gives out almost the same ranges, and although it is not 
reproduceable I have had my IP changed from 62.x.x.x to 24.x.x.x, and vice 
versa. Also, I have very strong evidence they do filter in- and egress 
traffic:  Although forbidden by the AUP I did run some harmless services 
(ssh, dns) on my gateway box. They were quick to block that, and they did 
that by somehow rewriting any inbound (syn) traffic to port 80.  The way I 
found that out was that when performing a remote portscan of my box it had 
ALL ports closed. But when I opened a port 80 listener the same portscan 
revealed all the ports that were open from the onset (22,25,53) as open, in 
addition to the port 80.  As support for this, on the gateway box iptables 
indeed logged portscans directed to port 80 uniquely which makes sense only 
when such redirections actually were done.  And lo and behold, telnetting to 
port 25 indeed actually gave me an... apache welcome banner.

In hindsight, I understood that this also interfered with my ability to use 
tools from that connection, and it thus cleared up some issues I previously 
had attributed to "general badness / weirdness" with their connection.

Soon after discovering this I ditched them (as I needed to run my own servers 
anyway) and I'm very glad my new ISP can be trusted to not fsck up something 
on my line without telling me upfront.  I'm not personally against ISPs 
filtering, that would fix a lot of problems with compromised boxes, but they 
should allow for non-clueless people to still run their servers, for instance 
by a configurable setting in the ISPs' service pages.

Maarten

> ps::: I may have the adders ass-backwards the linux boxes might have gotten
> 64.x.x.x
>
> TroyC
>
> On Monday 08 March 2004 18:28, Frank Knobbe wrote:
> > This post should probably have gone to SF-PenTests, but since it is more
> > of a discussion item, I thought about Full Disclosure, the list for vuln
> > info and everything else :)
> >
> >
> > Anyhow, I noticed that certain vulnerability scans, for example scans
> > using Nikto and similar tools, when run from a Comcast address show a
> > different behavior than when they are run from a clear, uncontrolled
> > Internet connection (i.e. corporate T-3). In fact, it appears like
> > Comcast has an Inline-IDS (some call it an IPS ;) sitting on its wires,
> > filtering out certain signatures and blocking subsequent access for a
> > short period of time. For example, scan progresses, then hangs
> > inexplicably, then resumes, trips a sig, and hangs again. At the same
> > time, the same scan from a non-Comcast address continues without any
> > hick-ups. Targets have been ruled out (up and running, verified at the
> > same time from different addresses), and connectivity to the rest of the
> > net remains. It's looks like just the src-dst address pair is used so
> > that all connections from a Comcast src to that particular dst are
> > blocked for a short moment (1-5 minutes).
> >
> > Has anyone else noticed that? Is Comcast actually attempting to keep all
> > those worms'n'viruses of their clients away from the Internet?
> >
> > How many other ISP's are known to use IPS's inline to protect themselves
> > from the 'Net, or protect the 'Net from themselves?
> >
> > Regards,
> > Frank (routing all scans via VPN through corporate hosts ;)
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ