Friday, July 30, 2004

FreeBSD 5.3 Arrives in October?

freebsd.png" align=left>I read a great article at ZDNet UK based on the May-June 2004 FreeBSD Status Report. Citing release engineer Scott Long, the article says he hopes FreeBSD 5.3 will arrive on the first of October, 2004.

I like to see this sort of FreeBSD coverage in more mainstream publications, like last week's CNN article on open source.

On a different note, visit the redesigned Sguil homepage. Scott Dexter did a really nice job, and we're looking for someone with suitable graphics-fu to redesign the Sguil logo. Please send any ideas to 'scottder at sguil dot net'.

Thursday, July 29, 2004

Review of Wi-Foo: The Secrets of Wireless Hacking Posted

Amazon.com just posted my five star review of Wi-Foo. The book's Web site is wi-foo.com. From the review:

"'Wi-Foo' is the wireless book the security community needs. The book mixes theory, tools, and techniques in a manner helpful to those on the offensive or defensive side of the wireless equation. After reading 'Wi-Foo,' I'm glad I didn't try to cover similar topics in my 'Tao of Network Security Monitoring' -- these authors have written the definitive wireless 'hacking' text.

Several aspects of 'Wi-Foo' make the book a winner. First, with the exception of crypto topics in chapters 11 and 12, they tend to defer to previously published works rather than rehash old topics. For example, rather than exhaustively explain 802.11i, they refer readers to 'Real 802.11 Security,' an excellent defense-oriented wireless book. 'Wi-Foo' also assumes readers are familiar with TCP/IP and system administration, leaving out potentially redundant material."

Tuesday, July 27, 2004

Using Session Data to Scope Events Without Signatures

Critics of intrusion detection systems say signature-based IDSs are too easy to evade, bypass, or fool. This is true when the IDS only provides alert data to analysts. Alerts are the results of judgements made by the IDS developers, as encoded in the IDS' rules and logic. To deal with events that have no signatures, we can turn to other forms of network security monitoring data.

Session data is a record of transactions between parties, typically storing source and destination IP addresses and ports, session start and end times, and counts of packets and bytes of data sent by source and destination. Session data is best captured for connection-oriented TCP traffic, but sessions can be emulated for connectionless protocols like UDP and ICMP in a request-response model.

Session data is immune to encryption, because no payloads are captured. Session data is also not dependent on signatures, because every transaction is recorded. This "neutrality" makes session data an excellent candidate for investigating events for which no signatures exist, albeit in an "after-the-fact" manner.

The recent MyDoom variant represents a case where session data can be used to determine if hosts have been infected. We can ask Sguil to check its session database for evidence of connections to port 1034 TCP, after reading the report by the SANS Internet Storm Center:

WHERE sessions.start_time > '2004-07-20' AND
(sessions.src_port = 1034 or sessions.dst_port = 1034)
and sessions.dst_port != 80 and sessions.src_port !=80
and sessions.dst_port != 443 and sessions.src_port != 443
LIMIT 500

This SQL query excerpt says to check for sessions with source or destination ports of 1034 TCP, but to omit sessions with ports 80 or 443 TCP. This is a way to ignore outbound Web browsing records.

Here are partial sample results for 26 July 2004, omitting src_bytes, dst_pckts, and dst_bytes, which are all 0 in this case:

start_time src_ip src_port dst_ip dst_port src_pckts
17:37:49 1.2.3.4 47076 15.136.19.27 1034 6

17:38:10 1.2.3.4 47146 16.138.31.128 1034 6

17:38:31 1.2.3.4 47209 16.190.234.172 1034 6

17:38:52 1.2.3.4 47235 16.49.36.18 1034 6

17:39:13 1.2.3.4 47317 16.133.77.85 1034 6

These results show us that host 1.2.3.4 began making outbound connections to port 1034 TCP at 17:37:49. This is a strong indicator that 1.2.3.4 is infected by the latest MyDoom variant. Should any inbound connections to port 1034 TCP on 1.2.3.4 appear, we know someone is making use of this backdoor.

If you're not running Sguil, you can use Argus to collect session data. SANCP by John Curry is another option, one which is included in Sguil. The default session data recording in Sguil uses Snort's stream4 preprocessor keepstats function.

If you'd like to know more about using session data to scope intrusions and other security events, please see chapters 7 and 15 in my Tao of Network Security Monitoring.

Saturday, July 24, 2004

Review of Hardening Windows Systems Posted

Amazon.com just posted my five star review of Hardening Windows Systems. From the review:

"Roberta Bragg's _Hardening Windows Systems_ (HWS) is exactly the sort of book I expected from McGraw-Hill/Osborne's new 'Hardening' series. The publisher gained fame through its assessment-oriented 'Hacking Exposed' series, and now it advocates preventing intrusions via configuration instead of assessment. (Those familiar with my Network Security Monitoring theories will remember I believe 'prevention eventually fails,' but I still recommend doing everything possible to make the intruder's task difficult!) HWS is a Windows security tour-de-force, and I intend to recommend it often."

Review of Know Your Enemy: 2nd Ed Exclusively at TaoSecurity

I just finishing reading the second edition of Know Your Enemy and wrote a review for Amazon.com. Unfortunately, Amazon.com is treating this completely new second edition as though it were the first edition. When I tried to post my review, I received this response:

"Oops! Only one review per customer per product set is allowed.

