Alex Scoble's IT Notes - An Information Technology Blog

Forget about the bomb, the real danger is cyber warfare

One of the most dangerous things that our government is doing right now is the collection of unknown open computer vulnerabilities. Cyber weapons can be launched from anywhere in the world with very low cost, are difficult to determine who constructed or launched them and can do significant damage to our infrastructure.

When we opened the gates to their use as a weapon of war with STUXNET and Operation Olympic Games, we in effect sent all of our troops out to battle without leaving anyone to defend the homeland.

A much more effective strategy would have been to work with software developers to get those vulnerabilities closed and to make sure that our sensitive and critical computer systems were well defended against these types of attacks.

We denied Iran from getting the bomb for a while and instead gave them a brand new weapon that is far riskier to us because of the ease of which it can be used and the inability to attribute attacks to the real aggressors that launch them.

A good starting point for researching Security Information and Event Management (SIEM) tools/services

Recently, I've been doing research on tools for log management and SIEM (Security Information and Event Management). As anyone who's ever been part of selecting an enterprise can testify, it's quite the daunting task.

Enterprise tools are BIG, as in they have a footprint larger than a brontasaurus, typically require a lot of work to get them set up to where they are useful and usable and they aren't any good unless someone (sometimes a small team is required) is managing them on a daily basis. Figuring out which tool best meets your needs is just as large of an endeavour.

Sometimes it can be hard to figure out just where to start, so you do some Google searches trying to find what SIEM tools are on the market, and maybe you do some searches for open source products that are up to the task and if you are lucky, you'll hit on one of Dr. Anton Chuvakin's blog posts on the subject.

He is definitely an expert in the field and currently works at Gartner doing analysis for them on the subject.

You'll also notice, if you pay close attention, that he's got a great sense of humor (and apparently likes Cognac).

Some notable blog posts of his that I think are required reading to anyone who is looking to purchase a SIEM tool are:

Top 10 criteria for a SIEM? - He goes against his better instincts and writes an informative blog post on excellent criteria, in my opinion, for beginning your assessments of the various SIEM tools

On choosing a SIEM - Here he provides some questions that a security analyst, business exec or IT manager should ask before they even begin looking for a SIEM...the questions are quite insightful and get to the heart of the matter of "do we really need this functionality?" and, more importantly, "do we have the resources to support it and make it successful?"

The myth of SIEM as "analyst in a box" - A good blog post in his series on how not to choose a SIEM. Basically, it boils down to if you don't have a security analyst or analysis team on staff already, you better get one before deploying a SIEM or your effort will be a complete failure.

Happy reading!

Linux would not have protected the Iranians against Stuxnet

Interesting discussion going on over at Google+ about the ramifications of Stuxnet and Flame. 

One part of the conversation is completely *facepalm*/smh (shaking my head) worthy, though. Someone brought up the extremely ludicrous notion that Linux would have protected the Iranians against Stuxnet and Flame. Linux totally would not have given the Iranians any extra protection.

The Stuxnet attacks are highly sophisticated and targeted and were able to get through every layer of the Iranian infrastructure to get embedded within the centrifuge controls. Flame, at least as far as I can tell, may have been used to provide the reconnaissance needed in order to build Stuxnet. It wouldn't have mattered what types of computers and OSes the Iranians used. The attackers would have just found vulnerabilities in any of them and developed exploits accordingly.

These hacks were very difficult to defend against and would have required a very thorough "defense in depth" strategy with a dedicated staff of security analysts to monitor and analyze network, OS and application logs and health. Even then, given the fact that spies were involved, It would have been an uphill battle to stop these attacks from succeeding.

There are certainly advantages that Linux gives to organizations within datacenters. Protecting them against highly advanced and targeted threats that exploit unknown weaknesses is not one of them, in my opinion.

Configuring iptables to log network traffic

For security as well as debugging purposes, it's a good idea to log the inbound, outbound, invalid and dropped packets that flow through the network interfaces on your linux systems. This is part one of a series with the rest, such as how to configure rsyslog.conf, to come later.

I was having problems getting iptables to log packets like I wanted, so I did some research on Google and found this post by Toast Research that detailed a good method for building your iptables modularly to allow for logging of packets.

