EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)
Stephen Satchell
list at satchell.net
Mon Jun 23 06:14:24 UTC 2008
Brandon Galbraith wrote:
> On 6/23/08, Nathan Ward <nanog at daork.net> 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