Information Security & US & Life & Love & Fashion & Hacking & Passion

Basic Analysis and Security Engine

Basic Analysis and Security Engine (BASE) is available for download from http://www.base.secureideas.net/about.php. The purpose of BASE is to provide a Web-based front end for analyzing the alerts generated by Snort. Base was derived from the ACID project (Analysis Console for Intrusion Databases). Whereas ACID is more of a general-purpose front end for viewing and searching for events, BASE is a Snort-specific utility. The instructions to configure BASE assume you have already installed and configured Snort. Snort must be installed with the —with-mysql switch because Snort does not support MySQL output by default. The Snort Web site has RPM packages with MySQL support already included for some operating systems. This is the list of dependencies for running BASE: httpd, Snort (with MySQL support), MySQL, php-gd, pcre, php-mysql, php-pdo, php-pear-Image-GraphViz, graphviz, and php-adodb. Follow these steps to get BASE up and running.

1. Download and install MySQL and BASE

2. Edit the /snort/snort.conf file. Uncomment and edit the following line:

   output database: log, mysql, user=snort password=snortpass dbname=snort
   
   host=localhost
   
   

3. The next few steps are related to setting up the MySQL database and settings. After you install MySQL, enter the MySQL commands by typing mysql on the command line. This will place you in an interactive command mode. All commands must have a semicolon at the end of the line. By default, the MySQL installation will not have a password set at all. You should add a default password with the following commands.

   mysql
   
   mysql> SET PASSWORD FOR root@localhost=PASSWORD('somepassword');
   
   

   After you have assigned a password to the root account, simply entering mysql will not enable you to access the interactive command mode. After a password has been assigned, use mysql –u <username> –p. You will then be prompted to enter the password for the user you specified (typically root).

4. The next step is to create the Snort database.

   mysql> create database snort;
   
   

5. You now need to give the Snort user permissions to add the needed tables to the Snort database. Use these commands:

   mysql> grant INSERT, SELECT on root.* to snort@localhost;
   
   

6. You should now set the password for the Snort user to the same password you used in the Snort configuration file.

   mysql> SET PASSWORD FOR snort@localhost=PASSWORD('snortpass');
   
   

7. The next step is to add some additional permissions for the Snort database using the following commands:

   
   
   mysql> grant ALL on snort.* to snort@localhost;
   
   mysql> grant ALL to snort;
   
   mysql> exit
   
   

8. Now that the database has been created, you need to populate it with the tables Snort uses. Use the following command to create the tables:

   mysql --u root --p < /etc/snort/schemas/create_mysql snort
   
   

   When the command completes, it will not give any indication of its success; therefore, it will be necessary to manually verify that the tables were created.

   Tip

   If the package you installed did not include the /snort/schemas/ directory, you can download the source package and extract the directory from there. With Fedora Core 5, for some reason installing the Snort with MySQL support did not include the schemas directory.

9. Verify the MySQL tables were created in the Snort database by entering the following commands. You should see output similar to that shown in the following example:

   mysql --u root --p
   
   show databases;
   
   +----------+
   
   | Database |
   
   +----------+
   
   | mysql    |
   
   | snort    |
   
   | test     |
   
   +----------+
   
   use snort;
   
   show tables;
   
   +------------------+
   
   | Tables_in_snort  |
   
   +------------------+
   
   | data             |
   
   | detail           |
   
   | encoding         |
   
   | event            |
   
   | icmphdr          |
   
   | iphdr            |
   
   | opt              |
   
   | reference        |
   
   | reference_system |
   
   | schema           |
   
   | sensor           |
   
   | sig_class        |
   
   | sig_reference    |
   
   | signature        |
   
   | tcphdr           |
   
   | udphdr           |
   
   +------------------+
   
   exit
   
   

   The list of databases is not significant, as long as the Snort database exists, of course. The table listing must be accurate. If any are missing, Snort will generate an error when you run it.

10. Install php-gd, which is used to generate the graphs in BASE. On Fedora Core 5 you can just type yum install php-gd.

11. Install ADODB, which is a database abstraction library for PHP. On Fedora you can simply enter yum install php-adodb.