Then I modified what they had done and came up with my own file and here it is. It is set up to allow port 80 through as well as ICMP pings, SSH connections, syslog messages and traffic from your Puppet server.

Just do 'nano /etc/sysconfig/iptables' when logged in as root (using 'sudo su -' of course) to modify your file to do what you want it to do.

The three digit numbers are there to allow for automated building of iptables files using DevOps systems like Puppet or Chef. The benefit to that is that you'd manage the iptables file at the enterprise level and these systems keep an audit trail of changes made and also ensure that systems stay properly configured. If someone were to change an iptables file managed by one of the DevOps systems, the DevOps system will revert to the proper file. That's the power of DevOps.

As you can see, the file is broken up into modules with the header defining what those modules are and the various rules either accept, log, drop or send packets further on down the chain.

# 001
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:invaliddrop - [0:0]
:loginaccept - [0:0]
:logoutaccept - [0:0]
:logdrop - [0:0]

# 002
# Accept all loopback connections
-A INPUT -i lo -j ACCEPT

# 003
# Forward all invalid packets to invaliddrop
-A INPUT -m state --state INVALID -j invaliddrop

# 004
# Forward all established connections to loginaccept
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j loginaccept

# 005
# Forward all icmp packets to loginaccept-A INPUT -p icmp -j loginaccept

# 006
# Forward these allowed input rules to loginaccept
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j loginaccept
-I INPUT -p tcp --dport 514 -s <your ip range here>/24 -j loginaccept
-I INPUT -p udp --dport 514 -s <your ip range here>/24 -j loginaccept
-I INPUT -p tcp --dport 8140 -s <your puppet server here> -j loginaccept
-I INPUT -p tcp --dport 61613 -s <your puppet server here> -j loginaccept

# 007
# Accept these rules without logging or forwarding them to loginaccept for logging
-I INPUT -m state --state NEW,ESTABLISHED -p tcp --dport 80 -j loginaccept

# 008
# Cleanup rule
-A INPUT -j logdrop

# 009
# Allow outbound loopback traffic
-A OUTPUT -o lo -j ACCEPT

# 010
# Forward all outbound traffic to logoutaccept
-A OUTPUT -j logoutaccept

# 011
# Drop all invalid packets (invaliddrop chain)
-A invaliddrop -j LOG --log-level 4 --log-prefix "IPTablesInvDrop: "
-A invaliddrop -j DROP

# 012
# Log accepted incoming packets at a rate of 2 per minute (loginaccept chain)
-A loginaccept -m limit --limit 2/min -j LOG --log-level 4 --log-prefix "IPTablesInAccept: "
-A loginaccept -j ACCEPT

# 013
# Log accepted outgoing packets at a rate of 6 per hour(logoutaccept chain)
-A logoutaccept -m limit --limit 6/hour -j LOG --log-level 4 --log-prefix "IPTABLESOutAccept: "
-A logoutaccept -j ACCEPT

# 014
# Drop all blocked packets (logdrop chain)
-A logdrop -j LOG --log-level 4 --log-prefix "IPTABLESDropped: "
-A logdrop -j DROP
COMMIT

Customize as needed.

Thoughts on Stuxnet and Operation Olympic Games

The New York Times ran a story yesterday about how President Obama ordered further attacks on Iran's uranium processing infrastructure using the Stuxnet virus. The attacks were part of Operation Olympic Games which was started under the previous George W Bush administration.

These attacks have serious ramifications for world politics in general and for the computer security community. The following are my thoughts on what some of those effects might be.

1. This story officially tells the world that the US has an extremely sophisticated cyber attack capability. The number of exploits and the complexity of the chain they created had not been seen before in the wild. This sets a precedent akin to us dropping the first atomic bomb on Hiroshima. No, not in the scope of the damage done, but in the level of seriousness of the attack. This is likely to set off a new "arms race" between countries and other organizations to create even more advanced cyber attacks.
2. Our government is playing a very dangerous game by performing these attacks. They have given other would be cyber warriors, rogue states, terrorists, etc. a blueprint on how to circumvent all but the most robust defenses (and even then, it would be difficult to defend against something like this). The attack used cannot currently be defended against by most corporations, networks and infrastructure in the US. If someone wanted to do harm to the US and thought that physical damage was the only way to do it, they know now that a similar level of damage can be done using computers. How long will it be before we see a serious terrorist/rogue state cyber attack against vital infrastructure or economic centers?
3. It takes a bite out of the use of Stuxnet by security professionals as an example of what organizations in the US have to defend against because no other cyber attack organization has demonstrated this level of sophistication, however, now that the blueprint is out there, it's only a question of time before others start duplicating what Stuxnet did and raising the bar of what is possible.
4. The deployment of Stuxnet which uses so many vulnerabilities that were previously unknown and thus not patched shows that there are some in the US government who think it's more important to keep dangerous vulnerabilities available to them in the wild versus helping to close these gaps for everyone. This should make security researchers very nervous and anger security professionals.
5. One "good" thing about this attack is that shows everyone involved with cyber security or system administation that we have a long way to go to build more secure systems and that we can't afford to wait on efforts to improve security of our vital infrastructure. The cost to improve might be high, but the costs of not doing so are much higher.
6. I question the wisdom of the New York Times in doing the research and publishing any of this information. In many ways, shedding light on this operation does grave harm to our national interests and greatly increases the risks to US citizens. This operation was obviously highly classified and should have stayed a secret for many years to come. Although it does occur to me that this probably could not have been leaked without some help from the Obama administration. Which raises further questions about why they would jeopardize public safety by releasing the information necessary to write this story.

We certainly live in "interesting" times. I just hope that this doesn't cause an outbreak of cyber war that would be catastrophic to people all over the world.

Ever wanted to know how secure a Linux password file, with hashed passwords using SHA-512 and salt, is? I think this is a good answer: http://security.stackexchange.com/questions/4687/are-salted-sha-256-512-hashes-still-safe-if-the-hashes-and-their-salts-are-expos Pretty damn secure.

Problems sending OSSEC logs to rsyslog

Pulling OSSEC logs into syslog is really a mess. It doesn't format stuff at all how a syslog client would.

For instance, it buries the agent name in the message text instead of reporting it as the system name, which instead gets reported as the OSSEC server name that got the logs in the first place.

Plus it ranks everything as MEDIUM in syslog terms regardless of how they are ranked within the OSSEC logs.

So a priority 1 (very low) OSSEC event gets prioritized the same as a priority 10 (high) event.

This is all making me think that syslog just isn't all that great for use with log analysis tools in a heterogeneous environment.

Although it does seem possible to get rsyslog to change the way it handles certain kinds of logs...I'll have to do some digging to see if I can find instructions for doing this with OSSEC.

**Update: My friend Mike recommends http://www.ossec.net/doc/syntax/head_ossec_config.syslog_output.html?highlight=syslog#syslog_output for a possible solution.

Installing LogAnalyzer and rsyslog on CentOS

Instructions on how to set up Linux modules needed to get a LogAnalyzer log aggregation/analysis server up and running and collecting logs.

Prerequisites

These instructions are specific to CentOS 6.2. If you are using a different distro, many of the installation commands and paths to files will be different from what I've documented below. I strongly suggest that you document the steps to perform a similar install for your distro.

You will need to install the prerequisites by using the following commands:

yum install httpd
yum install mysql
yum install mysql-server
yum install php
yum install php-mysql
yum install php-gd
yum install rsyslog
yum install rsyslog-mysql
/usr/bin/updatedb 

The '/usr/bin/updatedb' command updates the file index so that the 'find' and 'locate' commands work properly. If you've already properly set up your system to index the files daily, this will be unnecessary.

If your distro of Linux is using a different syslog server such as syslog-ng or sysklogd, you'll need to remove it.

MySQL

Set up MySQL

/sbin/chkconfig --levels 235 mysqld on
/etc/init.d/mysqld start
/usr/bin/mysql_secure_installation

Hit enter key after last command has run since no password has yet been set for root MySQL account. Hit 'y' and enter when asked to set up a root password and type in a strong password. Hit 'y' and enter for the following questions: "Remove anonymous users?", "Disallow root login remotely?", "Remove test database and access to it?", and "Reload privilege tables now?"

Set up database and tables

Create the user/database/table and table schema:

Log in to mysql:

mysql -u root -p

Create a user:

CREATE USER rsyslog;
SET PASSWORD FOR rsyslog= PASSWORD('yourpasswordgoeshere');

Set up database and table schema:

CREATE DATABASE rsyslogdb;
USE rsyslogdb;

Paste contents below to mysql to set up the schema:

CREATE TABLE SystemEvents
(
 ID int unsigned not null auto_increment primary key,
 CustomerID bigint,
 ReceivedAt datetime NULL,
 DeviceReportedTime datetime NULL,
 Facility smallint NULL,
 Priority smallint NULL,
 FromHost varchar(60) NULL,
 Message text,
 NTSeverity int NULL,
 Importance int NULL,
 EventSource varchar(60),
 EventUser varchar(60) NULL,
 EventCategory int NULL,
 EventID int NULL,
 EventBinaryData text NULL,
 MaxAvailable int NULL,
 CurrUsage int NULL,
 MinUsage int NULL,
 MaxUsage int NULL,
 InfoUnitID int NULL ,
 SysLogTag varchar(60),
 EventLogType varchar(60),
 GenericFileName VarChar(60),
 SystemID int NULL
);
CREATE TABLE SystemEventsProperties
(
 ID int unsigned not null auto_increment primary key,
 SystemEventID int NULL ,
 ParamName varchar(255) NULL ,
 ParamValue text NULL
);

Next, we need to grant permissions to the rsyslog account we created earlier:

GRANT ALL PRIVILEGES ON `rsyslogdb`.* TO 'rsyslog'@'%' IDENTIFIED BY 'yourpasswordgoeshere';
flush privileges;

Leave MySQL:

exit

Configure rsyslog

Setting up

How to configure rsyslog:

nano /etc/rsyslog.conf

Make your #### Modules #### section the same as the following:

#### MODULES ####

$ModLoad ommysql        # provides support for MySQL
$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
#$ModLoad immark.so     # provides --MARK-- message capability

# Provides UDP syslog reception
$ModLoad imudp.so
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 514

Just above ### begin forwarding rule ### section add info similar to the following line to limit IP addresses that can send syslog info to the server, for each class C subnet the server will be collecting from, you'll need to enter the subnet info followed by /24 (such as 172.18.22.0/24) to allow that subnet to send syslog data. Alternatively, you can limit by single IP addresses. The 127.0.0.1 is necessary so the server can send logs to itself:

$AllowedSender TCP, 127.0.0.1, 172.18.22.0/24
$AllowedSender UDP, 127.0.0.1, 172.18.22.0/24

Add the following line to the ### begin forwarding rule ### section. Replace the "<yourrsyslogpasswordhere>" bit with the password you set for rsyslog MySQL user above:

*.*       :ommysql:127.0.0.1,rsyslogdb,rsyslog,<yourrsyslogpasswordhere>

When done modifying the file, hit Ctrl+x, then y and then enter to save the file.

Restart the rsyslog service:

service rsyslog restart

Test rsyslog

Check if messages are arriving at the syslog server:

tail -f /var/log/messages

Check if messages are being stored in mysql database:

mysql -u root -p
use rsyslogdb;
select * from SystemEvents;

If you see anything other than “empty set” it’s working. Exit out of MySQL:

exit

Configure Apache

Configure CentOS to start the web server at bootup and manually start the service:

chkconfig --levels 235 httpd on
service httpd start

modify 2 lines to match your server's respective ip and fqdn in /etc/httpd/conf/httpd.conf

nano /etc/httpd/conf/httpd.conf
from:
Listen 80
to:
Listen ip.address.of.server:80
and from:
#ServerName www.example.com:80
to:
ServerName fully.qualified.domian.name:80

Hit CTRL+x, then Y and then enter to save and exit the file.

Restart the server:

/etc/init.d/httpd restart

Set up IPTables

Edit the iptables file:

nano /etc/sysconfig/iptables

Add these lines to the /etc/sysconfig/iptables file (before the COMMIT line):

-I INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
-I OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

You'll need to enter lines similar to the following based on your network environment. For more info on how to use IPTables in CentOS see http://wiki.centos.org/HowTos/Network/IPTables:

-I INPUT -p tcp --dport 514 -s 172.18.22.0/24 -j ACCEPT
-I INPUT -p udp --dport 514 -s 172.18.22.0/24 -j ACCEPT

Restart the network service and IPTables:

/etc/init.d/network restart
/etc/init.d/iptables restart

Configure LogAnalyzer

Install LogAnalyzer

Check for the latest stable release by going to http://loganalyzer.adiscon.com/downloads in a browser. Current latest release is http://loganalyzer.adiscon.com/downloads/loganalyzer-3-4-2-v3-stable

Download it on your CentOS server by doing the following:

cd /tmp
wget http://download.adiscon.com/loganalyzer/loganalyzer-3.4.2.tar.gz

Uncompress the file:

tar -xvzf loganalyzer-3.4.2.tar.gz

Copy the source directory to the Apache html directory and create config.php file:

cd loganalyzer-3.4.2/src
rm -R -f /var/www/html
mkdir /var/www/html
cp -R * /var/www/html
cd /tmp/loganalyzer-3.4.2/contrib/
cp * /var/www/html
cd /var/www/html
chmod +x configure.sh secure.sh
./configure.sh

The last line will create a blank “config.php” file, and will give everyone write access to it. It won´t generate any output.

Check if the config.php file has been created (initial setup via browser will make changes to this file):

ls

Create LogAnalyzer MySQL user and database:

mysql -u root -p
create database loganalyzerdb;
CREATE USER loganalyzer;
SET PASSWORD FOR loganalyzer= PASSWORD('yourpasswordgoeshere');
GRANT ALL PRIVILEGES ON `loganalyzerdb`.* TO 'loganalyzer'@'%' IDENTIFIED BY 'yourpasswordgoeshere';
flush privileges;
exit

Initial setup of Log Analyzer, Step One:

On a client system go to the Log server's URL using a web browser (http://yoursystemnamehere.blah.org).

A message stating "Critical Error Occurred: Error main configuration file is missing! Click here to install Adiscon LogAnalyzer!" will appear in browser. Click on the word "here" to start the install.

Click "Next" twice and you should get to the "Basic Configuration" screen. The recommend settings are:

• Number of syslog messages per page: 200 (set this lower if the log server is on a slow system)
• Message character limit for main view: 80 (default)
• Character display limit for all string fields: 80
• Show message details popup: Yes (default)
• Automatically resolved IP Addresses (inline): Yes (default)
• Enable User Database: Yes
• Database Host: localhost (default)
• Database Port: 3306 (default)
• Database Name: loganalyzerdb
• Table prefix: logcon_
• Database User: loganalyzer
• Database Password: <enter in the loganalyzer database user password that you set earlier here>
• Require user to be logged in: Yes

Click "Next".

Initial setup of Log Analyzer, Step Two:

Click "Next" on the "Create Tables" page, then click "Next" on the "Check SQL Results" page and then set up the admin user:

• Username: <enter in the username here that you want>
• Password: <enter in the user password that you want to use>
• Repeat Password: <re-enter in the user password that you want to use>

Click "Next".

Initial setup of Log Analyzer, Step Three:

The recommended settings for the "Create the first source for syslog messages" page are:

• Name of the source: All Syslog Sources
• Source type: MySQL Native
• Select view: Syslog Fields (default)
• Table type: MonitorWare
• Database host: localhost (default)
• Database name: rsyslogdb
• Database table name: SystemEvents
• Database user: rsyslog
• Database password: <enter in the rsyslog database user password that you set earlier here>
• Enable row counting: "Yes"

Click "Next" and then click "Finish".

The install of LogAnalyzer has now been completed. Now other users can be created and there are many settings that can be tweaked as needed.

Point all of the syslog capable devices to the new log server and begin analyzing the aggregated logs.

References

The following sites were used to help figure this all out

http://en.tiagomarques.info/2011/07/centos-syslog-server-rsyslog-mysql-and-loganalyzer/

http://www.pantz.org/software/mysql/mysqlcommands.html

http://pkgs.fedoraproject.org/repo/pkgs/phplogcon/README.fedora/5aa1ea186764ba0a7ea239131141734a/README.fedora

http://www.linuxhelp.in/2010/10/how-to-configure-syslog-server-or.html

http://www.beguelin.com/2009/05/locate-and-updatedb-on-centos.html

Chris Borte's brain

How to install Snort on CentOS 5.6 from source files

It took me a while and a lot of searching around to find all the pieces to do this install so I figured that I might as well document the whole process step by step in case someone else needs help and to help me remember what I did.

They do have RPMs for Snort if you'd rather go that route, but Sourcefire (the makers of Snort) recommend that you install by compiling from source, which is what this instructional blog post is about.

The first thing you'll want to do is install CentOS 5.6 and run the autoupdater.

Next you'll want to download the following source packages:

Snort http://www.snort.org/downloads/867

Daq http://www.snort.org/downloads/860

Libpcap http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz

TCPDump http://www.tcpdump.org/release/tcpdump-4.1.1.tar.gz

Libpcre http://sourceforge.net/projects/pcre/files/pcre/8.12/pcre-8.12.tar.gz/download

Libdnet http://libdnet.googlecode.com/files/libdnet-1.12.tgz

After downloading those files, you'll want to extract them. It's your choice where to extract them, but I just do it in the same folder that I downloaded them to.

Open up a terminal (command line) window and log in as root using

su - root

and enter your root password.

Make sure that gcc and the c++ module for gcc are installed:

yum install gcc

yum install gcc-c++

Change directories to where the libpcap source files were extracted to using the cd command, in my case the command is:

cd /home/alex/downloads/cd libpcap-1.1.1

Follow that with the following commands (these commands assume that libpcap 0.9.4 was installed per the default CentOS 5.6 install):

./configure

make

make install

That finishes the install of libpcap, so now we have to remove the links to the old version and create the new symbolic links.

cd /usr/lib

rm libpcap.so.0

rm libpcap.so.0.9

ln -s /usr/local/lib/libpcap.so.1.1.1 /usr/lib/libpcap.so.1.1.1

ln -s /usr/lib/libpcap.so.1.1.1 /usr/lib/libpcap.so.1

ln -s /usr/lib/libpcap.so.1 /usr/lib/libpcap.so

And now to the extracted directories from above for the daq source files and to do the install of daq:

cd /home/usr/alex/downloads/daq-0.5

./configure

make

make install

Next we need to install libpcre:

cd /home/usr/alex/downloads/pcre-8.12

./configure

make

make install

Next we need to install libdnet:

cd /home/usr/alex/downloads/libdnet-1.12

./configure

make

make install

And finally we can install snort:

cd /home/usr/alex/downloads/snort-2.9.0.5

./configure

make

make install

And you are done with the installation of Snort. You can now run it by doing this command:

/usr/local/bin/snort -v

You should now see information on the console for any packets that are received by your system's network adapters. You use ctrl-c command to exit from Snort.

Relying Too Much On Your Network Intrusion Detection Systems?

It seems that organizations are increasingly relying on Network Intrusion Detection Systems (NIDS) to monitor the security of their networks. While NIDS can certainly give IT staff insights in to what is going on with their network, these systems have several drawbacks that keep them from being the end-all-be-all of network security.

The biggest problem is that NIDS can't detect attacks within encrypted traffic. If an organization is tasked with protecting web based services that require HTTPS or SSL connections, any attacks done over those connections (cross site scripting, injections attacks (SQL or URL), or other attacks) will not be noticed by the NIDS systems. This means that many attacks will fly under the radar of organizations that don't employ other methods of security monitoring along side their NIDS.

Another issue with NIDS is that they are notoriously noisy. Since they typically need to monitor all network traffic and report on any anomalies found within those packets many ordinary behaviors will be trapped as possibly suspicious. This eats up precious manpower as analysts must routinely determine which reported items are noise and which are truly suspicious.

Which brings us to tuning of the NIDS. This can be a tricky task as you cannot simply disregard all traffic from trusted servers, because an insider (or a very crafty hacker) could compromise a trusted system and use it to perform attacks and again you would be none the wiser. However, without proper tuning the high number of false positives will render it extremely difficult to tell when real attacks have happened.

So what's the point of all this? That Intrustion Detection Systems can play an important role in helping an organization monitor network traffic for suspicious activity, however that they should be part of an overall layered defense strategy and should not be overly relied on to provide insights in to malicious attack attempts.

I recommend that NIDS be accompanied by systems that can monitor encrypted web traffic (web server log monitoring) as well as systems that monitor the configuration of all servers in a datacenter to ensure that they don't get out of compliance with organization configuration standards and security hardening best practices.