Your review was not accepted because we only allow each customer to write one review of each product set. An example of a product set is the collection of all editions of a book: hardcover, paperback, and audiobook. If you'd like, you can edit your existing review."

I'm sure Amazon.com does this to prevent multiple reviews by the same person, but these are two completely different books.

Amazon.com also harassed me to provide a real name to appear in my review. I had to tie this to a credit card. Aside from that aspect, I think this is a good idea. Review readers are supposed to believe the words of someone providing a "real name" rather than someone posting anonymously or using a pseudonym.

One final complaint -- I found my attempts to include " marks replaced by 'ampersand'quot; throughout the review. Amazon.com must be using a filtering mechanism to avoid cross-site scripting or similar attacks.
Because I don't want to edit my review of the first edition of Know Your Enemy, here is my review of the second edition:

"Nearly three years ago I gave the original "Know Your Enemy" (KYE:1E) four stars, subtracting a star for the inclusion of excessive IRC logs. I am very happy to rate the completely new second edition (KYE:2E) as a five star book, for three reasons. First, KYE:2E is one of the few books that rightfully concentrates on threats, not vulnerabilities, when discussing digital security. (Ed Skoudis' impressive "Malware" is another threat-oriented tome.) KYE:2E is a tour of multiple security disciplines, each addressed by a subject matter expert. Finally, KYE:2E is clear and cohesive, written by people who can communicate well. I highly recommend reading this book.

As a former Air Force intelligence officer, I performed threat analysis by studying Russian and other foes; not only did I look at their military equipment, but I also examined the foe themselves and their tactics. This is similar to examining a digital enemy's tools, as well as the intruder himself and his methodology. Lance Spitzner leverages his Army background through KYE:2E, bring this same focus to the study of black hats as he did against Russian tanks, their commanders, and their battle plans.

Threats are really the overlooked key to security. If a vulnerability exists in a critical asset, but no threat (meaning a party with the capabilities and intentions to exploit that weakness) exists, the target remains secure. Too often security practitioners think only of vulnerabilities, and waste time addressing flaws that no threat seeks to exploit.

KYE:2E addresses threats in numerous chapters, including several case studies (Windows, Linux, and Solaris compromises in ch 18-20) and sociological studies and lessons learned (ch 16-17).

Of the four aspects of the security process (assessment, protection, detection, and response), KYE:2E spends most of its time on detection and response. I was impressed by the repeated demonstrations of the recognition of the value of multiple forms of forensic evidence. Ch 3, for example, explicitly emphasizes the need to collect network-based alert, session, and full content data, supplemented by host-bases evidence, to detect and understand intrusions. The chapters on Windows- and UNIX-based forensic analysis are good introductions to the subject for those seeking a starting point.

KYE:2E is a collaborative effort that doesn't suffer the fate of similar team-authored books. I congratulate the editing team and lead editor for coordinating their efforts, since I found very few places where authors discussed the same issue twice. I found the technical discussions highly readable, especially sections on reverse engineering (ch 14) and Windows filesystems (ch 13). Ch 5 also featured excellent diagrams to explain key points on GenII honeynets. I was very pleased to see the excellent legal chapter available for download on the book's Web site. (.pdf)

I had very few complaints with KYE:2E, but I must highlight some bad advice in ch 15. While discussing best practices for saving Snort IDS logs and packets logged by Tcpdump (pp. 489-492), the authors recommend configuring Snort to send data directly to a database. This is an excellent way to cause Snort to drop packets and miss traffic, and was the reason Barnyard was invented. I also question the utility of storing full content data in a database, when putting it in that form renders most libpcap-oriented tools incapable of reading it.

KYE:2E is another must-buy for 2004. The book is a strong mix of hands-on technical configuration, defensive theory, and practical advice. Given the wide range of topics it expertly addresses, I expect everyone to find something of interest in this great book. I hope to see more information on anti-forensics, perhaps addressing tools like NoSEBrEaK, in future editions."

Friday, July 23, 2004

A Different Take on Intrusion Prevention Systems

Today while perusing the SANS Incident Handler's Diary, I noticed the "Handler On Duty" was Tom Liston, and his Web site was listed as LaBrea Technologies. I remembered Tom from his July 2001 post to the intrusions@incidents.org mailing list. There he theorized on the idea for his LaBrea "tarpit," code to trap malware visiting non-existent local IPs using various TCP tricks. Fearing DMCA, Tom no longer hosts LaBrea at his site, but it's available in the FreeBSD ports tree as security/labrea, and elsewhere.

A visit to LaBrea Technologies shows Tom is working on the "LaBrea Sentry IPS - Next Generation Intrusion Prevention System." From Tom's description:

"LaBrea Sentry connects to the local network and monitors attempts to access unused IP addresses. Once such attempts are detected, the LaBrea Sentry creates virtual machines to emulate an active server on the unused IP address, executes countermeasures defined by the user, logs the activity, and coordinates with LaBrea Central to proactively block known scanners.

LaBrea Central compiles and analyzes data from all LaBrea units, generating a global 'Bad Guy List,' providing proactive protection from known hostile sources."

A check at archive.org shows references to this product from at least April 2003, so Tom's been working on it for a while. This sort of product reminds me of a sort of passive-aggressive honeyd. I'd be interested in seeing what comes out of this work.