12. It's now time to configure BASE itself. Edit the /usr/share/basephp4/base_conf.php file to ensure that the following lines are configured with paths and settings appropriate for your configuration.

    $BASE_urlpath = '/base';
    
    $DBlib_path = '/usr/share/ododb';
    
    $DBtype         = 'mysql';
    
    $alert_dbname   = 'snort';
    
    $alert_host     = 'localhost';
    
    $alert_port     = '';
    
    $alert_user     = 'snort';
    
    $alert_password = 'snortpass';
    
    

    You should not be able to access the BASE Web page at the following URL: http://localhost/base/.

    Tools & Traps…

    Troubleshooting Tips

    • You can enable debugging in BASE by editing the /usr/share/base-php4/base-php4.conf file.

      $debug_mode = 2;
      
      

    • Use chkconfig to make sure that MySQL, Snort, and httpd are running.

      Chkconfig --list | grep snort
      
      Snortd      0:off 1:off 2:on 3:on 4:on 5:on 6:on
      
      

      If all entries say "off," then that service is configured not to start. Try service snortd start.

    • Httpd may need to be restarted for some configuration changes to take effect; when in doubt, restart it just to be safe: service httpd restart.

    • The httpd access log and error log can be found at /etc/httpd/logs.

    • You can control the logging level of the httpd by editing /etc/httpd/conf/httpd.conf.

      LogLevel debug
      
      

    • If you are having issues with the URLs not being found, the /etc/httpd/conf.d/base-php4.conf file tells the Web server to alias /base/ with the directory /usr/share/base-php4/.

    The very first time you start up BASE, none of the database tables have been created. You will see something like the page shown in Figure 4.15.

    
    Figure 4.15: BASE Setup

13. Click on the Setup page link.

14. Click the Create BASE AG button on the right-hand side. You see several success messages as shown in Figure 4.16.

    
    Figure 4.16: BASE Success

15. Click the Main Page link. This should take you to the primary BASE interface as shown in Figure 4.17.

Figure 4.17: BASE Main Page

Although this window may not be too flashy, there is a wealth of information you can discover. Most of the fields are actually links. By clicking to the right of Today's alerts, for example, you can get a sorted list of unique alerts, a listing of all alerts, or a list sorted by source IP address or destination IP address. The other headings along the left side offer similar functionality. Of particular note are the links for the Most Frequent 15 addresses by source address. This would enable you to quickly see which systems are generating the majority of your alerts. If you open that window (shown in Figure 4.18) there are several additional fields that are also hyperlinked.

Figure 4.18: BASE Most Frequent by Source IP

Note the field at the bottom labeled ACTION. This enables you to configure the alert groups. Alert groups are basically shortcuts to enable you to view a subset of alerts quickly, without having to navigate through the various menus to get there. For example, suppose you want to know anytime that 192.168.1.1 generates an alert. You can check the check box to the left of 192.168.1.1, and then use the {action} drop-down box to select Create AG (by Name). In the action column, enter .1_ALERTS to use as the alert group name. Finally, click Selected.

The next screen enables you to enter a description for the newly created alert group. Enter a meaningful text description for the group and click Save Changes. The next screen will be a listing of all alerts from 192.168.1.1. This screen is the alert group. In the future, if you want to quickly see this group of alerts, you can click Alert Group Maintenance at the bottom of each page, and then click the alert group you want to view. In this way, any subset of alerts is only two clicks away, sort of like a shortcut straight to a particular set of filtering criteria.

Another feature of note is the Administration link at the bottom of each page. This will take you to a screen where you can configure users for BASE. There are four options on the administration screen: list users, create a user, list roles, and create a role. These screens enable you to create users and assign them to various roles. If you click List Roles, you can see the four predefined roles. If you want to assign a user in the administrator role, simple click Create a user. Enter the login name, a full name or description, and a password. Use the drop-down box to select a role and then click Submit Query. None of the settings here will take effect until you edit the base_conf.php file and change the value of $Use_Auth_System = 1;. A value of 0 (the default) means the authentication is disabled and everyone has full access to BASE. Only the admin role has access to the administration screen.

The frag2 preprocessor

Because many varieties of devices are out there (and many can transfer data over TCP/IP), subtle implementation differences result in packets that must sometimes be reorganized and chopped into smaller packets, a process that’s called fragmentation.

 Technical Stuff  To a network-based IDS, fragmentation can result in false negatives (real attacks that are missed) because the attack actually spans several packets. The original offending data may have been in a single packet at the beginning of its journey, but through the normal process of routing, it may have been redistributed over several packets, which hides it well. Such fragmentation poses a special problem for Snort, but, thinking ahead, the Snort team has an answer: the frag2 preprocessor.

