Re: ssh and ids

[Bamm Visscher <bamm.visscher () gmail com>]

Real quick point. Don't assume the backdoor is going to be listening
on the server. It's a simple task to instead install a backdoor that
makes an outbound connection to a central server that lets the
attacker issue commands on the compromised host. This comm channel
could be encrypted (reverse ssh) or even use a http proxy.

With that said, I agree that prevention (Firewalls, IPS, regular
audits, patch management, etc), is an important factor in network
defense. But I think the thread here is meant to be focused on
detection. We aren't talking so much about attack detection, but the
true capability to be able to detect compromise (either as it happens
or after it has taken place) and more importantly, having the
information and capability to respond quickly to it. Although it would
be nice to be able to detect a compromise as it occurs (or prevent
it), we can't assume that will be the case 100% of the time.  To
augment that fact, we need to define practices that will help us
identify 'after access events'. Whether it's an FTP session and the
downloading of a hax0r toolkit, or a covert comms channel.

When I first started out, the organization I worked for spent a lot of
time analyzing telnet connections. We did this because at the time, it
seemed the attackers first step after compromising a host, was to
create a backdoor account, and then stroll through the front door
(yes, telnet is now considered a 'bad thing' but at the time, it was
the common place). Some of the more interesting things we would do was
at the '100 ft level', looking at a connection as a whole versus the
data inside. For instance, most people can't type fast enough to get
more than one character in a telnet packet, but if you cut 'n paste
some source code thru that connection, all of a sudden the byte/packet
ratio goes thru the roof. So, we could query our connections DB,
identify suspicious sessions, and then, since we logged the pcap, we
could look more closely and determine if the connection was indeed
malicious.  When DNS exploits initially became all the rage, we were
concerned our IDS that didn't decode DNS was missing zero-day attacks.
 So, from the 100 ft level, we would query our cnxs DB for sessions to
port 53 and where the source sent more the 1000 bytes during the
duration of the connection.  Again, once we identified those
suspicious connections, we would use the actual packet captures to
determine if there was a true attack (and if it was successful).

Telnet has long been replaced by secure shell (damn you encryption),
but that doesn't mean you still can't take a look from the 100 ft
view. For instance, it seems like it would
be trivial to determine which connections were used as a command
terminal, and which ones were actually tunneling other data thru them
(X or scp). In a cmd connection, I could also fairly accurately
identify which packets contained the carriage return and probably
figure out the number of chars each command contained (of course tab
completion could b0rk some of this).  If the internal IP addr
initiated the connection, but the external (server) IP addr appeared
to fit the template of a controlling terminal, I could theoretically
tag the connection as a possible reverse ssh backdoor.

There is a catch. Doing this 100ft analysis doesn't come cheaply.
First you have to collect the data and then you have to find the time
to mine it.  Personally, I view it as money well spent, but other
organizations may not find it so. A few of us on this list have
blabbered about the concept of Network Security Monitority (NSM)
before. Richard Bejtlich has a book [0] on the subject coming out
soon.  And with sguil [1], we are trying to make analysis at this
level more effecient (the above DNS example is actually a standard
query in sguil).

Bammkkkk

[0] http://www.taosecurity.com/books.html
[1] http://sguil.sf.net

On Tue, 22 Jun 2004 10:11:03 -0500, Frank Knobbe <frank () knobbe us> wrote:
> On Mon, 2004-06-21 at 07:43, Gary Flynn wrote:
> > The Juniper/Netscreen IDP comes with a feature called Profiler
> > that you can set to discover and alert on new port or host
> > appearances. You set it to discover whats normal, then turn on
> > alerting.
>
> Before we're diving too far into the list of IDS/IPS that can profile
> traffic, I just want to remind everyone that a good firewall
> configuration does exactly that; it creates a profile and prevents
> unauthorized connections.
>
> It seems these days we're quick to jump to IDS/IPS systems to have them
> detect and prevent unauthorized and/or abnormal traffic. It seems we're
> forgetting that a correctly configured firewall does the same thing. It
> prevents backdoors into web servers, it prevents web servers to
> establish sessions to the outside.
>
> The IDS needs to catch those conditions where for example an attacker
> launches a cryptcat shell from the web server to the outside, and I
> agree that the IDS needs to know the normal traffic profile for that
> purpose. But guess what... your firewall (which is blocking said
> shell-shovel-attempt) can detect it as well. Not just that, it can
> prevent it!
>
> It seems nowadays we tend to augment lax and leaky firewalls with IPS
> systems when we should really go back and tighten our firewall rule
> sets.
>
> Now that I'm done ranting, let me ask you: How do you detect a listening
> port on a rooted server when no one is able to send packets to that
> port?
>
> (Seems like nmap would do the trick, and is cheaper than profiling IDS
> appliance.)
>
> Cheers,
> Frank
>
>
>
>
> signature.asc - 1K


-- 
http://sguil.sf.net

---------------------------------------------------------------------------

---------------------------------------------------------------------------