Keep in mind that an "intrusion prevention system" as currently implemented by vendors is simply an access control device with visibility of layer 7 traffic. Vendors like TippingPoint, Intruvert (now part of NAI), and others knew they would be crushed by the firewall giants of the early 2000's if these start-ups competed as "improved firewalls." Instead, TippingPoint and others followed MBA strategy 101 and defined a "new market" for "Intrusion Prevention Systems." The firewall market took a while to catch on to the layer 7 inspection and denial routine, but by late 2002 vendors like Netscreen and Checkpoint were waking up. Marty Roesch participated in threads on focus-ids and snort-users that validate my viewpoint.

LaBrea is different in that it doesn't operate at layer 7, inspecting and then dropping traffic presumed to be malicious. Rather, it watches unused IP addresses and then interacts with malware attempting to connect to services which could be offered by those nonexistent hosts. An intrusion is "prevented" because the malware gets "stuck" in the tarpit prior to exploiting a live host -- maybe. It depends on a lot on luck, because the real target might get hit before the tarpit.

Thursday, July 22, 2004

Install Guide for Sguil 0.5.0 Posted

After installing a self-contained Sguil 0.5.0 installation on a new laptop, I updated my Sguil installation guide for Sguil 0.5.0. The new guide takes into account the merging of xscriptd's functions into sensor_agent.tcl and sguild.

I also caught a problem with the databases/mysqltcl FreeBSD port. By default the Makefile requires mysql323-client as a dependency, but I recommend changing that to mysql40-client to keep all components running MySQL 4.0.20.

Changes like these are the reason I didn't explain how to install Sguil in my book. As Sguil progresses towards a 1.0 release, a lot will change under the hood. The user interface and method of operation will remain stable, so I describe those features in my book.

Friday, July 16, 2004

The Tao of NSM Is Published!

My wife found a copy of my book left in our garage today by the UPS or Fedex delivery person! I'm very happy to see it in print.

Four years ago Karen Gettman from Addison-Wesley approached me about writing a book. Initially I wanted to write "Intrusion Detection and Incident Response Illustrated," but I decided to wait until I felt I was ready.

At Black Hat last year, I met my editor Jessica Goldstein from Addison-Wesley. I presented the proposal I had worked on all of the previous night. About a month later I signed a contract, and by March of this year submitted my draft of the text.

Now, less than a year after that Black Hat meeting, I have a copy of my book in hand. Thank you to every who assisted -- you're all in the preface!

Some of you will be getting review copies soon. I expect to see the book available from online booksellers next week, and in stores before the end of the month. Please send feedback to blog at taosecurity dot com.

Update: I asked my publisher why Amazon.com isn't currently selling my book at a discount. She wrote:

"Amazon is having a data feed problem, and that is why your book isn't discounted. Many new books on Amazon are showing for list price, which is incorrect. They are working with the vendor who is sending them the bad data and are trying to get it fixed."

Expect to see the price drop at Amazon.com shortly.

Netwox, the Network Toolbox

Packet Storm posted word of a new release of Laurent Constanin's Netwox. I had never tried it before, but was aware of the project from articles like Linux Security and elsewhere.

The Network Toolbox consists of three components: Netwib, a network library; Netwox, the collection of 150+ tools, and Netwag, a Tcl/Tk interface. Given that Sguil is also written in Tcl/Tk, I was interested in trying out this tool.

If you just run Netwox, you'll be presented by a series of menus which help you select the proper command line switches to use various tools. In the following example I use the menus to eventually see how Netwox recognizes the NICs in my workstation:

drury:/usr/local/src/netw-ib-ox-ag-5.19.0/src/netwag-src/src$ sudo netwox
Netwox toolbox version 5.19.0. Netwib library version 5.19.0.

######################## MAIN MENU #########################
0 - leave netwox
3 - search tools' title
4 - display help of one tool
5 - run a tool selecting parameters on command line
6 - run a tool selecting parameters from keyboard
a + information
b + network protocol
c + application protocol
d + sniff
e + spoof
f + record
g + client
h + server
i + tools not related to network
j + administrators' tools
k + attack tools
Select a node (key in 03456abcdefghijk): a


####################### information ########################
0 - leave netwox
1 - go to main menu
2 - go to previous menu
3 - search tools' title
4 - display help of one tool
5 - run a tool selecting parameters on command line
6 - run a tool selecting parameters from keyboard
a + information on local computer
b + information on remote computer
c + information on netw
Select a node (key in 0123456abc): a

############## information on local computer ###############
0 - leave netwox
1 - go to main menu
2 - go to previous menu
3 - search tools' title
4 - display help of one tool
5 - run a tool selecting parameters on command line
6 - run a tool selecting parameters from keyboard
a - 1:Display network configuration
Select a node (key in 0123456a): a

################## help for tool number 1 ##################
Title: Display network configuration
Note: If no option is set, they are all displayed
Usage: netwox 1 [-d] [-i] [-a] [-r]
name type description {example}
-d|--devices|+d|--no-devices display devices {0}
-i|--ip|+i|--no-ip display ip addresses {0}
-a|--arpcache|+a|--no-arpcache display arp cache and neighbors {0}
-r|--routes|+r|--no-routes display routes {0}
Example: netwox 1
Press 'r' or 'k' to run this tool, or any other key to continue

