[Snort-sigs] Documentation for Rule 488 INFO Connection Close d MSG from Port 80

Sean Batt sean at ...1796...
Sun Dec 21 19:21:02 EST 2003

Hello Intrusion Detectors,

On Sat, 20 Dec 2003, Adams, Samuel (contractor) wrote:
> Curious about your comment, I connected to several "normal" (I have no idea
> what normal means in this or really any context) web servers on port 80. 
> I attempted to grab a banner with the following command:
> get http/1.1
> While some returned an informative banner and some did not - without
> exception the connections ended with "Connection closed by foreign host." Am
> I missing something here? Were you thinking of some other way to telnet to a
> web server and grab a banner? Or am I connecting to abnormal web servers? 

I'm surprised this has to be explained. Its the telnet client program that
produces the string "Connection closed by foreign host." To confirm, run
strings on your telnet binary. In case you're wondering, if you do a
strings on your telnetd daemon you won't find the string. The string
doesn't appear in my webserver binary and I doubt it appears in yours.

$ strings /usr/bin/telnet | grep 'foreign host' 
Connection closed by foreign host. 
$ strings /usr/sbin/in.telnetd | grep 'foreign host'
$ strings /opt/apache/bin/httpd | grep 'foreign host'

So the string is generated on whichever host the telnet client is run. How
can this string possibly occur in a from_server tcp flow to $EXTERNAL_NET
port 80? Perhaps if you were accessing a web server with and archive of
this thread? Well, that's not anomalous traffic. In fact, asking Google,
there would seem to be 29900 hits on "Connection closed by foreign host"
on the web and 20300 in Google Groups.

OK, if there was a shell running on port 80 on www.evil.org (i.e. part of
$EXTERNAL_NET) someone already inside your perimeter (i.e. on $HOME_NET)
could telnet to it and get a shell. Of course, closing that connection
wouldn't trigger the rule. However, if the person inside your perimeter
used the shell on www.evil.org to telnet elsewhere, then at last, the rule
is triggered when that telnet session inside a telnet session is closed.

But what if the user of the shell on www.evil.org port 80 used ssh instead
of telnet? Ftp? Compiled a rootkit? Ran an irc client or server? Modified
their telnet client (remember its on www.evil.ors where the user may have
full control) to not match "Connection closed by foreign host."?

It strikes me that what this rule really should be looking for is that
telnet is used on a port 80 at all. I can't imediately see how one would
code a rule to do this, perhaps watching for a telnet options negotiation
on a nonstandard port might go some way, but then evil.org may not be
using telnetd to start their shell in which case perhaps no options would
be negotiated. (Actually, some testing seems to indicate that telnet
options are only processed when the telnet port, 23, is used).

I think its easier to just delete rule 488 :-)

Sean.Batt at ...1797...
IT Manager, RSSS ANU
tel: +61 2 612 53296

More information about the Snort-sigs mailing list