Re: [IPCop-devel] After The Install

Ah IDS - my favourite topic :-)

> First off, to properly monitor your firewall, you must stay up on
> different types of attacks. Keeping the Intrusion Detection System up
> to date is one way of doing this. If you monitor the IDS logs, they
> will be identifying the type of attack and classifying it for you.
>
> This is already part of IP Cop.
The one thing that really got to me about SW was the fact that the IDS
reporting
looked good, but really didnt allow you to do much more than list a
historical
view of history.

IDS is still a human intensive act. And to run IDS properly and maintain
proper
security it is very costly. Firstly you should keep a rolling log of all
your packets
going past your sensor, extract all of the packets that match the rulesets.
Once
you have an intrusion attempt you have your security team work back through
the logs to determine the attempt. As a result this is generally only used
in
military (only some!) and large corporations that like to keep secrets.

Runing Snort on a low end firewall device with lowend user knowledge will
only get half the job done. But in defensive half a job is better that none,
in particular if it detects you are being used as an attack platform
(Nimba/CR/Lion etc)
then you are at least ware of the issue!


> > If there's Snort log analysis tools, let's get them in there as well,
> > and automate them.
> >
> > Example:
> > If a bunch of ports are being sniffed in a short time-frame, *OR* in
> > too "regular" (timing-wise) a pattern, IPCop should do a reverse DNS
> > lookup on the IP address and email the admin about it with
> > suggestions on how to contact a person in authority over that
> > machine.  They admin can, perhaps, "allow" some IPs to be doing
> > things regularly.  IE, if they are port-forwarding to an ORANGE
> > web-server, and somebody has a cron job to check their web-site
> > daily, that should not, after the admin says so, notify them every
> > time it happens.
>
> Well, much of the time, those IP addresses are spoofed and don't belong
> to the machine that the attack is coming from.

Actually its not trivial to spoof IP connections, so more likely than not
I would expect a TCP connection to be accurate. Not to say that the
attack originated from there, but the device was probably used as a
springboard (anon-proxy, compromized host)

Now there is a number of systems out there that can be used to collect
results sets and get results for:

http://www.dshield.org/howto.html
https://predictor.securityfocus.com/
MyNetwatch man is another

Personally I like the SANS one. To me this would be a nice to have.

> There are infinite ways to attack your machine. We know about a finite
> number of them. Thinking we can know about all of them is naive. That
> is why you must monitor your logs. To look for patterns. Humans are
> good at that, machines are lousy at it. Machines are only good at
> detecting patterns once they have been taught to do so by a human that
> noticed that pattern. Machines don't catch new patterns well at all.
Very true - at least the honey hots volunteers help update the rules :-)

Gareth