################## running tool number 1 ###################
Enter optional tool parameters and press Return key.
netwox 1
################################### Devices ###################################
nu dev ethernet_hwtype mtu real_device_name
1 Eth0 00:50:BA:AC:D7:43 1500 rl0
2 Eth1 02:00:4C:00:00:00 1500 fwe0
3 Eth2 00:30:48:41:F9:56 1500 fxp0
4 Pli0 plip 1500 plip0
5 Lo0 loopback 16384 lo0
6 Eth3 00:BD:CA:09:00:01 1500 vmnet1
7 Eth4 00:BD:DC:E3:57:00 1500 vmnet0
##################################### IP ######################################
nu ip /netmask ppp point_to_point_with
3 10.200.211.99 /255.255.255.0 0
5 127.0.0.1 /255.0.0.0 0
6 192.168.0.1 /255.255.255.0 0
############################## ArpCache/Neighbor #############################
nu ethernet ip
3 00:0A:41:C7:BA:80 10.200.211.1
3 00:30:48:41:F9:56 10.200.211.99
3 00:C0:4F:61:3F:72 10.200.211.52
6 00:BD:CA:09:00:01 192.168.0.1
#################################### Routes ###################################
nu destination /netmask source gateway metric
3 10.200.211.99 /255.255.255.255 local 0
5 127.0.0.1 /255.255.255.255 local 0
6 192.168.0.1 /255.255.255.255 local 0
3 10.200.211.0 /255.255.255.0 10.200.211.99 0
6 192.168.0.0 /255.255.255.0 192.168.0.1 0
5 127.0.0.0 /255.0.0.0 127.0.0.1 0
Command returned 0 (OK)
Press 'r' or 'k' to run again this tool, or any other key to continue

I know fxp0 is my main interface, and see Netwox calls it "Eth2". I can use this information to sniff with Netwox once I return to the main menu:

Select a node (key in 03456abcdefghijk): d

########################## sniff ###########################
0 - leave netwox
1 - go to main menu
2 - go to previous menu
3 - search tools' title
4 - display help of one tool
5 - run a tool selecting parameters on command line
6 - run a tool selecting parameters from keyboard
a - 7:Sniff
b - 10:Sniff and display network statistics
c - 11:Sniff and verify checksums
d - 13:Obtain DLT type for sniff and spoof for each device
e - 110:Ethernet bridge limiting flow
Select a node (key in 0123456abcde): a

################## help for tool number 7 ##################
Title: Sniff
Usage: netwox 7 [-d device] [-f filter] [-p] [-H encode] [-D encode] [-r] [-x]
[-i] [-t] [-s] [-o file] [-R recordencode] [-c uint32] [-C uint32]
name type description {example}
-d|--device device device name {Eth0}
-f|--filter filter pcap filter
-p|--pause|+p|--no-pause can pause {0}
-H|--hdrencode encode header encoding type for screen {array}
-D|--dataencode encode data encoding type for screen {dump}
-r|--rawip|+r|--no-rawip sniff at IP level {0}
-x|--extended|+x|--no-extended display other protocols (dns) {1}
-i|--ipreas|+i|--no-ipreas reassemble IP packets {0}
-t|--tcpreord|+t|--no-tcpreord reorder TCP packets {0}
-s|--screen|+s|--no-screen display to screen {1}
-o|--outfile file save in record file {dstfile.txt}
-R|--recordencode recordencode encoding type for record file {bin}
-c|--split-size uint32 maximum size of record in kb {0}
-C|--split-age uint32 maximum age of record in seconds {0}
Example: netwox 7
Press 'r' or 'k' to run this tool, or any other key to continue
################## running tool number 7 ###################
Enter optional tool parameters and press Return key.
netwox 7 -d Eth2 -f icmp

I just told network to sniff for ICMP on interface "Eth2". In the future I could simply run "netwox 7 -d Eth2 -f icmp" and dispense with the menus. Here are the results when I generate ICMP by pinging Google:

netwox 7 -d Eth2 -f icmp
Ethernet________________________________________________________.
| 00:30:48:41:F9:56->00:0A:41:C7:BA:80 type:0x0800 |
|_______________________________________________________________|
IP______________________________________________________________.
|version| ihl | tos | totlen |
|___4___|___5___|____0x00=0_____|___________0x0054=84___________|
| id |r|D|M| offsetfrag |
|_________0x3290=12944__________|0|0|0|________0x0000=0_________|
| ttl | protocol | checksum |
|____0x40=64____|____0x01=1_____|____________0x6796_____________|
| source |
|_________________________10.200.211.99_________________________|
| destination |
|________________________216.239.41.104_________________________|
ICMP4_echo request______________________________________________.
| type | code | checksum |
|____0x08=8_____|____0x00=0_____|_________0xA3C9=41929__________|
| id | seqnum |
|_________0xC849=51273__________|___________0x0000=0____________|
| data: 1322f8408e86070008090a0b0c0d0e0f101112131415161718191a1 |
| b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233343536 |
| 37 |
|_______________________________________________________________|