By enabling frag2 in your snort.conf file, Snort’s packet decoder uses a similar reassembly process for reconstructing fragmented packets, before submitting them to the detection engine. It takes the pieces and puts Humpty Dumpty back together again.

To enable the frag2 preprocessor, use a configuration like this:

preprocessor frag2: timeout 60

http_inspect: a preprocessor for HTTP

With Snort 2.1, the http_decode preprocessor gave way to the http_inspect preprocessor. If you use Snort 2.0, use http_decode. If you use Snort 2.1 (or later), use http_inspect.

 Tip  We recommend installing and using the http_inspect preprocessor. Using http_inspect normalizes all packets containing different forms of HTTP communication into a state that Snort can easily compare and scan through its rules. A huge amount of Web traffic crosses the Net, and many attacks rely on the HTTP protocol as their transmission medium.

To configure your Snort system so that it normalizes Web traffic, you need to put a few lines in your snort.conf configuration file that look something like the following:

preprocessor http_inspect: global iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default profile all ports { 80 }
preprocessor http_inspect_server: server 172.16.1.1 profile all ports { 80 }

The first configuration line, which contains the keyword http_inspect, is for setting up the global behavior of the preprocessor, whereas the other lines with http_inspect_server in them are for specializing the configuration for individual machines. You need to include the iis_unicode_map keyword and its argument. Without it, Snort complains and refuses to start.

The options that follow the http_inspect_server keywords include the

• Ports on which the preprocessor should operate (between the {}s).

• A series of operations that should be used when normalizing the traffic.

The options described in the next sections are some of the most useful http_inspect options. They show how HTTP preprocessing really works.

rpc_decode: a preprocessor for RPC connections

Applications that use Remote Procedure Calls (RPC connections) use a different connection method than most common network services. Servers using RPC don’t listen on published well-known ports, such as TCP port 22 for telnet or TCP port 80 for HTTP. Servers using RPC bind to a random, unreserved port and publish that they’re available to another application (the local portmapper). You may already be familiar with portmapper if you’ve seen what application is listening on a TCP and UDP ports 111 on a standard Unix computer.

 Tip  How can you snort when you don’t know where to put your nose? The answer is to decode the traffic on port 111, which is the traffic cop port. It isn’t a perfect answer, but it helps get the job done.

To configure the rpc_decode preprocessor, insert the following line into your snort.conf configuration file:

preprocessor rpc_decode: 111 32711

The numbers that follow the colon are ports to regard for decoding. Port 32711 is a port that Sun’s Solaris operating system uses for portmapper in addition to port 111.

portscan, portscan2, conversation

Portscanning is a technique that hackers use to “get the lay of the land” of a network that they intend to target. If we compare digital attacks to real-world warfare ones, portscanning is analogous to sending a surveillance and reconnaissance team to catalog the buildings, access portals, and armed guards that protect an installation.

Typical Snort rules can’t see whether an individual packet is part of a probing attack. The portscan, portscan2, and conversation preprocessors operate on both

• Individual packets

• Groups of packets

What makes a portscan a portscan? Together, several factors paint a pretty good picture of the prober’s intent:

• The time over which the packets were sent.

• The number of destination ports the packets were directed toward.

• The number of destination hosts addressed by the packets.

Snort’s portscan preprocessor operates by watching for a specified number of packets, sent within a certain timeframe, directed at any of the hosts on our network. For example, portscan produces an alert if it’s programmed with a threshold that 100 different ports were addressed within 5 minutes all from the same IP address source.

The portscan preprocessor is configured in the Snort configuration file with a line like this:

preprocessor portscan: 172.16.100.0/24 10 30 /var/log/snort/portscan.log

For the specifics on those options, check the configuration flags, which conform to this setting:

preprocessor portscan: <network> <# of ports> <time period> <logfile>

The example shows that this instance of the portscan preprocessor is set up to produce alerts whenever someone is probing the 172.16.100.0 Class C network with at least 10 different ports within 30 seconds.

 Tip  A configuration line in your snort.conf file can tell the system to ignore certain networks. This line is handy when you do port scans of your own network for topology mapping purposes. To configure portscan-ignorehosts, edit your snort.conf file and input a line using the following syntax:

