EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)

Stephen Satchell list at
Mon Jun 23 06:14:24 UTC 2008

Brandon Galbraith wrote:
> On 6/23/08, Nathan Ward <nanog at> wrote:
>> Do 'normal' web hosting providers allow customer created scripts to create
>> TCP sessions out to arbitrary things?
> Doesn't PHP provide a fair amount of TCP functionality that can be used
> simply by uploading the code you need to your shared web hosting account?

PHP, Perl, Python all provide the ability to generate Socket connections 
via TCP and UDP.  At the Web hosting company I used to work at, they ran 
a "mostly open" policy when it came to outbound connections.  This was 
particularly true of co-located-equipment and leased-equipment 
customers, much more so than the shared-equipment accounts.

When I monitored traffic, I found that the most common port for outgoing 
TCP connections was on port 80.  Investigation of TCP port-22 outbound 
traffic showed that most of that traffic was SCP and tunneled RSYNC 
traffic to single locations.

We found our share of bad apples, such as the the guy who set up a 
tunnel between a leased server and his location in Texas, for the 
purpose of running a spammer Web site with the payload coming to the Web 
host's IP addresses instead of the spammer operators' addresses.

Of more interest to me, though, was the monitoring of traffic on our 
currently unallocated IP addresses; *lots* of woodpeckering on a wide 
variety of ports.  The reason I originally set up a server that would 
accept packets from all currently-unused IP addresses was to minimize 
the ARP flooding that occurred when someone would hammer on an IP 
address that wasn't in use.  Once that was in place, it was a trivial 
matter to monitor abusive traffic and add to the local access control 
list as necessary when requests to the network operators of the source 
of abusive traffic would not take steps to remove the people who were 
not RFC 1855-compliant.

The default server's logs proved to be an excellent way for us to detect 
compromised on-site dedicated servers, particularly those servers 
infected with mal-ware designed to "probe the immediate neighborhood" first.

More information about the NANOG mailing list