Ethernet________________________________________________________.
| 00:0A:41:C7:BA:80->00:30:48:41:F9:56 type:0x0800 |
|_______________________________________________________________|
IP______________________________________________________________.
|version| ihl | tos | totlen |
|___4___|___5___|____0x00=0_____|___________0x0054=84___________|
| id |r|D|M| offsetfrag |
|_________0x3290=12944__________|0|0|0|________0x0000=0_________|
| ttl | protocol | checksum |
|___0xF3=243____|____0x01=1_____|____________0xB495_____________|
| source |
|________________________216.239.41.104_________________________|
| destination |
|_________________________10.200.211.99_________________________|
ICMP4_echo reply________________________________________________.
| type | code | checksum |
|____0x00=0_____|____0x00=0_____|_________0xABC9=43977__________|
| id | seqnum |
|_________0xC849=51273__________|___________0x0000=0____________|
| data: 1322f8408e86070008090a0b0c0d0e0f101112131415161718191a1 |
| b1c1d1e1f202122232425262728292a2b2c2d2e2f30313233343536 |
| 37 |
|_______________________________________________________________|

This unique format is one of the cooler aspects of Netwox.



Monday, July 12, 2004

Review of Snort 2.1 Posted

Amazon.com just posted my four star review of Snort 2.1. Several quotes from my review of Snort 2.0 appear in the new book, even though I also gave that first edition four stars. From the end of the review of the new edition:

"I would enjoy seeing three improvements in the third edition. First, thoroughly scrub the book for old information. Watch out for people writing about 'Cerebus' or http_decode or offerings from Silicon Defense, whose Web site disappeared in early 2004. Second, tell people to read the excellent Snort manual before reading the book. There's no need to address topics well-covered in the manual, like all of the IP- and TCP-based rule options. Third, ditch the existing rules chapter in favor of two new ones, one explaining principles via existing rules, and one showing advanced rule development.

I still recommend buying this book, but you might guide your reading choices by the comments in this review."

Sunday, July 11, 2004

Using Oinkmaster to Update Snort Rules

I've never explained how I like to keep Snort rules updated on my sensors. The tool of choice for automatic rule updates is Andreas Ostling's Oinkmaster, a Perl script. Here is a sample run. First I make a temporary directory to hold old Snort rules files, then download and extract the snapshot version of Oinkmaster. (Oinkmaster 1.0 was released in May, but the snapshot includes some improvements discussed in the oinkmaster-users mailing list.)

[root@sensor root]# mkdir /tmp/oldrules
[root@sensor root]# cd /usr/local/src
[root@sensor src]# wget http://oinkmaster.sourceforge.net/oinkmaster-snapshot.tar.gz
--15:05:14-- http://oinkmaster.sourceforge.net/oinkmaster-snapshot.tar.gz
=> `oinkmaster-snapshot.tar.gz'
Resolving oinkmaster.sourceforge.net... done.
Connecting to oinkmaster.sourceforge.net[66.35.250.209]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 68,234 [application/x-tar]

100%[====================================>] 68,234 16.53K/s ETA 00:00

15:05:18 (16.53 KB/s) - `oinkmaster-snapshot.tar.gz' saved [68234/68234]

[root@sensor src]# tar -xzvf oinkmaster-snapshot.tar.gz
oinkmaster/
oinkmaster/contrib/
oinkmaster/contrib/README.contrib
oinkmaster/contrib/addmsg.pl
oinkmaster/contrib/addsid.pl
oinkmaster/contrib/create-sidmap.pl
oinkmaster/contrib/makesidex.pl
oinkmaster/contrib/oinkgui.pl
oinkmaster/ChangeLog
oinkmaster/FAQ
oinkmaster/INSTALL
oinkmaster/LICENSE
oinkmaster/README
oinkmaster/README.gui
oinkmaster/README.templates
oinkmaster/README.win32
oinkmaster/UPGRADING
oinkmaster/oinkmaster.1
oinkmaster/oinkmaster.conf
oinkmaster/oinkmaster.pl
oinkmaster/template-examples.conf

The default oinkmaster.conf is set up just as I want it to be. Namely, it knows to not update local.rules and snort.conf, which are customized for my environment. So, I copy the default oinkmaster.conf file to an alternative location, and then run Oinkmaster to see its default switches:

[root@sensor src]# cp oinkmaster/oinkmaster.conf /usr/local/etc/snort/oinkmaster.conf
[root@sensor src]# /usr/local/src/oinkmaster/oinkmaster.pl

Error: no output directory specified.

Oinkmaster v1.0 by Andreas Ostling (andreaso@it.su.se)

Usage: oinkmaster.pl -o outdir [options]

outdir is where to put the new files.
This should be the directory where you store your Snort rules.