preprocessor portscan-ignorehosts: network/netmask

To ignore networks 192.168.4.0/24 and the host 10.10.10.66, add the following line to snort.conf:

preprocessor portscan-ignorehosts: 192.168.4.0/24 10.10.10.66/32

Back Orifice (bo)

 Technical Stuff  In the late 1990s, an underground hacking group named The Cult of the Dead Cow (CDC) created a remote administration application called Back Orifice (a play on Microsoft’s Back Office program suite) to control Windows operating system computers from afar. While Back Orifice can be used for legitimate system administration, it’s also a favorite backdoor program for intruders. All you must do is trick someone into installing the program, which isn’t hard because it’s small and easy to package with other programs.

 Tip  The bo preprocessor focuses on traffic associated with the Back Orifice tool, which is an incredibly strong indication of a hacker in your midst.

The bo preprocessor can detect the first few moments of a BO connection attempt across the network and alert on it appropriately. Configuring the bo preprocessor is straightforward. Simply edit your snort.conf file and add the following:

preprocessor bo

Trimming the fat

Likely the first refinement that any IDS guru recommends, almost to the point of being a broken record, is to reduce your false positives by stripping the dead wood from your rules files.

We recommend that you sit down with a map of your network and a list of your network connected assets (operating systems and exposed services are the most critical) and build a table of your computer resources that can be attacked. From there you comment out those rules that just don’t matter. If you have ten Windows NT servers running MS Project Server and nothing else, there’s little need for a thousand Linux/Unix rules.

Commenting out unneeded rules is a simple matter: Just edit the file containing the rule and place a “#” before the first character of the rule type (generally “alert”).

Chapter 9 includes more tuning methods that reduce false positives and the reasons why removing the extra noise keeps your Snort a-snorting.

Making adjustments

Small changes to the rules files of your setup can keep your Snort installation running at peak efficiency. By refining the rules that you are already running with Snort, you generate better reports, waste less time reviewing them, and react faster.

 Warning   Before editing any Snort rule file, it’s highly recommended that you do the following:

• Always make a backup of that rule file.

• Make sure that you use a plain text editor that doesn’t add any funky formatting or characters when you save the file. The vi program in Linux and Notepad in Windows are good examples.

Start by finding a rule that can use some tweaking. Maybe this DNS rule was misclassed:

alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"DNS SPOOF query response 
PTR with TTL\: 1 min. and no authority"; content:"|85800001000100000000|"; content:
"|c00c000c00010000003c000f|"; classtype:bad-unknown; sid:253; rev:2;)

Out of the box, it’s classified as a “bad-unknown” alert. Maybe it should be reclassified as a reconnaissance or information probe, consistent with an “attempted-recon” tag. To change the rule, just edit the dns.rules (the file that contains the rule we’re modifying) and change it to something like

alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"DNS SPOOF query response 
PTR with TTL\: 1 min. and no authority"; content:"|85800001000100000000|"; content:
"|c00c000c00010000003c000f|"; classtype:attempted-recon; sid:253; rev:3;)

 Technical Stuff  We bumped up the revision number to 3 so that another person can see that something’s changed.

 Tip  If you plan on making lots of changes to the base rules that come with Snort, keep a local backup copy of the original version outside of the directory that Snort uses to manage its configuration. If you upgrade Snort without keeping copies of all your custom tweaking, you may accidentally overwrite the whole lot with one punch of the enter key!

Building a rule from whole cloth

In some cases, a new rule is needed. Situations that might require a new rule include:

• Some sort of odd behavior on the network has been noticed: Maybe an abnormal amount of data is transferred on the network after hours, or a particular server is rebooting for no apparent reason. An investigation begins to determine what these oddities mean, and based on captured network data, you can create a rule that matches the odd event.

• A new attack hits the Internet. There are no existing Snort rules that match the attack, so you decide to create a rule on your own.

 Tip  For almost all configurations, the standard set of rules (if regularly updated) can be just what the doctor ordered. The need to build a whole rule from scratch isn’t an everyday occurrence.

Here’s a real-world situation that we can use as an example. While on-site at a customer’s facility, we heard that its network was acting irrationally and that the customer needed our help in isolating the cause of it. After an hour of tracking back a huge amount of network bandwidth coming from two workstation computers, we found that they were infected with some sort of virus. We diagnosed a virus by running a packet sniffer and capturing all of those workstations’ network communications.

