lann...@runbox.com dijo [Fri, May 12, 2017 at 04:31:11PM +0200]: > Hi, Hi,
> I'm performing installation for a "secure" web app. OK, but I must first point to a minor contradiction here: Your mail's subject talks about incident response, but you talk here about "performing installation". Those are two very different (although, yes, conceptually related) issues. Before going further to your choice of applications, this first step requires understanding what is that you are installing: Which kind of web app? What framework is it built on? Which language does it use? If you are building your application, start by assessing the environment you are building against: Look for known vulnerabilities (i.e. using the CVE database¹), try to assess how frequent and how deep the impact of said vulnerabilities are. Check how long has it taken for issues to be accepted / addressed / solved by the authors. ¹ https://cve.mitre.org/ Of course, try to choose the framework with the smallest attack surface (i.e. if your application can do with a minimalistic framework instead of a full-featured stack, it will probably be better). On the other hand, if you are installing a known program (either free or non-free), you should do the same for the program itself, as well as other programs addressing the same application domain. That's for installation, of course. But your mail goes on to address what your mail subject initially suggests: > I'm starting with psad, and suricata. > > Now I'd like to install Sguil or Snorby or any alternative for packet > capturing. My problem is that I have to compile myself which we know is not > the best solution for security. Keep in mind that for the next release cycle you will probably also have to self-support Snort², as it will most likely be dropped out of testing a couple of weeks from now (#861842). Also, Snorby falls in the case I mentioned above: I quite like developing with Ruby on Rails... But make sure to properly protect the system that will/would host Snorby, as Rails has too large an attack surface for security-sensitive stuff. ² https://tracker.debian.org/pkg/snort The issue with Snorby or Sguil is not compiling them (as they are not compiled - Ruby and Tcl scripts respectively), but supporting them (it's up to you to track and update new upstream versions). It *might* not be much of a burden, but again, check the projects' history; some pieces of software are a manitenance nightmare. > Does any alternative exists? > > Also, Which tool can mail me if there are any alerts? > > Any other tools that I should consider? There are many, many tools that can help you here - but they all depend on you being skilled using them. Intrusion prevention/detection and incident response are not really tasks that can be fully automated. I suggest you take a look at several of the packages that 'apt search intrusion detection' give you; you will find several quite old (although good!) tools as aide or snort; you will find many tools for file-based IDS/IPS (and it seems you are looking for a network-based one). To be honest, a long time ago I did have an IDS system, but in the end I ditched it — Profiling what's "normal" and "abnormal" activity, understanding what appears in your correlator, needs a lot of site-specific, knowledge-intensive work. A useful IDS will also demand a high CPU load, and strategic placement in your network infrastructure. Of course, it depends on your network's needs; given that I'm "just" the network administrator for a smallish research institute with few network-exposed services, we decided after some months the risks were not worth me devoting an almost full time to tracking reported incidents. The difference between IDS and IPS is that the first one reports what has just happened, and the second actually attempts to block attacks from succeeding. An IPS is way more powerful, but demands way more attention - because it can be abused leading to DoS. Anyway, that's the point of view of a small-scale sysadmin who *thinks* does some things right :-]
signature.asc
Description: Digital signature