by January 5, 2004 0 comments



It’s not sufficient to put a firewall on your network, as it only protects your network’s boundaries. What you also need is an IDS (Intrusion Detection System) for the network (NIDS) and hosts (HIDS). Both work by monitoring suspcious actvities on your network or specific host systems. Here we’ll talk about how to configure and optimaly use two free IDSs, namely SNORT NIDS and Portsentry HIDS. Both are extremely powerful tools.

Configuring Snort
You will need to install the following rpm from our this month’s PCQ Essential CD. 

rpm —ivh snort-2.0.0-1.dag.rh90.i386.rpm

The main configuration file is snort.conf (found in /etc/snort), which can be edited using any text editor. 
There are four main sections in this configuration file: Network variables, pre-processor section, output Plug-ins and customize rule set.

The network variables attempt to focus on packets which the NIDS must analyze for any alerts. While it is alright to leave this section to default, it is important to note that for high traffic servers, you will need to be more focused on each of the
parameters mentioned here. 

The pre-processor section allows you to fine-tune things like the stateful inspection, IP defragmentation support, explicit http, telnet normalized support etc. These can also be left unchanged, unless you have very specific needs. 

Create your own rules
in snort
Let us dissect an existing
rule to learn the components of the rules

alert tcp $TELNET_SERVERS 23 -> $EXTERNAL_NET any (msg:”TELNET
login incorrect”; content:”Login incorrect”;
flow:from_server,established; reference:arachnids,127; classtype:bad-unknown;
sid:718; rev:6;)

The above record tells snort to raise an alert when: any server located in
the Telnet Servers network zone sends the command “Login
incorrect” from port 23 to any user on the Net zone, snort will log
“Telnet Login Incorrect” in the log file and classify th e alert
as “Bad Unknown Type”. The “flow” defines the
direction of data packet and “established” specifies this rule
to be applicable to only complete tcp connections.

Like wise we can create our own rule sets (you may want to populate the
local.rules file) eg.

alert tcp $HTTP_SERVERS 80 -> $EXTERNAL_NET any (msg:”Web login
Incorrect detected by PCQ”; content:”Login incorrect”;
flow:from_server,established; reference:arachnids,127; classtype:bad-unknown;
sid:718; rev:6;)

The above record will monitor all Web activities and if the server
responds to any user with “Login Incorrect”, SNORT will log in
the syslog file : Web login Incorrect, detected by PCQ

The Output plugin section is what you may want to reconfirm. This section primarily describes the method, location, type and content of the alerts and notifications. Snort allows you to dump the alerts not only into a plain text log file, but also mysql, postgresql, MS SQL Server and UNIX ODBC databases. Additionally, you may choose to use binary log files, which are much smaller in size.
We would advise you to uncomment the following line.

output alert_syslog: LOG_AUTH LOG_ALERT

This will allow you to log all Snort alerts into your syslog file.

Customizing rule set is the most interesting and useful of the sections. It is here that you define what signatures Snort should look for. By default, Snort comes with more than 1800 rules with new ones being added continuously. However, don’t enable all the rules together as it may overload your system and cause NIDS to drop packets. The rules are used for detecting viruses on the network, Trojan attempts, Web hack attempts, specific platform hack attempts, Denial of Service attacks and employees visiting porn sites. You can also create your own rule set to detect any particular signatures.Other sections of the configuration file can be left default. Once the configuration is done, fire up Snort using the service snortd start command or chkconfig —level 235 snortd on command to start it on every boot.

Words of caution

  • You will need one NIDS for every LAN segment. At best, you can deploy multiple servers across the company and take integrated control through central log-management.

  • If you use switches, you will be able to put NIDS only on its auxiliary port and link all ports of the segment to that port. This is the only way to deploy NIDS on a switch

  • When the network is fully saturated (very high traffic), an NIDS will start dropping packets. so a potential hacker could first flood the network with trafficand then try to gain access.

  • If the communication on the network is in encrypted format, NIDS will not be able to listen and take corrective action

  • Do not enable all rules on your NIDS. More rules mean more processor requirement and hence higher the chances of drop rates


Using Portsentry 
If you were asked to get inside a protected house, where would you start? You would first identify the possible entry points into the house: doors, panels, windows, exhaust locations, etc. Then you would check to see if the window panes or doors will open. A burglar alarm is generally configured to detect such attempts and is usually linked to the central police station or local security team.

Configuring logcheck
The configuration of logcheck is even simpler. Just open the file /usr/bin/logchek.sh, go to line 42 and change the 
SYSADMIN=”yourid@yourhost.com” 
to send all reports to
yourid@yourhost.com. You may check in the /etc/logcheck directory for fine tuning the following files:
hacking: contains typical hack attempt messages as recorded by the log files
Violations: Contains words that are not necessarily hack attempts but what the system administrators should be aware of
Violations.ignore: Add into this file those phrases or keywords that may cause false alarms etc
Ignore: Contains the keywords, which logcheck should simply ignore

