IDS mailing list archives
Re: ssh and ids
From: Bamm Visscher <bamm.visscher () gmail com>
Date: Tue, 22 Jun 2004 16:35:42 -0500
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 --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- ssh and ids Runion Mark A FGA DOIM WEBMASTER(ctr) (Jun 18)
- Re: ssh and ids Adam Powers (Jun 21)
- Re: ssh and ids Martin Roesch (Jun 21)
- Re: ssh and ids Tony Carter (Jun 22)
- Re: ssh and ids Jason (Jun 22)
- Re: ssh and ids Adam Powers (Jun 22)
- Re: ssh and ids Martin Roesch (Jun 23)
- Re: ssh and ids Christian Kreibich (Jun 24)
- Re: ssh and ids Gary Flynn (Jun 21)
- Re: ssh and ids Frank Knobbe (Jun 22)
- Re: ssh and ids Bamm Visscher (Jun 23)
- Re: ssh and ids Frank Knobbe (Jun 23)
- Re: ssh and ids Frank Knobbe (Jun 22)
- <Possible follow-ups>
- Re: ssh and ids Ron Gula (Jun 21)
- RE: ssh and ids Wozny, Scott (US - New York) (Jun 21)
- RE: ssh and ids Omar Herrera (Jun 21)
- RE: ssh and ids Matthew F. Caldwell (Jun 22)
- RE: ssh and ids Frank Knobbe (Jun 22)
- RE: ssh and ids Peter_Schawacker (Jun 22)
- Re: ssh and ids Adam Powers (Jun 22)
- Re: ssh and ids David W. Goodrum (Jun 22)
- RE: ssh and ids Thierry Evangelista (Jun 23)