102: Intrusion Detection System -- Final Report
This project was one of a pair aimed at improving network security.
(The other concerned the possibility of
scanning
for compromised machines,
which led to our introduction of the ESISS system.)
The aim of the project was to produce a pilot system, which could give
us experience in setting up and operating an IDS, and might provide useful
guidance for any future development of such a system.
The project's home page has links to the
presentations, to the snort and
suricata home pages, and to this
report.
How?
The project was kicked off in mid-2014. After some preliminary
searching, snort was picked as the
most likely candidate for a pilot system. It's under active development,
there's a good and responsive mailing list, and there are regular rule
updates available. A Development meeting
presentation summarised the state to date.
More investigation and some initial hand-configuration led on to a
"proper" lcfgication, which turned out to be rather less straightforward
than was hoped. However, it did produce a working pilot implementation,
and generated some impressions which were included in another
Development meeting progress
presentation in October 2014.
That meeting concluded that we shouldn't invest much more effort at
the present time. Since then the system has been left to run on the
principal edge routers, just to get a feel for its impact and potential
usefulness.
Some comments on snort
(See also the October Development
meeting presentation.)
It might have been interesting to consider
suricata as an alternative.
However, that would be better done in a separate project, where it could
be more easily controlled and accounted for.
Where next?
The current implementation is still very much a pilot system. A few things
would need to happen before it could be said to be a full service:
- If it's to be worth putting in the effort to convert the current pilot
to a full service then some thought would need to be given to how the
reports are formatted,
distributed and acted upon. There would be still quite a lot
of work required to tidy up all the loose ends, and it's not worth spending
the effort unless it's likely that we would really use the results.
- The current reporting mechanism is pretty basic. It's just
enough of a proof-of-concept to establish that the whole IDS thing
might be useful. Something better tailored to our actual needs, whatever
they might be, would be needed.
It doesn't currently incorporate any knowledge of the actual end
systems, which can result in lots of false positives. If a better
mechanism knew that a machine was a Linux box, for example,
it could ignore any reports
of Windows-specific issues. On a more homogeneous network the
admin could just tune the enabled rules rather better so that only relevant
ones were turned on, but that's not really a possibility for us.
- We're using a personal "oinkcode" to download the rules. We should look
into the possibility of an institutional one instead. We might also want
to consider the paid-for rules, though the pricing structure doesn't seem
particularly attractive for the way we operate.
The free ruleset lags quite a bit behind the paid
one. We wouldn't have seen the shellshock reports until a week or two
after the probes started, for example,
by which time it would have been too late.
Listening out for vulnerability reports seems rather more effective.
- The logs are rather noisy, as a result of the external scans. Those are
supposed to be whitelisted, but it doesn't seem to be particularly
effective. It might be better just to have the reporting tool ignore them.
- Everything's going into syslog on tycho, from where the current reports are
generated. Someone with the right kind of knowledge could probably get our
other existing tools there to produce more useful summaries.
- snort has a notion of "inside" and "outside", which is not
really quite flexible enough for us. Do we put Conf110 inside or outside,
for example, to detect threats against it or from it against the "inside"?
- There's still some fragility (doesn't always start properly, doesn't
always download the rules properly) which would need to be investigated and
ironed out of a production system.
- There might be some merit in giving alternatives (e.g.
suricata) a thorough look before
committing to a snort service. It seems to have ruleset-compatibility
with snort, has a nicer configuration syntax, and an active user and
development community.
Overall, I would say that the
"scanning"
project produced a rather more useful outcome.
Accounting
The project clocked up about two weeks of effort overall.
$Id: FinalReport.html,v 1.20 2015/01/29 13:59:02 gdmr Exp $