The above is exactly how a HIDS works. Typically, e-burglers (read hackers) would first scan (test open windows, doors) your system using scanning tools. The burglar alarm on your system (HIDS) is configured to sense such scanning attempts in realtime and raise suitable alarms. That’s exactly what Portsentry does.

In the home example, if you get several visitors, not all of them will have access to all the rooms. So once they leave, you may want to crosscheck whether anyone tried to get into rooms they weren’t supposed to. In real life, this may take hi-tech gadgets and expensive equipment, but in the on-line world you can do it using a passive IDS (Intrusion Detection Systems), such as Logcheck. This software periodically checks for signs and symptoms of attack on the system and reports the snyopsis by mail to the administrator. This is also an extremely useful tool for those lazy system administrators who do not get time to regularly scan their log files to detect any malicious events.

Both portsentry and logcheck are on this month’s PCQ Essential CD. Install them as follows: 


rpm -ivh portsentry-1.1-fr8..i386.rpm (for portsentry)
rpm -ivh logcheck-1.1.1-4.i386.rpm (for logcheck)

Use the service portsentry start command to start portsentry. Logcheck is enabled by default and will run after every hour. Check your mailbox for possible mails from these programs. 

Configuring Portsentry 
Configuring portsentry is fairly straightforward with the following main sections in its configuration file
/etc/portsentry/portsentry.conf:

Monitor section
TCP_PORTS, UDP_PORTS: Specify the specific ports to be monitored here. This is comma separated. In most cases, default configuration is appropriate.

ADVANCED_PORTS_TCP, ADVANCED_ PORTS_ UDP: This is the port below that Portsentry will monitor all the ports. Leave it at 1024 for both TCP and UDP.
ADVANCED_EXCLUDE_TCP, ADVANCED_EXCLUDE_UDP are the ports that are NOT monitored in the advanced mode.

Reaction section
Other than informing the administrator of the ongoing attack, Portsentry can react to an attack in at the following ways.

Cloak the host: In this mode, the host under attack simply disappears from the net for the hacker. This is achieved by killing the return route. The default configuration file has a command for this —
Kill_Route.

KILL_ROUTE=”/usr/sbin/route add —host $TARGET$ gw 10.0.0.0 

The trick is to route the return path through a non-existent gateway. Additionally, the 


KILL_HOSTS_DENY=”ALL: $TARGET$: DENY”

will initiate the TCP wrapper and configure the server not to offer any services to the hacker’s system.

Hack the hacker: Not recommended, yet if you would like to test your luck, you may want to use the command 


Kill_Run_Cmd=”/path/to/scanner $TARGET$”
Kill_Run_Cmd=”/path/to/some/exploit $TARGET$”

The above commands will enable your system to first scan the hacker and then launch an appropriate exploit for his system. You will, of course, need to have the right scanners and exploits for the job.

Simply inform: A command like the following will simply inform the administrator of the ongoing
attack.


Kill_Run_Cmd=”/bin/mail -s Active System Attack from $TARGET$, on port $PORT$ administrator@somehost.com

You can even inform of an attack through an instant messenger as fllows: 


Kill_Run_Cmd=”/sbin/g8imconnect admin@somehost.com “Active System Attack from $TARGET$, on port $PORT$” 

Scan_Trigger: Setting a value of 2 in the configuration file will avoid some false alarms. Increasing this figure will make your HIDS more and more “lethargic”, while lower values will make it “jumpy”.

Miscellaneous
Ignore_File:
Points to file that contains the list of host IP addresses that you want the HIDS to ignore.
History_File:
File that contains all the sites that have been blocked.
Blocked_File:
Contains the list of sites that have been blocked in this session. It will be overwritten when you restart
Portsentry.

Leave the other commands to their default values, and do the same if you’re in doubt as well.


Alok Sinha
, is Chief of Information Security, Bharti Group The views presented here are of the author and may not
reflect the views of the employer in full or part

Questions to ask nids vendors

  • What are the charges, if any, for signature updates and maintenance?

  • What is the NIDS drop rate at full throttle and 2000+ rules? This is to be discussed assuming 64 byte packet size (and not 1500). The drop rate should be minimal if not nil.

  • How many simultaneous TCP connections can the NIDS handle? It should be as high as possible.

  • What is the basis of sizing for memory and CPU power? This gives you an idea whether NIDS will be able to cater to your network traffic.

  • What prevention mechanism is available against throttling the IDS? 

  • Can it do heuristic scanning? This should be helpful for some logical event re-building analysis.

  • How does the NIDS protect against slow scans? It should have stateful inspection capabilities.

  • Does the NIDS provide facility to log into a database, instead of flat file? Most definitely required. 

  • What traffic levels are generated when forwarding information to the management console? For a large deployment, this becomes extremely useful.

  • Does the NIDS continue to work, even when the management console is overloaded or off air for some time? 

  • How many signatures does the system support? It should of-course be as large as possible.

  • What intrusion response features does the product have? As explained in the article it should offer all three.

  • Who will write the rule for re-configuring/integrating it with the firewall? Let the vendor do it.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<