RE: ssh and ids

From: Murtland, Jerry (MurtlandJ_at_Grangeinsurance.com)
Date: 06/21/04

  • Next message: Tom Arseneault: "RE: possible causes of source and destination ip from external network" 
    To: "'Runion Mark A FGA DOIM WEBMASTER(ctr)'" <mark.runion@us.army.mil>, focus-ids@securityfocus.com
Date: Sun, 20 Jun 2004 22:35:04 -0400

    Well, your email has various blocks that should be addressed:

    Lets suppose the attacker is mildly sophisticated, and after making the
    initial assault roots the box and installs a secure backdoor or two. Is
    there any IDS capable of isolating data it cannot read, except to monitor
    authorized port usage of a system or group of systems?

    It sounds like what you are looking for is an IPS. An IDS is not meant to
    act on traffic that has been filtered. An IDS's purpose is only to give you
    a more usable format of reporting of deep packet inspection (marketing bla
    bla) so that you can act on the data that is being sent. If it's something
    that shouldn't be going on, it's up to you to make the blocks. Not the IDS.
    If you have an IPS in place, you can make calls to specific data and headers
    being sent in suspicious or non-legitimate traffic to stop it without using
    a human interface as a proxy.

    Not to complicate the question, but when the attacker is using portal gates
    and all
    communications traffic is encrypted in normal channels how can an IDS
    participate?

    An IPS, an IDS, whatever you're using, you can't filter encrypted traffic.
    That's the entire purpose of encryption. The only thing you can filter is
    the initial call for authentication to your network before the encrypted
    tunnel is established. And obviously, this is what you would want to do.
    You're looking to verify legitimate authentication calls. Some time will
    also need to be spent reviewing the logs to look for multiple attempts
    (brute force attacks) to authenticate to your network via unrecognized
    portals or sources. IPS and IDS logs will show this type of activity. IPS
    will block if you setup thresholds for this type of activity. You will need
    to develop rules which block sources identifying brute force attempts. This
    is an IPS function, not IDS.

    Monitoring normal traffic patterns seems a bit slow for detection.

    You're absolutely right. Trend analysis is probably the most reliable, yet
    not the most efficient. It's slow and resource intensive. We will be
    deploying an IPS in our network very soon. Although IDS has great
    technology in place, I think it was step 1 toward a more proactive solution,
    the IPS. I don't however think that the IPS is the golden ticket. There is
    still quite a bit of development to really work out the bugs such as
    blocking legitimate traffic at times. But you have to weigh the risks on
    what you are trying to protect. Being that you have a military address, I
    hope this isn't traffic from a SCIF.

    Jerry J. Murtland, CISSP
    Sr. Data Security Analyst
    Information Security Dept

    -----Original Message-----
    From: Runion Mark A FGA DOIM WEBMASTER(ctr)
    [mailto:mark.runion@us.army.mil]
    Sent: Friday, June 18, 2004 2:19 PM
    To: focus-ids@securityfocus.com
    Subject: ssh and ids

    Lets suppose the attacker is mildly sophisticated, and after making the
    initial assault roots the box and installs a secure backdoor or two. Is
    there any IDS capable of isolating data it cannot read, except to monitor
    authorized port usage of a system or group of systems? Not to complicate
    the question, but when the attacker is using portal gates and all
    communications traffic is encrypted in normal channels how can an IDS
    participate? Monitoring normal traffic patterns seems a bit slow for
    detection.

    -
    Mark Runion

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

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

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

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

  • Next message: Tom Arseneault: "RE: possible causes of source and destination ip from external network"
    • Quantcast