White dot for spacing only
The Dice Project


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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"?
  7. 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.
  8. 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.


FinalReport.html,v 1.20 2015/01/29 13:59:02 gdmr Exp


 : Units : Infrastructure : Projects : 102-IDS 

Mini Informatics Logo - Link to Main Informatics Page
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh
Spacing Line