Re: what is the good way against reverse telnet?

[Joachim Schipper <j.schipper () math uu nl>]

On Mon, Jan 31, 2005 at 01:54:15AM +0000, Monty Ree wrote:
> Hello, all.
>
> I have operated firewalled linux webhosting server.
> But only input traffic is secured and outbound traffic is totally opened by 
> firewall.
>
> So some attacker attacked these servers using reverse telnet.
> So is there any method in order to protect against reverse telnet?
> Any method or solutions without prohibitting outbound traffic?
>
> Thanks in advance.

Dear Monty,

there are a couple solutions to this, however, none of them are perfect.
In essence, a knowledgeable person will always be able to bypass your
protections.

Of course, the real problem is not reverse telnet - the problem is that
the attacker succeeded in getting a telnet application running on the
server. I will re-state this - the real problem is that the attacker
executed something nasty on the server.

That being said, disallowing any and all outbound connections from ports
that your machine does not have any business sending on is always a good
idea, particularly for servers. (I don't know if you call this
'prohibiting outbound traffic' - basically, you allow a small,
controlled portion of all outbound traffic to pass. On a dedicated
server, anything not from port 80 can be blocked - if you are also
running a couple client programs, like ntpd (highly recommended by the
Apache docs, and rightly so), you can open some port/destination
combinations on a case-by-case basis).

It is possible to use something like Snort or Snort-inline
(www.snort.org in both cases, I believe) to check for telnet traffic on
unusual ports, and (in the second case) block it. But it's not possible
to filter out everything - if you filter out telnet, they'll use SSH; if
you filter out SSH, and manage not to shoot yourself in the foot in the
process, they'll create a custom CGI program and talk to that (phpShell
is a good example - look it up on freshmeat.net), or any sort of
encapsulated protocol. It's quite hopeless, really. (This doesn't mean
it's not worth the trouble, it'll make succesfully using a compromised
server is much more difficult, especially when trying to avoid being
logged - however, not being broken into in the first place is a much
better idea.)

In short, I guess this means you'll have to look into protecting the
servers... what are you running? Apache? How did the attackers get in? A
poorly written CGI application? Is Apache running in a chroot() jail?
Are you using su_exec? Properly? Do you use mod_security, and have you
configured it? Basically, some more info would be nice... and I'm afraid
a simple solution blocking reverse telnet won't do. Sorry... security is
always more difficult than that.

                Joachim