Re: GIDS, Intrusion Prevention: A Firewall by Any Other Name

["Marcus J. Ranum" <mjr () ranum com>]

Iván Arce wrote:
> IDS adopters on the other hand have gone a step
> further in their assumptions, here the rationale is that
> they can NOT stop  all the attacks, sometime somewhere
> there will be someone good enough to bypass the poorly
> configured firewall so here is ideas is "if I cannot stop them all
> at least I will try to be informed as soon as I detect a successful
> attack" (think a NIDS on the trusted side of the FW or a HIDS).
> So in my opinion adopting IDS technologies imply a conceptual
> change in term of what is expected from the firewall technology,
> the adopter is giving in to the idea of not being able to
> stop all the attacks.

I think that's a useful distinction, but in a lot of ways it's
also an implementation detail. When I say that firewalls/IDS/AV/VPN
are "really the same thing" I mean that the data flows should
look like approximately this inside:


input:
        if we've been told to encrypt it to someplace else {
                encrypt it and tunnel it //VPN
                GOTO input
        }

        if it came in on a VPN channel {
                decrypt and verify its origin // VPN
                if origin does not verify {
                        generate an alarm event //denied!
                        GOTO input
                }
                //fall through to...
        }

        if it's permitted {
                if we've been told to audit log contents {
                        if we know how to decode this stream
                                generate type specific audit event
                        else
                                generate audit event
                }
                if we've been told to scan for viruses and we know
                        how to decode this stream {
                        decode it and scan for viruses //AV
                        if we detect a virus {
                                generate an alarm event
                                block rest of session //denied!
                        }
                }
                if we've been told to do IDS {
                        apply known signatures for this type of stream //IDS
                        if we detect an attack {
                                generate alarm event
                                block rest of session //denied!
                        }
                        apply statistics (anomaly detection) if appropriate
                }
                GOTO input
        }

        if it's denied {
                if honeypot functionality is requested for this service {
                        interact with the remote system
                        if we've been told to do IDS {
                                apply IDS signatures
                                generate alarms if appropriate at
                                        reduced priority
                        }
                        record whatever useful interactions for audit
                }
                record transaction summary
                GOTO input
        }

        Implementing classical IDS with a flow like the above
is just a matter of putting 2 boxes in series and plugging different
policies into them, or configuring the first one right. ;)

mjr.
---
Marcus J. Ranum                         http://www.ranum.com
Computer and Communications Security    mjr () ranum com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards