Firewalling with Snort & Guardian Active Response, Best Practices
Why do we need Snort?
¨ Many forms of attack can go completely undetected by casual observation
¨ Many modern attacks, such as DDOS, are impossible to prevent or contain using static firewall rules
¨ Snort is answer to demands of a cheap and automated solution
The first Snort post dealt with Snort on Ubuntu 14.04 from Sourcecode with Barnyard, SnortReport, Acid. The next bits are Snort sensor set-up. The Snort log for a sensor running on eth1 is processed via snort_stat.pl, e-mailed to “cert@our.org", compressed and stored. Snort is then restarted.
Automated Attack Response
Network intrusion detection systems are capable of mitigating attacks to some extent by applying the network access controls, such as firewall rules, or by directly terminating offending connections. For a review of snort attack response rules, please see http://blog.snort.org/2012/03/rule-category-reorganization.html
One of the flexible ways to use Snort for automatic attack response is with Guardian Active Response for Snort. Guardian is a security program which works in conjunction with Snort to automatically update firewall rules based on alerts generated by Snort. The updated firewall rules block all incoming data from the IP address of the attacking machine (the machine which caused Snort to generate an alert. There is also logic in place which prevents blocking important machines, such as DNS servers, gateways, other hosts with known ip addresses and whatever else is needed.
Here is a link that is recommended: http://www.symantec.com/connect/articles/understanding-ids-active-response-mechanisms . I found it very interesting on why one should use this software with great caution. J
Snort –
· Network intrusion detection and prevention system (IDS)
· Analyzes incoming traffic for signs of attack
o Protocol analysis
o Heuristic content matching
o Rule based
· Report generation
Guardian Active Response (GAR)– Active firewall modification scripts for several firewall programs
· Designed for Snort
· Whitelist for preventing unwanted blocking
· Written is Perl
· Supports watching multiple IPs
Why use Guardian? – Uses snort logs to dynamically block threats
SNORT Network Configuration Overview
Guardian Setup & Integration
· Installed on a dedicated machine: The Acronym Friendly Vast Lab Intrusion Detection and Prevention System (AFVLIDPS)
· Passive connection to hub sniffs incoming traffic without incurring additional delay
· There is a delay, however, between the start of the attack and the Guardian response
GAR Rules
· Avoid service interruptions due to false positives
· Creating rules requires nontrivial amounts of data and analysis
· Quality of Service
§ Restrict to times of day
§ Restrict based on attack frequency
§ Staged restrictions
GAR Performance
· Guardian can read the logs quickly
· MySQL logs are used to view reports and do not affect speed of system
· QoS - Quality of Service
§ Block all potentially harmful traffic?
§ Limit harmful traffic?
§ Leak a little traffic from harmful sources?
Data / Results
The whitelist of addresses which should never be blocked by the IDS are crucial for the automated response system. Even if the IDS invokes the response command upon seeing the attack in the full TCP stream only (thus preventing the DoS attack through blocking the access to mission-critical hosts), many IDS signatures have false positives that will result in disrupting of non-malicious connections. It is desirable to enable response only on reliable signature with no known false positives and additionally have the well-designed whitelist.
The tool supports Linux iptables, ipchains, ipfwadm, ipfw, and also commercial CheckPoint Firewall-1 and Cisco PIX firewalls.
Distributed IDS Setup
Networks with higher traffic load might justify deploying several dedicated sensor machines reporting to a single alarm database and console. To build a distributed IDS, one needs to install the components described above into different machines. The set-up is similar to the single host set-up described here. The difference is that now we need two (or more) base machines with Ubuntu.
Sensor Installation
Install base system, as described here. Set up Snort IDS with MySQL support:
# apt-get install snort-mysql
Please accept all default values during installation. Now Snort is set to log to a database on another host. The appropriate lines in snort.conf on every sensor machine are:
# output plugins output database: log, mysql, user=snort password=<the secret snort password here> dbname=snort_log host=<central-log-host-running-sql-name>
Every machine can have more than one Snort instance for the case of a distributed VLAN or a combination of LANs and VLANs.
Installation of Central Station
The Base system installation should be done as described above. MySQL server should be set up via “apt-get install mysql-server”. During the installation, network connections should be allowed to the SQL server.
Issues may start when granting permissions to access the database tables. One needs to repeat commands "grant" and "set password" for each host one want to connect to central database. For example:
mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort@<sensor1-name.our.org>; mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort@<sensor2-name.our.org>; mysql> grant CREATE, INSERT, SELECT, DELETE, UPDATE on snort_log.* to snort@<sensor3-name.our.org>;
The multi-machine setup needs to address the issue of maintaining signature sets. In the likely case that various machines are deployed in different environments with different security requirements , will lead to differences in rulesets. An internal sensor will need a different rule set from the one running outside the border router or in the DMZ.
Manual rule updates become adminitrative burdens if more than one sensor is deployed. One simple solution is to deploy the signatures on a central server and then retrieve them via ftp. If the signature sets are known in advance, i.e. the same signatures need to be disabled on each update, then "oinkmaster" from Snort can be used to distribute updates from a central server and handle the local ruleset customization on each sensor via the oinkmaster interface.
Each sensor may also have its own unique configuration, which is tuned using "include" directive in configuration file.
The security of the sensor-console communication is something that needs to be addressed too. If deemed necessary, the SQL communication between the sensor and the database can be done over secure shell(SSH).
Large Distributed IDS
In this case the central system is further separated, and the Web server and SQL server are installed on separate machines. This is a variation of the previous set-up. One needs to install sensors, then install the database on one machine, and deploy the Web server and ACID onto another machine. When setting up the IDS console, one should configure the source database as located at another machine. This will leave more CPU cycles for the database process.
Some Best Practices
Whether we are deploying an intrusion detection system on a large network with many sensors or a small network with a single sensor, we should deploy the device in as secure and logical a manner as possible. In this article some techniques value-added resellers (VARs) and security consultants use for securely deploying a network IDS on a customer's network have been addressed, focusing on Snort deployments, simply because Snort is easily available, widely used and OpenSource, even after Cisco bought them :-) ...however, these same principles can be used for other IDSes and applications.
VLAN placement
Determination of what the customer wants monitored. Traffic can either be monitored from the outside of the firewall, or it can be monitored on the inside of the firewall. I personally prefer the inside but like to keep a sensor on the outside in case I need to look at that traffic. tcpdump or a sniffer like Wireshark (formally Ethereal, now owned by Riverbed) can b sued to monitor the interfaces. This makes it easier to determine network problems and detect denial-of-service attacks.
Management network
The customer's IDS information should not be available to just anyone. To help protect this information, a management VLAN should be set up for the specific purpose of non-sniffing interfaces to sit on. If this is not possible or practical, then usage of iptables and TCP wrappers should be considered to restrict who can view what and from where.
Secure communication
HTTPS should only be used to view the IDS management and reporting interface. All communication between sensors and management consoles should be tunneled through SSH or Stunnel.
Secure access to management and reporting interface
The reporting interface should never be left unprotected. Even if the built-in access control of the application itself is being used, it should always be protected with Web server or file level permissions, depending on the Web server the customer is using. If it is on the main LAN, then access can also be lmited/controlled to it via iptables or TCP Wrappers.
Securing the management interface
All applications and utilities that are not needed should be removed, all ports that are not being used should be closed, and communication should be allowed to only what the sensor or manager needs to talk to. This is a basic policy in all matters of systems administration, and it is especially important when considering the sensitive data IDS sensors might pick up.
Reporting and checking
For management of the customer's IDS, it should be inspected regularly, perhaps every hour or two, and a log kept of the last time it was checked. All alerts from that time forward should be viewed so that nothing is missed. For monitoring Snort, BASE can also be used. It is based upon the ACID code that most people have used and are familiar with. It is, however, being actively developed and works much better than previously.
Tuning and updates
While not truly a secure deployment concern, tuning is one of the most important steps in deploying an IDS. If the customer becomes overwhelmed with irrelevant alerts, they will be more apt to ignore alerts as time goes by. So far as updates are concerned, both the rules and engine sould be kept up to date. The use of Oinkmaster is recommended for Snort deployments. It will update the rules on a regular basis and administrator will be notified via email of any changes. The use of SourceFire VRT rules is recommended for Snort installs due to the research and development that goes into them. They are built to the vulnerability rather then a particular exploit and are thoroughly tested by the SourceFire VRT team. One can register to receive them on Snort.org.
Syncing time
An NTP server should be set up on the management system and configure the sensors to update from it. This is key to determining what is happening and when on the network.
References
· “Design Of an Autonomous Anti DDos network” by Angel Cearns
· http://www.chaotic.org/guardian/
No comments:
Post a Comment