Options:
-b dir Backup your old rules into dir before overwriting them
-c Careful mode - only check for changes and do not update anything
-C cfg Use this configuration file instead of the default
May be specified multiple times to load multiple files
-e Enable all rules that are disabled by default
-h Show this usage information
-i Interactive mode - you will be asked to approve the changes (if any)
-q Quiet mode - no output unless changes were found
-Q super-quiet mode (like -q but even more quiet when printing results)
-r Check for rules files that exist in the output directory
but not in the downloaded rules archive
-T Test configuration and then exit
-u url Download from this URL instead of the one in the configuration file
(must be http://, https://, ftp://, file:// or scp:// ... .tar.gz)
-U file Merge new variables from downloaded snort.conf into
-v Verbose mode
-V Show version and exit

I first run Oinkmaster with -c (careful mode) to see the changes it recommends:

[root@sensor src]# /usr/local/src/oinkmaster/oinkmaster.pl -c
-o /usr/local/etc/snort/rules -C /usr/local/etc/snort/oinkmaster.conf

Loading /usr/local/oinkmaster-1.0/oinkmaster.conf

Downloading file from http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz... done.

Archive successfully downloaded, unpacking... done.

Processing downloaded rules... disabled 0, enabled 0, modified 0, total=2113.

Setting up rules structures...

WARNING: duplicate SID in your local rules,
SID 2114 exists multiple times, please fix this manually!

WARNING: duplicate SID in your local rules,
SID 2113 exists multiple times, please fix this manually!

done.

Comparing new files to the old ones... done.

Skipping backup since we are running in careful mode.

Note: Oinkmaster is running in careful mode - not updating anything.

[***] Results from Oinkmaster started Sun Jul 11 14:44:43 2004 [***]

[+++] Added rules: [+++]

-> Added to ftp.rules (1):

alert tcp $EXTERNAL_NET any -> $HOME_NET 21
(msg:"FTP RETR format string attempt"; flow:to_server,established;
content:"RETR"; nocase; pcre:"/^RETR\s[^\n]*?%[^\n]*?%/smi";
reference:bugtraq,9800; classtype:attempted-admin; sid:2574; rev:1;)

-> Added to oracle.rules (1):

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS $ORACLE_PORTS
(msg:"ORACLE generate_replication_support prefix overflow attempt";
flow:to_server,established; content:"generate_replication_support";
nocase; pcre:"/(package|procedure)_prefix[\s\r\n]*=>
[\s\r\n]*('[^']{1000,}|"[^"]{1000,})/Rsmi";
classtype:attempted-user; sid:2576; rev:2;)

...edited...
[///] Modified active rules: [///]

-> Modified active in attack-responses.rules (4):

old: alert tcp $HOME_NET 749 -> $EXTERNAL_NET any
(msg:"ATTACK-RESPONSES successful kadmind buffer overflow attempt";
flow:established,from_server; content:"*GOBBLE*"; depth:8;
reference:cve,CAN-2002-1235; reference:url,www.kb.cert.org/vuls/id/875073;
classtype:successful-admin; sid:1900; rev:5;)

new: alert tcp $HOME_NET 749 -> $EXTERNAL_NET any
(msg:"ATTACK-RESPONSES successful kadmind buffer overflow attempt";
flow:established,from_server; content:"*GOBBLE*"; depth:8;
reference:bugtraq,5731; reference:bugtraq,6024; reference:cve,2002-1226;
reference:cve,2002-1235; reference:url,www.kb.cert.org/vuls/id/875073;
classtype:successful-admin; sid:1900; rev:10;)

old: alert tcp $HOME_NET 22 -> $EXTERNAL_NET any
(msg:"ATTACK-RESPONSES successful gobbles ssh exploit uname";
flow:from_server,established; content:"uname"; reference:bugtraq,5093;
classtype:misc-attack; sid:1811; rev:5;)

new: alert tcp $HOME_NET 22 -> $EXTERNAL_NET any
(msg:"ATTACK-RESPONSES successful gobbles ssh exploit uname";
flow:from_server,established; content:"uname"; reference:bugtraq,5093;
reference:cve,2002-0390; reference:cve,2002-0639; classtype:misc-attack;
sid:1811; rev:8;)

...edited...

[///] Modified inactive rules: [///]

-> Modified inactive in exploit.rules (1):

old: #alert tcp $EXTERNAL_NET any -> $HOME_NET 22
(msg:"EXPLOIT ssh CRC32 overflow filler"; flow:to_server,established;
content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|";
reference:bugtraq,2347; reference:cve,CVE-2001-0144;
classtype:shellcode-detect; sid:1325; rev:4;)

new: #alert tcp $EXTERNAL_NET any -> $HOME_NET 22
(msg:"EXPLOIT ssh CRC32 overflow filler"; flow:to_server,established;
content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|";
reference:bugtraq,2347; reference:cve,2001-0144; reference:cve,2001-0572;
classtype:shellcode-detect; sid:1325; rev:6;)

...edited...

[---] Removed rules: [---]

-> Removed from ftp.rules (1):

alert tcp $EXTERNAL_NET any -> $HOME_NET 21
(msg:"FTP format string attempt"; flow:to_server,established;
content:"%p"; nocase; classtype:attempted-admin; sid:1530; rev:4;)

[*] Non-rule line modifications: [*]

None.

[+] Added files: [+]

-> classification.config
-> gen-msg.map
-> reference.config
-> sid-msg.map
-> threshold.conf
-> unicode.map

You'll see I highlighted some of the output. These show the various categories of modifications made by Oinkmaster. Once we are confident that Oinkmaster isn't going to make any changes we don't like, we run it in update mode by removing the "-c" flag. We add the "-b" flag and specify a directory to hold a backup of the old ruleset:

[root@sensor src]# /usr/local/src/oinkmaster/oinkmaster.pl -b /tmp/oldrules
-o /usr/local/etc/snort/rules -C /usr/local/etc/snort/oinkmaster.conf

Loading /usr/local/oinkmaster-1.0/oinkmaster.conf
...truncated...

Oinkmaster makes an archive of the rules in /tmp/oldrules:

[root@sensor src]# ls /tmp/oldrules/
rules-backup-20040711-144820.tar.gz

Notice that in the original test run, Oinkmaster found duplicate rule SIDs of 2113 and 2114. Oinkmaster should discard the old version, but a manual check finds duplicate rules:

[root@sensor src]# grep -i 2113 /usr/loca/etc/snort/rules/*.rules

rservices.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 512
(msg:"RSERVICES rexec username overflow attempt"; content:"|00|"; offset:9;
content:"|00|"; distance:0; content:"|00|"; distance:0;
classtype:attempted-admin; sid:2113; rev:2;)

rservices.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 512
(msg:"RSERVICES rexec username overflow attempt"; flow:to_server,established;
content:"|00|"; offset:9; content:"|00|"; distance:0; content:"|00|";
distance:0; classtype:attempted-admin; sid:2113; rev:3;)

[root@sensor src]# grep -i 2114 /usr/local/etc/snort/rules/*.rules

rservices.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 512
(msg:"RSERVICES rexec password overflow attempt"; content:"|00|";
content:"|00|"; distance:33; content:"|00|"; distance:0;
classtype:attempted-admin; sid:2114; rev:2;)

rservices.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 512
(msg:"RSERVICES rexec password overflow attempt"; flow:to_server,established;
content:"|00|"; content:"|00|"; distance:33; content:"|00|"; distance:0;
classtype:attempted-admin; sid:2114; rev:3;)

This isn't a big deal. A quick deletion with vi removes the old rules, both having revision number 2.

Remember that after updating the rule set, Snort must be restarted. I prefer to stop Snort and then run it in the foreground to make sure it accepts all of the rules. Once it seems to be running ok, I stop and start it in the background as a daemon with the -D switch.

Saturday, July 10, 2004

Another Chapter, Plus Foreword and Index from Book Posted

My publisher Addison-Wesley made a few more excerpts from my book The Tao of Network Security Monitoring: Beyond Intrusion Detection available online. The 48-page file bejtlich_chs.pdf contains chapter 2, "What is NSM?" and the previously announced chapter 10, "NSM with Sguil." You can also read Ron Gula's foreword or peruse the 34-page index in .pdf form.

Currently the Addison-Wesley site lists 16 July as the availability date for the book. Amazon.com shows 1 July, which is wrong, while Barnes and Noble shows 28 July. The actual release date should be sometime next week or the week after.

Friday, July 09, 2004

Review of BSD Hacks Posted

Amazon.com just posted my five star review of BSD Hacks. This is a great book and a must-buy for all BSD users. From the review:

"BSD Hacks is the book I hoped to read. I've been using FreeBSD in production and test environments for about four years (since 4.1 REL), and I've played with OpenBSD and NetBSD for about a year each. I was looking for a book that would explore the nooks and crannies of BSD without covering the introductory issues often found elsewhere. By hack 10 I had already learned enough to justify purchasing BSD Hacks. Unless you're a member of the core team, you'll find enough tricks and tips to make BSD Hacks a welcome addition to your system administration library."

Thursday, July 08, 2004

Sguil Development Issues

Lots has been happening in the Sguil world this past week. Bamm released Sguil 0.5.0 last week. The major development was the merging of xscriptd functionality into sguild. That's one less component to worry about.

I also made some changes to the instructions for building IncrTcl in my Sguil installation guide, thanks to Mark Bergstrom. My guide still applies to Sguil 0.5.0, although the advice on xscriptd now belongs in the sguild configuration section. I'll produce a new guide for Sguil 0.5.1 when it arrives, as I hope to incorporate Snort 2.2.0 as well.

After nearly four years of asking Bamm for feature requests in various apps he's written, I finally committed my own change to Sguil. I committed a change to sguil.tk and qrylib.tcl to support querying for events by source or destination port. Unfortunately I made a mistake merging my changes into the version I checked into CVS, and Bamm made a correction to sguil.tk shortly after my commit! I duplicated a line by mistake.

Nevertheless, I thought it might be interesting to share the commands I used to check out and then check in the Sguil code for those who don't use CVS.

First I checked out the latest Sguil distro. I made a directory to separate that code from my home directory, and then set an environment variable telling CVS to use SSH for transport:

drury:/home/analyst$ cd sguil_devel

drury:/home/analyst/sguil_devel$ export CVS_RSH=ssh


Next I checked out the Sguil code:

drury:/home/analyst/sguil_devel$ cvs -d:ext:taosecurity@cvs.sf.net:/cvsroot/sguil
checkout sguil

taosecurity@cvs.sf.net's password:

cvs checkout: Updating sguil

U sguil/README

cvs checkout: Updating sguil/client

U sguil/client/sguil.conf

U sguil/client/sguil.tk

cvs checkout: Updating sguil/client/lib

U sguil/client/lib/dkffont.tcl

U sguil/client/lib/email17.tcl

...truncated...

Next I made the changes I needed to the Sguil code, and committed them. Note I did this from the 'sguil' directory:

drury:/home/analyst/sguil_devel/sguil$ cvs commit

cvs commit: Examining .

cvs commit: Examining client

cvs commit: Examining client/lib

...edited...
cvs commit: Examining web/data

cvs commit: Examining web/lib

taosecurity@cvs.sf.net's password:


After entering my password, I was dropped into a vi session. There I was asked to create my log entry for the changes I made. When done CVS checked in the files I modified:

Checking in client/sguil.tk;

/cvsroot/sguil/sguil/client/sguil.tk,v <-- sguil.tk

new revision: 1.121; previous revision: 1.120

done

Mailing sguil-cvs@lists.sf.net...

Generating notification message...

Generating notification message... done.

Checking in client/lib/qrylib.tcl;

/cvsroot/sguil/sguil/client/lib/qrylib.tcl,v <-- qrylib.tcl

new revision: 1.19; previous revision: 1.18

done

Mailing sguil-cvs@lists.sf.net...

Generating notification message...

Generating notification message... done.


In the #snort-gui IRC channel on irc.freenode.net, this message appeared:

taosecurity * sguil/client (2 files in 2 dirs):
Added ability to query events for source or destination ports.

CIA-7 is a reference to the CIA Open Source Notification System, an IRC bot. You can see that message saved here. We also use Infobot and Pastebot to keep track of various pieces of information in the #snort-gui channel.

Wednesday, July 07, 2004

External 2.5 Hard Drive Enclosure

This isn't the most exciting topic, but I wanted to report another successful piece of hardware with FreeBSD. Earlier I wrote about the Adaptec DuoConnect PC Card adapter which provides my laptop with FireWire (but not USB 2.0, unfortunately). To add some external high-speed storage to my laptop, I bought a ByteCC 2.5 HDD enclosure with FireWire and USB 2.0 from XPCGear.com. I liked this model because I could buy an AC adapter with it. I could have drawn power from the laptop's single on-board USB 1.1 port, but I prefer to leave that free as the USB 2.0 ports on the Adaptec card don't work properly under FreeBSD.

Here is how a 30 GB HDD appeared in dmesg output when plugged into the Adaptec adapter using FireWire:

GEOM: create disk da0 dp=0xc3a81450
da0 at sbp0 bus 0 target 0 lun 0
da0: Fixed Direct Access SCSI-0 device
da0: 50.000MB/s transfers, Tagged Queueing Enabled
da0: 28615MB (58605120 512 byte sectors: 255H 63S/T 3648C)

As this was a NTFS drive, I mounted it using mount_ntfs:

orr:/$ sudo mount_ntfs /dev/da0s1 /mnt

/dev/da0s1 on /mnt (ntfs, local)

This model also ships with a handy carrying case for the drive. The guys at XPCGear.com were very helpful, and actually answered by phone a question I posted during the checkout procedure!

Tuesday, July 06, 2004

FreeBSD on the Dell PowerEdge 750

Several months ago I asked the readership of the freebsd-hardware mailing list if anyone had experience with the Dell PowerEdge 750 1U server, especially its DELL CERC SATA 1.5/6ch RAID-0 (an Adaptec card) setup. Today we finally received a system on which I could test FreeBSD, so these are my results.

I found I could not load FreeBSD 5.2.1 on the box. Although I was able to get through the boot procedure, FreeBSD did not see the hard drive. I decided to try the same snapshot of FreeBSD-CURRENT from 17 Jun 04 that worked on my Dell PowerEdge 2300. Thankfully the RAID-0 setup was recognized as a single 465 GB hard drive. It was device aacd0, indicating use of the aac driver. Once I saw this I checked the CVS files associated with the aac driver and saw no substantial changes to the code since my 17 Jun snapshot was taken.

The installation proceeded normally until newfs started. At that point the system froze. I cycled through the virtual terminals and saw this message:

Entropy device is blocked. Dance fandango on keyboard to unblock.

This was weird, so I banged away on the keyboard for a few seconds. Sure enough the installation continued and completed without errors. Doing some research I found posts on 20 Jun, 28 May, and earlier about this very issue. The fix should be appear in 5.3 RELEASE. Discussion of this system appeared as recently as two weeks ago.

To test the box's speed, I ran make buildkernel and got these timing results:

--------------------------------------------------------------
>>> Kernel build for fedorov completed on Tue Jul 6 17:16:06 EDT 2004
--------------------------------------------------------------
611.591u 311.459s 15:16.78 100.6% 2580+2531k 3514+2998io 2839pf+0w

The CPU supports HyperThreading Technology, so the 5 CURRENT kernel's out-of-the-box support for SMP results in seeing two logical CPUs:

CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2800.11-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf34 Stepping = 4
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Hyperthreading: 2 logical CPUs
real memory = 536608768 (511 MB)
avail memory = 515424256 (491 MB)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1

I posted the dmesg output for this box to the NYCBUG dmesg list.

OpenOffice.org 1.1.2 Packages Available for FreeBSD

I learned from this post that packages of OpenOffice.org 1.1.2 are available. I intend to upgrade via package since building OOo using the ports tree takes forever.

I also learned a few lessons about document management this past weekend while creating slides for my USENIX talk. I found that I could create and save a presentation in .sxi format, only to have OOo not able to open it. I lost several hours worth of work due to this flaw. I was unable to open several .sxi files built with OOo 1.1.1 on FreeBSD, and was unable to get OOo 1.1.1 on Fedora Core 2 or OOo 1.1.2 on Windows 2000 to read the problematic .sxi either.

I dealt with this in two ways. First, I chopped up my presentation into eight smaller files. This limited the damage in the event some slide became corrupt and prevented access to the rest of the presentation. Second, I saved every presentation in .sxi and .ppt formats. That way I could try opening the presentation in PowerPoint if OOo decided not to read the file it just saved.

I made use of the built-in bug reporting on OOo on FC2 to send a message to the OOo team.