All of that techno-sleuthing work we did can be best summarized into a packet capture, or at least a fair approximation of one. What follows is a snippet of what we were looking at:

15:30:05.000913 10.3.232.38.1522 > 192.168.4.81.1434: udp 376

0x0000   4500 0194 bec2 0000 6d11 d406 d963 055d        E.......m....c.]
0x0010   d8ab 0224 1069 059a 0180 6b52 0401 0101        ...$.i....kR....
0x0020   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0030   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0040   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0050   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0060   0101 0101 0101 0101 0101 0101 0101 0101        ................
0x0070   0101 0101 0101 0101 0101 0101 01dc c9b0        ................
0x0080   42eb 0e01 0101 0101 0101 70ae 4201 70ae        B.........p.B.p.
0x0090   4290 9090 9090 9090 9068 dcc9 b042 b801        B........h...B..
0x00a0   0101 0131 c9b1 1850 e2fd 3501 0101 0550        ...1...P..5....P
0x00b0   89e5 5168 2e64 6c6c 6865 6c33 3268 6b65        ..Qh.dllhel32hke
0x00c0   726e 5168 6f75 6e74 6869 636b 4368 4765        rnQhounthickChGe
0x00d0   7454 66b9 6c6c 5168 3332 2e64 6877 7332        tTf.llQh32.dhws2
0x00e0   5f66 b965 7451 6873 6f63 6b66 b974 6f51        _f.etQhsockf.toQ
0x00f0   6873 656e 64be 1810 ae42 8d45 d450 ff16        hsend....B.E.P..
0x0100   508d 45e0 508d 45f0 50ff 1650 be10 10ae        P.E.P.E.P..P....
0x0110   428b 1e8b 033d 558b ec51 7405 be1c 10ae        B....=U..Qt.....
0x0120   42ff 16ff d031 c951 5150 81f1 0301 049b        B....1.QQP......
0x0130   81f1 0101 0101 518d 45cc 508b 45c0 50ff        ......Q.E.P.E.P.
0x0140   166a 116a 026a 02ff d050 8d45 c450 8b45        .j.j.j...P.E.P.E
0x0150   c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45        .P........<a...E
0x0160   b48d 0c40 8d14 88c1 e204 01c2 c1e2 0829        ...@...........)
0x0170   c28d 0490 01d8 8945 b46a 108d 45b0 5031        .......E.j..E.P1
0x0180   c951 6681 f178 0151 8d45 0350 8b45 ac50        .Qf..x.Q.E.P.E.P
0x0190   ffd6 ebca                                      ....

That same sequence of bytes was being repeated ad nauseum by the two busted computers. What we didn’t know at the time was that a new worm outbreak had just started to infest the Internet. What we were seeing with that hex dump was the MS-SQL worm (also known as Slammer) in its replication stage. To bandage the situation, we unplugged the two offending computers and ran to our Snort installation, where we chopped a few bytes out of this trace to build a signature and ultimately a Snort rule to catch any more of these instances.

To illustrate, here’s a string of 16 bytes that can represent this novel worm:

c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45

Line number “0x0150” is an example of a segment made into a signature. Now, on to the fun part of making a Snort rule out of that gunk! The first goal is to build an appropriate header. A review of the first line of the trace dump gives all the necessary network information you need to construct a header.

15:30:05.000913 10.3.232.38.1522 > 192.168.4.81.1434: udp 376

Table 8-6 identifies the meaning of each of the preceding line’s component elements.

All that’s needed from Table 8-6 are the protocol and the destination port. The source IP address, source port, and destination IP address show up differently when coming from and going to different systems. Remember, we’re looking for new instances of this worm, not the infected systems we already know about. Coupled with the signature that was scissored from that big block of packet data, that’s the complete makings of a fledgling Snort rule. All the pieces fit together like this:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"New MSSQL Worm A-Multiplyin’";
 content:"|c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45|"; sid:1000001; rev:1;)

 Technical Stuff  The preceding example highlights the following best-practices in creating a Snort rule:

• We followed the path of the good Snort administrator and made the Snort ID equal to 1,000,000.

• The revision is marked as 1, meaning that this attempt was our first at drafting a rule to achieve the wanted results.

After testing, if our signature isn’t right or other elements need tweaking, we can make the changes and increase the rev number to reflect the changes.