In the last article, you learned what Snort is, and how to get it installed and running on your system. You also saw that Snort performs three critical and fundamental functions:
- Packet sniffing: Snort can monitor packets, both incoming and outgoing, directed at the machine it's installed on. It also can monitor packets on the network it's running on, and quite a bit more. This is probably Snort's most basic function, and everything else it does depends on this ability to detect and observe network traffic in a packet form.
- Packet logging: Snort can not only monitor packets in real time, but also log those packets. Logging lets you manually, or automatically, deal with those packets, and to have some record of what's happened. Whether you're weeding through old packets searching for an intrusion, or Snort is sounding a software alert based on something it just logged, packet logging takes you from a real-time tool to a tool that can persist the data it reacts to in various forms.
- Intrusion detection: In lots of ways, intrusion detection is just packet sniffing combined with logging, with a layer of automated intelligence thrown on top of it all. An intrusion detection system (or IDS) has a set of rules that, combined with knowledge of what's going on across a network, can provide monitoring and response to potentially problematic situations on your network.
In this article, I'll go well beyond installation and configuration, and talk about how to set up Snort to detect Web-related intrusions. You'll also see how Snort can be configured with up-to-date rules, and run in the "background" of everything your servers do.
Note: This article is not really focused on Snort from the system administrator's point of view. There's a lot to learn about Snort, and it can detect intrusions ranging from attacks on your IRC services to Web-related problems to malicious code attempting to access your machine on protected ports. This article, though, focuses specifically on what Web designers and developers should know to suggest improvements for protection of their specific projects and applications. For more general Snort resources, refer to the various links in Resources.
In the last article, I left off by providing a quick look at Snort's three functions,, and looking at a few packets. For instance, run snort -v to get output that looks a bit like Listing 1.
Listing 1. Sniffing with Snort
[bdm0509:~] sudo snort -v
Password:
Running in packet dump mode
--== Initializing Snort ==--
Initializing Output Plugins!
Verifying Preprocessor Configurations!
***
*** interface device lookup found: en0
***
Initializing Network Interface en0
Decoding Ethernet on interface en0
--== Initialization Complete ==--
,,_ -*> Snort! <*-
o" )~ Version 2.8.0.2 (Build 75)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2007 Sourcefire Inc., et al.
Using PCRE version: 7.6 2008-01-28
Not Using PCAP_FRAMES
03/31-08:55:12.179192 192.168.1.102:64862 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10292 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:12.179498 192.168.1.102:64863 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10293 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:12.180121 192.168.1.102:64864 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10294 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:12.180278 192.168.1.102:64865 -> 239.255.255.253:427
UDP TTL:1 TOS:0x0 ID:10295 IpLen:20 DgmLen:64
Len: 36
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:12.247880 192.168.1.102:64866 -> 192.168.1.255:137
UDP TTL:64 TOS:0x0 ID:10296 IpLen:20 DgmLen:78
Len: 50
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:12.248297 192.168.1.103:137 -> 192.168.1.102:64866
UDP TTL:64 TOS:0x0 ID:8075 IpLen:20 DgmLen:90
Len: 62
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:12.599248 192.168.1.102:55381 -> 192.168.1.101:139
TCP TTL:64 TOS:0x0 ID:10297 IpLen:20 DgmLen:64 DF
******S* Seq: 0x42127B5E Ack: 0x0 Win: 0xFFFF TcpLen: 44
TCP Options (8) => MSS: 1460 NOP WS: 0 NOP NOP TS: 1428368232 0
TCP Options => SackOK EOL
...
LOTS more output here
...
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:21.976018 0.0.0.0:68 -> 255.255.255.255:67
UDP TTL:64 TOS:0x0 ID:48134 IpLen:20 DgmLen:328
Len: 300
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:21.976800 ARP who-has 192.168.1.104 tell 192.168.1.1
03/31-08:55:22.968515 192.168.1.1:67 -> 255.255.255.255:68
UDP TTL:150 TOS:0x0 ID:6040 IpLen:20 DgmLen:576
Len: 548
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:22.977578 ARP who-has 192.168.1.104 tell 192.168.1.104
^C*** Caught Int-Signal
Run time prior to being shutdown was 14.231224 seconds
===============================================================================
Packet Wire Totals:
Received: 78
Analyzed: 78 (100.000%)
Dropped: 0 (0.000%)
Outstanding: 0 (0.000%)
===============================================================================
Breakdown by protocol (includes rebuilt packets):
ETH: 78 (100.000%)
ETHdisc: 0 (0.000%)
VLAN: 0 (0.000%)
IPV6: 0 (0.000%)
IP6 EXT: 0 (0.000%)
IP6opts: 0 (0.000%)
IP6disc: 0 (0.000%)
IP4: 71 (91.026%)
IP4disc: 0 (0.000%)
TCP 6: 0 (0.000%)
UDP 6: 0 (0.000%)
ICMP6: 0 (0.000%)
ICMP-IP: 0 (0.000%)
TCP: 57 (73.077%)
UDP: 14 (17.949%)
ICMP: 0 (0.000%)
TCPdisc: 0 (0.000%)
UDPdisc: 0 (0.000%)
ICMPdis: 0 (0.000%)
FRAG: 0 (0.000%)
FRAG 6: 0 (0.000%)
ARP: 3 (3.846%)
EAPOL: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 4 (5.128%)
DISCARD: 0 (0.000%)
InvChkSum: 0 (0.000%)
Upconvt: 0 (0.000%)
Up fail: 0 (0.000%)
S5 G 1: 0 (0.000%)
S5 G 2: 0 (0.000%)
Total: 78
===============================================================================
Action Stats:
ALERTS: 0
LOGGED: 0
PASSED: 0
===============================================================================
Snort exiting |
Remember that you'll need to either run as the root user or use sudo. Those details are discussed in the last article if you've forgotten.
The challenge, of course, is to make some sense of this information. You can break it down a bit further into individual packets, like the one shown in Listing 2 (which is pulled directly from the results of Listing 1).
Listing 2. A single packet from the output shown in Listing 1
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:21.976800 ARP who-has 192.168.1.104 tell 192.168.1.1
03/31-08:55:22.968515 192.168.1.1:67 -> 255.255.255.255:68
UDP TTL:150 TOS:0x0 ID:6040 IpLen:20 DgmLen:576
Len: 548
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
What does all of this mean? And is it cause for concern?
It's (almost) all about the IP address
The most important thing you can learn from a packet comes from the IP addresses. The packet in Listing 2 has a few; they're called out in bold in Listing 3.
Listing 3. Focusing on the IP addresses in the packet from Listing 2
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
03/31-08:55:21.976800 ARP who-has 192.168.1.104 tell 192.168.1.1
03/31-08:55:22.968515 192.168.1.1:67 -> 255.255.255.255:68
UDP TTL:150 TOS:0x0 ID:6040 IpLen:20 DgmLen:576
Len: 548
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
There are two IP addresses mentioned here: 192.168.1.104, and 192.168.1.1. Additionally, in the second occurrence of 192.168.1.1, there's a port at the end. A port number comes at the end of an IP address after a colon, like this: 192.168.1.1:67.
Before you can make much sense of this, you need to know the IP address of your own
machine. You can use the Windows® command ipconfig or,
on Linux®, UNIX®, or a terminal in Mac OS X, ifconfig. In the example packet from Listing 3, 192.168.1.104 happens to be the IP address of the machine running Snort, and 192.168.1.1 is the router that machine's network uses to get to the outside world.
In this case, this packet is coming from a computer (the one running Snort, with the IP 192.168.1.104) and moving toward the router (192.168.1.1). Then, you've got some additional information, about the length, an ID, and some strange codes like TOS, TTL, and UDP.
Already, the process of digging into packets can seem a bit intimidating. If you're a
Web designer used to focusing on CSS styles and divs, or a
developer who'd rather consider how cohesive your classes are, or whether an interface
or an abstract class makes the most sense, packets fall somewhere between boring and
outright coma-inducing on the interest scale. Start adding a bunch of odd acronyms,
and you're probably already tempted to leave this article and find something interesting on CSS text replacement, or perhaps how to implement the Chain of Responsibility design pattern in C#.
It's this complexity and difficulty -- the confusion that often comes from staring at packets -- that Snort is best at unraveling. In fact, the entire reason Snort is so useful for a Web developer is because it allows for concentration on design patterns, layouts, and functional tasks. With Snort, beyond a basic understanding (most of which you have from the previous article and this section), you can let your tool do the work you don't want to. The remainder of this article, then, lays out how Snort can handle packet analysis, and how you can use community efforts to keep your systems safe, without you needing to relearn the things you've forgotten from that one required networking class you took in college.
Rather than you spending hours digging into packets, you can set Snort to handle analysis, and have Snort alert you when there are problems; you do this by giving Snort a set of rules. These rules, usually in the form of a text file, tell Snort what to do, give it information on key details to look for in packets, and instruct Snort as to what should happen if that key information is found. Further, these rules can limit what Snort listens to (such as instructing Snort to only worry about a single machine, or to monitor traffic on an entire network), as well as logging everything it finds and does to a file for easy review later.
Really, it's good use of Snort rules that saves you the work of manual packet analysis.
Before you can write rules, you need to tell Snort to function as an IDS. The easiest way to do this -- and to log packets -- is to use Snort's default configuration, stored in the etc/snort.conf file within your Snort installation directory (mine is in /usr/local/snort-2.8.1/etc/snort.conf). This sets up Snort in a pretty simple fashion and gets things running. Listing 4 shows a portion of the Snort configuration file.
Listing 4. The default snort.conf file
# stream5: Target Based stateful inspection/stream reassembly for Snort
# ---------------------------------------------------------------------
# Stream5 is a target-based stream engine for Snort. Its functionality
# replaces that of Stream4. Consequently, BOTH Stream4 and Stream5
# cannot be used simultaneously. Comment out the stream4 configurations
# above to use Stream5.
#
# See README.stream5 for details on the configuration options.
#
# Example config (that emulates Stream4 with UDP support compiled in)
preprocessor stream5_global: max_tcp 8192, track_tcp yes, \
track_udp no
preprocessor stream5_tcp: policy first, use_static_footprint_sizes
# preprocessor stream5_udp: ignore_any_rules
# Performance Statistics
# ----------------------
# Documentation for this is provided in the Snort Manual. You should read it.
# It is included in the release distribution as doc/snort_manual.pdf
#
# preprocessor perfmonitor: time 300 file /var/snort/snort.stats pktcnt 10000
# http_inspect: normalize and detect HTTP traffic and protocol anomalies
#
# lots of options available here. See doc/README.http_inspect.
# unicode.map should be wherever your snort.conf lives, or given
# a full path to where snort can find it.
preprocessor http_inspect: global \
iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default \
profile all ports { 80 8080 8180 } oversize_dir_length 500
#
# Example unique server configuration
#
#preprocessor http_inspect_server: server 1.1.1.1 \
# ports { 80 3128 8080 } \
# flow_depth 0 \
# ascii no \
# double_decode yes \
# non_rfc_char { 0x00 } \
# chunk_length 500000 \
# non_strict \
# oversize_dir_length 300 \
# no_alerts
# rpc_decode: normalize RPC traffic
# ---------------------------------
# RPC may be sent in alternate encodings besides the usual 4-byte encoding
# that is used by default. This plugin takes the port numbers that RPC
# services are running on as arguments - it is assumed that the given ports
# are actually running this type of service. If not, change the ports or turn
# it off.
# The RPC decode preprocessor uses generator ID 106
#
# arguments: space separated list
# alert_fragments - alert on any rpc fragmented TCP data
# no_alert_multiple_requests - don't alert when >1 rpc query is in a packet
# no_alert_large_fragments - don't alert when the fragmented
# sizes exceed the current packet size
# no_alert_incomplete - don't alert when a single segment
# exceeds the current packet size
preprocessor rpc_decode: 111 32771
# content goes on for a long time... |
So a single configuration statement looks something like this:
preprocessor rpc_decode: 111 32771 |
Snort has a lot of keywords that are in use here, and in keeping with the theme of providing a practical, what-you-need-to-know approach to Snort, I won't cover most of those. However, there are two things you should pick up from this file:
- Instructions to Snort amount to short pieces of information, usually involving either
preprocessorstatements about what to look for andoutputstatements (not shown in the sample in Listing 4) for issuing alerts. - The default snort.conf file is actually a pretty full-featured, usable configuration file. It's not just dummy data, but will actually work for your Snort installation.
After you've got a configuration file, you can run Snort as an intrusion detector (I'll add rules in just a moment). Listing 5 shows the output from starting Snort as an IDS, running in the foreground.
Listing 5. Running Snort as an IDS
bdm0509:/usr/local/snort-2.8.1] sudo snort -de -l logs/ -c etc/snort.conf
Running in IDS mode
--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file etc/snort.conf
PortVar 'HTTP_PORTS' defined : [ 80 ]
PortVar 'SHELLCODE_PORTS' defined : [ 0:79 81:65535 ]
PortVar 'ORACLE_PORTS' defined : [ 1521 ]
Frag3 global config:
Max frags: 65536
Fragment memory cap: 4194304 bytes
Frag3 engine config:
Target-based policy: FIRST
Fragment timeout: 60 seconds
Fragment min_ttl: 1
Fragment ttl_limit (not used): 5
Fragment Problems: 1
Stream5 global config:
Track TCP sessions: ACTIVE
Max TCP sessions: 8192
Memcap (for reassembly packet storage): 8388608
Track UDP sessions: INACTIVE
Track ICMP sessions: INACTIVE
Stream5 TCP Policy config:
Reassembly Policy: FIRST
Timeout: 30 seconds
Min ttl: 1
Options:
Static Flushpoint Sizes: YES
Reassembly Ports:
21 client (Footprint)
23 client (Footprint)
25 client (Footprint)
42 client (Footprint)
53 client (Footprint)
80 client (Footprint)
110 client (Footprint)
111 client (Footprint)
135 client (Footprint)
136 client (Footprint)
137 client (Footprint)
139 client (Footprint)
143 client (Footprint)
445 client (Footprint)
513 client (Footprint)
514 client (Footprint)
1433 client (Footprint)
1521 client (Footprint)
2401 client (Footprint)
3306 client (Footprint)
HttpInspect Config:
GLOBAL CONFIG
Max Pipeline Requests: 0
Inspection Type: STATELESS
Detect Proxy Usage: NO
IIS Unicode Map Filename: etc/unicode.map
IIS Unicode Map Codepage: 1252
DEFAULT SERVER CONFIG:
Server profile: All
Ports: 80 8080 8180
Flow Depth: 300
Max Chunk Length: 500000
Max Header Field Length: 0
Inspect Pipeline Requests: YES
URI Discovery Strict Mode: NO
Allow Proxy Usage: NO
Disable Alerting: NO
Oversize Dir Length: 500
Only inspect URI: NO
Ascii: YES alert: NO
Double Decoding: YES alert: YES
%U Encoding: YES alert: YES
Bare Byte: YES alert: YES
Base36: OFF
UTF 8: OFF
IIS Unicode: YES alert: YES
Multiple Slash: YES alert: NO
IIS Backslash: YES alert: NO
Directory Traversal: YES alert: NO
Web Root Traversal: YES alert: YES
Apache WhiteSpace: YES alert: NO
IIS Delimiter: YES alert: NO
IIS Unicode Map: GLOBAL IIS UNICODE MAP CONFIG
Non-RFC Compliant Characters: NONE
Whitespace Characters: 0x09 0x0b 0x0c 0x0d
rpc_decode arguments:
Ports to decode RPC on: 111 32771
alert_fragments: INACTIVE
alert_large_fragments: ACTIVE
alert_incomplete: ACTIVE
alert_multiple_requests: ACTIVE
Portscan Detection Config:
Detect Protocols: TCP UDP ICMP IP
Detect Scan Type: portscan portsweep decoy_portscan distributed_portscan
Sensitivity Level: Low
Memcap (in bytes): 10000000
Number of Nodes: 36900
ERROR: Unable to open rules file: ../rules/local.rules or etc/../rules/local.rules
Fatal Error, Quitting.. |
This looks pretty good until the last line. Snort expects to find some rule files, but when it doesn't, it errors out.
The default configuration includes several rules files
Snort has several standard rules files, with predetermined names and functions. If you open the snort.conf file again, and scroll to the bottom, you'll see a set of commands like Listing 6:
Listing 6. Bottom of snort.conf file
#################################################################### # Step #6: Customize your rule set # # Up to date snort rules are available at http://www.snort.org # # The snort Web site has documentation about how to write your own custom snort # rules. #========================================= # Include all relevant rulesets here # # The following rulesets are disabled by default: # # web-attacks, backdoor, shellcode, policy, porn, info, icmp-info, virus, # chat, multimedia, and p2p # # These rules are either site policy specific or require tuning in order to not # generate false positive alerts in most environments. # # Please read the specific include file for more information and # README.alert_order for how rule ordering affects how alerts are triggered. #========================================= include $RULE_PATH/local.rules include $RULE_PATH/bad-traffic.rules include $RULE_PATH/exploit.rules include $RULE_PATH/scan.rules include $RULE_PATH/finger.rules include $RULE_PATH/ftp.rules include $RULE_PATH/telnet.rules include $RULE_PATH/rpc.rules include $RULE_PATH/rservices.rules include $RULE_PATH/dos.rules include $RULE_PATH/ddos.rules include $RULE_PATH/dns.rules include $RULE_PATH/tftp.rules include $RULE_PATH/web-cgi.rules include $RULE_PATH/web-coldfusion.rules include $RULE_PATH/web-iis.rules include $RULE_PATH/web-frontpage.rules include $RULE_PATH/web-misc.rules include $RULE_PATH/web-client.rules include $RULE_PATH/web-php.rules include $RULE_PATH/sql.rules include $RULE_PATH/x11.rules include $RULE_PATH/icmp.rules include $RULE_PATH/netbios.rules include $RULE_PATH/misc.rules include $RULE_PATH/attack-responses.rules include $RULE_PATH/oracle.rules include $RULE_PATH/mysql.rules include $RULE_PATH/snmp.rules include $RULE_PATH/smtp.rules include $RULE_PATH/imap.rules include $RULE_PATH/pop2.rules include $RULE_PATH/pop3.rules include $RULE_PATH/nntp.rules include $RULE_PATH/other-ids.rules # include $RULE_PATH/web-attacks.rules # include $RULE_PATH/backdoor.rules # include $RULE_PATH/shellcode.rules # include $RULE_PATH/policy.rules # include $RULE_PATH/porn.rules # include $RULE_PATH/info.rules # include $RULE_PATH/icmp-info.rules # include $RULE_PATH/virus.rules # include $RULE_PATH/chat.rules # include $RULE_PATH/multimedia.rules # include $RULE_PATH/p2p.rules # include $RULE_PATH/spyware-put.rules # include $RULE_PATH/specific-threats.rules include $RULE_PATH/experimental.rules # include $PREPROC_RULE_PATH/preprocessor.rules # include $PREPROC_RULE_PATH/decoder.rules # Include any thresholding or suppression commands. See threshold.conf in the # <snort src>/etc directory for details. Commands don't necessarily need to be # contained in this conf, but a separate conf makes it easier to maintain them. # Note for Windows users: You are advised to make this an absolute path, # such as: c:\snort\etc\threshold.conf # Uncomment if needed. # include threshold.conf |
The file attempts to include a number of rules files, the most primary of these lines being this one:
include $RULE_PATH/local.rules |
Then, what you'll need to get Snort running is a set of rules it can load and work from.
Tell Snort what to do with rules
A rule in Snort terminology is just an instruction to Snort; specifically, a rule is about how to inspect, analyze, or report on packets. While configuration is a more general set of rules about how Snort should operate, rules tell Snort what to do every time a packet comes across a network interface that Snort monitors.
A rule in Snort has two basic components:
- It tells Snort something specific to look for in a packet, such as
GETin a Web request or a specific port in a telnet connection. - It tells Snort what to do when it finds that something specific. Many times this is simply triggering an alert, allowing you to respond to those alerts.
So for each potentially intrusive connection, Snort needs a rule (or rules that cover multiple related intrusions). Of course, the problem with this approach should be quickly apparent: there are a lot of intrusions you have to worry about. How is even a full-time network administrator or system administrator going to keep up with all the different intrusions that are out there, especially when new ones are cropping up every day? Even worse, if you're a Web developer doubling as the "Snort guy" at a small shop, or trying to convince your already-overworked admins to add Snort to their responsibilities, this becomes even more impossible. Thankfully, though, Snort provides relief for just these situations.
Because Snort is such a technical, network-specific product, the folks that keep improving Snort also keep up with the types of intrusions that are currently in vogue -- and how to detect and respond to those intrusions. Every time a new release of Snort comes out, a new set of "default" rules is made available to go with that release. This default set of rules basically covers all the things you want to protect against, and makes it easy to get things going.
Navigate to the Snort Web site (links are in the Resources section), and click the Rules link in the left navigation. Along the top of the rules page, you'll see a gray navigation bar where you can click VRT Rules. Scroll down to the registered user section, where you can get a set of rules to match the release of Snort you're using; this portion of the Snort site is shown in Figure 1.
Note: Make sure you're logged in before attempting to download these rules.
Figure 1. Downloading default rules from the Snort Web site
This download process downloads a ZIP file, named something like snortrules-snapshot-2.8.tar.gz. Expand this, and you'll get a folder named something like snortrules-snapshot-2.8_s. This folder has contents that look like Figure 2.
Figure 2. Expanded rules from the Snort Web site
By default, Snort looks for, at a minimum, a rules file called local.rules in a directory called rules within the Snort installation. So to take advantage of the rules you just downloaded, simply copy or move the expanded rules folder into your Snort installation directory:
[bdm0509:/usr/local/snort-2.8.1] cp -rp ~/Downloads/snortrules-snapshot-2.8_s/rules . |
You should also copy over the etc/ directory in the rules you downloaded. This updates your default configuration to include any additional rules files that might be needed for this release of the rules:
[bdm0509:/usr/local/snort-2.8.1] cp -rp ~/Downloads/snortrules-snapshot-2.8_s/etc . |
When you've done all of this, your Snort directory structure should look like Listing 7.
Listing 7. A Snort installation directory with a rules directory
[bdm0509:/usr/local/snort-2.8.1] ls
COPYING autom4te.cache configure.in ltmain.sh snort.8
ChangeLog config.guess contrib m4 src
LICENSE config.h depcomp missing stamp-h1
Makefile config.h.in doc mkinstalldirs templates
Makefile.am config.log etc preproc_rules verstuff.pl
Makefile.in config.status install-sh rpm ylwrap
RELEASE.NOTES config.sub libtool rules
aclocal.m4 configure logs schemas |
There are a lot of rules in that nested directory, as well. Listing 8 shows all the rules files you got from the Snort site.
Listing 8. The rules in Snort's rules/ directory
[bdm0509:/usr/local/snort-2.8.1] ls rules
Makefile.am info.rules smtp.rules
VRT-License.txt local.rules snmp.rules
attack-responses.rules misc.rules specific-threats.rules
backdoor.rules multimedia.rules spyware-put.rules
bad-traffic.rules mysql.rules sql.rules
cgi-bin.list netbios.rules telnet.rules
chat.rules nntp.rules tftp.rules
content-replace.rules open-test.conf virus.rules
ddos.rules oracle.rules voip.rules
deleted.rules other-ids.rules web-attacks.rules
dns.rules p2p.rules web-cgi.rules
dos.rules policy.rules web-client.rules
experimental.rules pop2.rules web-coldfusion.rules
exploit.rules pop3.rules web-frontpage.rules
finger.rules porn.rules web-iis.rules
ftp.rules rpc.rules web-misc.rules
icmp-info.rules rservices.rules web-php.rules
icmp.rules scan.rules x11.rules
imap.rules shellcode.rules |
If you try and run Snort on most platforms at this stage, you're ready to go. However, there are some problems specific to Mac OS X worth mentioning, especially if you're using a Mac as a testing machine before taking Snort to one of your production UNIX or Linux servers. There are several steps you need to perform to get Snort running properly on Mac OS X.
First, you need to remove your current Snort installation and rebuild a lot of it. This doesn't involve manually deleting files, though. Simply run this command:
make clean |
This command cleans up any files before you rebuild your installation in a Mac OS X-centric way. Then, issue the following commands:
[bdm0509:/usr/local/snort-2.8.1] glibtoolize --force Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL' [bdm0509:/usr/local/snort-2.8.1] sudo aclocal -I m4 Password: [bdm0509:/usr/local/snort-2.8.1] sudo autoheader [bdm0509:/usr/local/snort-2.8.1] sudo automake --add-missing --copy [bdm0509:/usr/local/snort-2.8.1] sudo autoconf [bdm0509:/usr/local/snort-2.8.1] export LD_TWOLEVEL_NAMESPACE=1 |
Now, you can run the make command again, and then run the
make install command, as detailed in the last article.
You'll get a lot of output, and Snort will be ready to run... almost.
You'll need to make one more change, this time to the etc/snort.conf configuration file. Locate the following line in the snort.conf file. (It's easiest to find this line by searching for "dynamicengine.")
# # Load a dynamic engine from the install path # (same as command line option --dynamic-engine-lib) # dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so |
Comment out the dynamicengine line by inserting a # symbol
before the line, and add the line shown below in bold:
#
# Load a dynamic engine from the install path
# (same as command line option --dynamic-engine-lib)
#
#dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so
dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.dylib
|
You'll have to make several other similar changes. Search for "Step #2", and you'll see a section like Listing 9:
Listing 9. Searching for Step #2 in the code
#################################################### # Step #2: Configure dynamic loaded libraries ## If snort was configured to use dynamically loaded libraries, # those libraries can be loaded here.# # Each of the following configuration options can be done via# the command line as well. ## Load all dynamic preprocessors from the install path # (same as command line option --dynamic-preprocessor-lib-dir) # dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_dcerpc_preproc.so dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_dns_preproc.so dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_ftptelnet_preproc.so dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_smtp_preproc.so dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_ssh_preproc.so # Comment out above and uncomment this if running OSX # #dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_dcerpc_preproc.dylib #dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_dns_preproc.dylib #dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_ftptelnet_preproc.dylib #dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_smtp_preproc.dylib #dynamicpreprocessor file /usr/local/lib/snort_dynamicpreprocessor/libsf_ssh_preproc.dylib |
Note: Several of these lines are artificially broken to make this easily printable and viewable on the Web. Each of these instructions is on a single line in snort.conf, and that's the way you should keep these lines in your own configuration files.
You'll need to essentially follow the instructions. Comment out the first several lines, and uncomment out the later lines, as shown in Listing 10.
Listing 10. Showing which lines to comment and uncomment
####################################################
# Step #2: Configure dynamic loaded libraries
## If snort was configured to use dynamically loaded libraries,
# those libraries can be loaded here.#
# Each of the following configuration options can be done via# the command line as well.
## Load all dynamic preprocessors from the install path
# (same as command line option --dynamic-preprocessor-lib-dir)
#
#dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_dcerpc_preproc.so
#dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_dns_preproc.so
#dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_ftptelnet_preproc.so
#dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_smtp_preproc.so
#dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_ssh_preproc.so
# Comment out above and uncomment this if running OSX
#
dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_dcerpc_preproc.dylib
dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_dns_preproc.dylib
dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_ftptelnet_preproc.dylib
dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_smtp_preproc.dylib
dynamicpreprocessor
file /usr/local/lib/snort_dynamicpreprocessor/libsf_ssh_preproc.dylib
|
Now, you're ready to run Snort. It may seem like a lot of work, but this sort of configuration is fairly common for network- and system-related tools. And, best of all, you only have to do this sort of thing once (or, a few times).
Before continuing, though, note that because most rules include a new version of the snort.conf file, you'll need to perform this last step every time you copy over a new version of the file or the etc/ directory.
The details of these go well beyond the scope of this article, and get into true network and system administrator issues that, as a Web developer or designer, aren't worth taking the time to dig into. For now, trust these instructions, and if you're interested in more of what's really going on, visit the Snort forums online (see Resources).
With a default set of rules, and the tweaks required for Mac OS X implemented if you're using that platform, you're ready to fire up Snort. The command you should issue is shown in Listing 11, along with a good portion of its output.
Listing 11. Run Snort (without errors)
[bdm0509:/usr/local/snort-2.8.1] sudo snort -de -l logs/ -c etc/snort.conf
Running in IDS mode
--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file etc/snort.conf
PortVar 'HTTP_PORTS' defined : [ 80 ]
PortVar 'SHELLCODE_PORTS' defined : [ 0:79 81:65535 ]
PortVar 'ORACLE_PORTS' defined : [ 1521 ]
Frag3 global config:
Max frags: 65536
Fragment memory cap: 4194304 bytes
Frag3 engine config:
Target-based policy: FIRST
Fragment timeout: 60 seconds
Fragment min_ttl: 1
Fragment ttl_limit (not used): 5
Fragment Problems: 1
Stream5 global config:
Track TCP sessions: ACTIVE
Max TCP sessions: 8192
Memcap (for reassembly packet storage): 8388608
Track UDP sessions: INACTIVE
Track ICMP sessions: INACTIVE
Stream5 TCP Policy config:
Reassembly Policy: FIRST
Timeout: 30 seconds
Min ttl: 1
Options:
Static Flushpoint Sizes: YES
Reassembly Ports:
21 client (Footprint)
23 client (Footprint)
25 client (Footprint)
42 client (Footprint)
53 client (Footprint)
80 client (Footprint)
...
LOTS more output like this for a while...
...
+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
8771 Snort rules read
8771 detection rules
0 decoder rules
0 preprocessor rules
8771 Option Chains linked into 501 Chain Headers
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++
+-------------------[Rule Port Counts]---------------------------------------
| tcp udp icmp ip
| src 1011 38 0 0
| dst 6684 429 0 0
| any 494 117 20 7
| nc 15 4 3 4
| s+d 16 16 0 0
+----------------------------------------------------------------------------
+-----------------------[thresholding-config]----------------------------------
| memory-cap : 1048576 bytes
+-----------------------[thresholding-global]----------------------------------
| none
+-----------------------[thresholding-local]-----------------------------------
| gen-id=1 sig-id=12224 type=Limit tracking=src count=1 seconds=600
| gen-id=1 sig-id=12228 type=Limit tracking=src count=1 seconds=30
| gen-id=1 sig-id=7055 type=Limit tracking=src count=1 seconds=300
| gen-id=1 sig-id=7069 type=Limit tracking=src count=1 seconds=300
| gen-id=1 sig-id=7068 type=Limit tracking=src count=1 seconds=300
| gen-id=1 sig-id=7074 type=Limit tracking=src count=1 seconds=600
| gen-id=1 sig-id=12121 type=Limit tracking=src count=1 seconds=300
| gen-id=1 sig-id=12122 type=Limit tracking=src count=1 seconds=18000
...
More packet information rolling by...
...
+-----------------------[suppression]------------------------------------------
| none
-------------------------------------------------------------------------------
Rule application order: activation->dynamic->pass->drop->alert->log
Log directory = logs/
Verifying Preprocessor Configurations!
Warning: 'ignore_any_rules' option for Stream5 UDP disabled because of UDP rule with
flow or flowbits option
Warning: flowbits key 'access.download' is set but not ever checked.
Warning: flowbits key 'dce.bind.mqqm' is checked but not ever set.
Warning: flowbits key 'sylk.download' is set but not ever checked.
Warning: flowbits key 'AdvancedSpy_detection' is set but not ever checked.
Warning: flowbits key 'works.download' is set but not ever checked.
Warning: flowbits key 'mspub_header' is set but not ever checked.
358 out of 512 flowbits in use.
***
*** interface device lookup found: en0
***
Initializing Network Interface en0
Decoding Ethernet on interface en0
[ Port Based Pattern Matching Memory ]
+-[AC-BNFA Search Info Summary]------------------------------
| Instances : 835
| Patterns : 210306
| Pattern Chars : 1938187
| Num States : 1108715
| Num Match States : 177685
| Memory : 26.49Mbytes
| Patterns : 5.86M
| Match Lists : 7.21M
| Transitions : 13.36M
+-------------------------------------------------
--== Initialization Complete ==--
,,_ -*> Snort! <*-
o" )~ Version 2.8.1 (Build 28)
'''' By Martin Roesch & The Snort Team:
http://www.snort.org/team.html
(C) Copyright 1998-2008 Sourcefire Inc., et al.
Using PCRE version: 6.5 01-Feb-2006
Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.8
<Build 13>
Preprocessor Object: SF_SSH Version 1.1 <Build 1>
Preprocessor Object: SF_SMTP Version 1.1 <Build 7>
Preprocessor Object: SF_FTPTELNET Version 1.1 <Build 10>
Preprocessor Object: SF_DNS Version 1.1 <Build 2>
Preprocessor Object: SF_DCERPC Version 1.1 <Build 4>
Not Using PCAP_FRAMES
System will wait here until you exit Snort...
^C*** Caught Int-Signal
Run time prior to being shutdown was 356.123989 seconds
===============================================================================
Packet Wire Totals:
Received: 893
Analyzed: 893 (100.000%)
Dropped: 0 (0.000%)
Outstanding: 0 (0.000%)
===============================================================================
Breakdown by protocol (includes rebuilt packets):
ETH: 893 (100.000%)
ETHdisc: 0 (0.000%)
VLAN: 0 (0.000%)
IPV6: 4 (0.448%)
IP6 EXT: 0 (0.000%)
IP6opts: 0 (0.000%)
IP6disc: 0 (0.000%)
IP4: 884 (98.992%)
IP4disc: 0 (0.000%)
TCP 6: 0 (0.000%)
UDP 6: 0 (0.000%)
ICMP6: 0 (0.000%)
ICMP-IP: 0 (0.000%)
TCP: 807 (90.370%)
UDP: 74 (8.287%)
ICMP: 3 (0.336%)
TCPdisc: 0 (0.000%)
UDPdisc: 0 (0.000%)
ICMPdis: 0 (0.000%)
FRAG: 0 (0.000%)
FRAG 6: 0 (0.000%)
ARP: 5 (0.560%)
EAPOL: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
InvChkSum: 458 (51.288%)
S5 G 1: 0 (0.000%)
S5 G 2: 0 (0.000%)
Total: 893
===============================================================================
Action Stats:
ALERTS: 33
LOGGED: 33
PASSED: 0
===============================================================================
Frag3 statistics:
Total Fragments: 0
Frags Reassembled: 0
Discards: 0
Memory Faults: 0
Timeouts: 0
Overlaps: 0
Anomalies: 0
Alerts: 0
FragTrackers Added: 0
FragTrackers Dumped: 0
FragTrackers Auto Freed: 0
Frag Nodes Inserted: 0
Frag Nodes Deleted: 0
===============================================================================
Stream5 statistics:
Total sessions: 62
TCP sessions: 18
UDP sessions: 44
ICMP sessions: 0
TCP Prunes: 0
UDP Prunes: 0
ICMP Prunes: 0
TCP StreamTrackers Created: 20
TCP StreamTrackers Deleted: 20
TCP Timeouts: 4
TCP Overlaps: 0
TCP Segments Queued: 0
TCP Segments Released: 0
TCP Rebuilt Packets: 0
TCP Segments Used: 0
TCP Discards: 120
UDP Sessions Created: 46
UDP Sessions Deleted: 46
UDP Timeouts: 2
UDP Discards: 0
Events: 0
===============================================================================
HTTP Inspect - encodings (Note: stream-reassembled packets included):
POST methods: 0
GET methods: 0
Post parameters extracted: 0
Unicode: 0
Double unicode: 0
Non-ASCII representable: 0
Base 36: 0
Directory traversals: 0
Extra slashes ("//"): 0
Self-referencing paths ("./"): 0
Total packets processed: 238
===============================================================================
Snort exiting |
This is a lot of output, and points out why running Snort on the command-line like this is a fairly short-term, ineffective way to use Snort. It's much better to have your admins run Snort on a long-term, continuous basis, preferably as a system or background process.
Before talking more about the anatomy of a rule, though, you should break down each
component of the command used to run Snort, in the command sudo
snort -de -l logs/ -c etc/snort.conf, as shown in Listing 11. Here's what each component does:
-
sudo: Allows you to run Snort with administrative privileges. This was discussed in the last article, but in short, Snort needs more permissions than most typical users have. -
snort: Obviously, this runs Snort. -
-de: The "d" option causes Snort to listen and display application-layer data, and "e" displays link layer packet headers. Without getting into unnecessary detail, this option essentially provides the most verbose form of logging that Snort allows for in terms of packet sniffing. -
-l logs/: Tells Snort to log the packets and alerts it produces, and to put them all in the logs/ directory. -
-c etc/snort.conf: Indicates to use etc/snort.conf as the configuration file to run Snort.
After you've got Snort running with a current ruleset, you can expand your horizons, and look at writing your own rules. This is a great way to add security and checks for specific problems that relate to you, and means things like Web-based attacks and HTTP-related issues should be your focus. First, though, you need just a tad more concept and theory behind how a rule is structured.
There are a couple of general types of rules you'll see. By taking a look at each, you'll get a basic idea of what you can do with Snort rules.
-
Rules that mine packets based on the port they're directed at. These rules focus on the port a packet is being sent to. It's pretty easy to determine what ports applications should have open, so this is a way of monitoring potentially illegal traffic on unexpected or closed ports. One of the most common offenders here is IRC (Internet Relay Chat), and here's a rule that prevents exploitation over common IRC ports:
alert tcp $EXTERNAL_NET any -> $HOME_NET 6666:7000 (msg:"EXPLOIT CHAT IRC topic overflow"; flow:to_client,established; content:"|EB|K[S2|E4 83 C3 0B|K|88 23 B8|Pw"; reference:bugtraq,573; reference:cve,1999-0672; classtype:attempted-user; sid:307; rev:9;)
-
Rules that mine packets based on their protocol. These rules focus on the protocol used, like HTTP or IP Mobility. For example, here's a rule that detects a possibly malicious type of SMTP SSL request:
alert tcp $SMTP_SERVERS 465 -> $EXTERNAL_NET any (msg:"SMTP SSLv2 Server_Hello request"; flow:from_server,established; flowbits:isset,sslv2.client_hello.request; content:"|04|"; depth:1; offset:2; content:"|00 02|"; depth:2; offset:5; flowbits:set,sslv2.server_hello.request; flowbits:noalert; metadata:policy balanced-ips drop, policy connectivity-ips drop, policy security-ips drop, service smtp; classtype:protocol-command-decode; sid:3497; rev:4;)
-
Rules that mine packets based on the application involved. There are lots of applications that aren't troublesome in themselves, but have potential security holes, like when a port or protocol used normally by that app has vulnerabilities. Here's a rule to prevent a particularly nasty hole in Access allowing for download requests that are improper:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"WEB-CLIENT Microsoft Access file download request"; flow:to_server, established; content:"GET"; nocase; uricontent:".mdb"; nocase; flowbits:set,access.download; flowbits:noalert; metadata:service http; reference:url,support.microsoft.com/kb/925330; classtype:misc-activity; sid:13627; rev:1;)
As in the case of packets, you don't have to understand every option in these rules; in fact, you should just eyeball these rather than get overly worried about what nocase means, or how the rule author knew that IRC traffic usually flows over ports 6666 through 7000. It's been said several times, and it's still true: if you're a designer, be a designer; if you're a programmer, be a programmer. Focus on your core competencies, and then know enough about Snort to help get it going. From there, it's the network or system administrator's job to dig into every little option.
Despite not knowing all the ins and outs of rules, there are a few you should keep on hand. These are things that you want to protect against, focus on the Web or Web-related problems, and aren't always part of the default rule set you can get from Snort.
First, you should always protect against your machine -- the one serving your Web content to millions of users -- from being used as a mail relay. That's how most spammers work: they send mail through another unprotected machine and hide their own identity. There are actually two hugely important reasons to go to great lengths to protect against this:
- Spam is bad. That's rather obvious, but who wants their server to be a resource for spammers?
- Your server's IP could get blocked. This is an even bigger issue for the Web developer. If other networks -- and their admins -- realize that your server is the source of spam, they're likely to block your server's IP address from access to or from their network. In some cases, this only affects mail (mail from your server is blocked or blacklisted). In some cases, though, all traffic to and from your network or IP address could get blocked. And that means when someone tries to access your site from that network, they'll be blocked, too... meaning you've just cut your user base.
Listing 12 shows a simple rule you can add to your Snort setup to take care of relaying.
Listing 12. A rule to prevent mail relaying
alert tcp $SMTP_SERVERS 25 -> $EXTERNAL_NET any
(msg:"Possible mail relay usage"; content:"Relaying denied";
flags:A+; classtype:trojan-activity; sid:1000001; rev:1;) |
Sometimes you want Snort to issue what amounts to an informational alert. These alerts provide useful data, but require further analysis by real humans. One good example of this is the 403 - forbidden message that Web servers generate when a resource is requested that's not allowed. Snort can detect all of these "403 - forbidden" errors, and issue an alert. You'd get something like this:
HTTP/1.0 403 Access denied to 72.187.80.82/../../windows/system/cmd.exe |
Obviously, this isn't just a mistaken URL or a bad link... it's someone trying to make malicious use of a command-line executable. Of course, you might also get an alert like this:
HTTP/1.0 403 Access denied to 203.42.142.32/images/sg_talking.jpg |
This looks like a pretty innocent situation; maybe something as simple as an image with bad permissions. So in the first case, you'd want to see if you need to blacklist an IP or network, and in the second, you need to check your application. In any case, you want the information about a 403 so you can make these sorts of decisions. Listing 13 shows the rule that reports on this.
Listing 13. A rule to report on 403 responses
alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any
(msg:"ATTACK-RESPONSES 403 Forbidden"; flow:from_server,established;
content:"HTTP/1.1 403"; depth:12; classtype:attempted-recon; sid:1201; rev:7;) |
This rule actually comes standard with Snort in later versions, but if you happen to be somewhere that Snort was already set up, make sure this rule is in place. Better yet, you might get some benefit from having the admins mail you the alerts that this rule generates, perhaps once a month. It will let you see any potential security issues in your own application design.
Try to avoid becoming the Snort guru
One last word of warning, especially to those of you in smaller organizations: be careful you don't become the Snort guru. You can easily learn and invest so much time in Snort that you're no longer able to do what you enjoy: design sites and build Web applications. Certainly, if you want to get more into networking, dig into Snort as much as you like. But you're better off pointing your current admins to articles like this one and encouraging them to do the work, rather than becoming a conduit for all their Snort knowledge.
At some point, now that you've gotten a taste for security, you're also going to have to (re-)let go. In other words, it's easy to learn a bit about Snort or other IDSes, and get pretty paranoid. There are lots of ways to attack Web applications, and you'll never be able to protect against all of them. Even more important than familiarity and even mastery of Snort is a good relationship with your admins. Let them know your security needs and concerns, and then let them do their job. You'll benefit in the long run a lot more than you would by wresting security responsibilities from their grasp, and trying to do it all yourself.
It must be said that Snort is really a tool that falls firmly in the domain of the system and network administrator. If you're a Web developer or application programmer, you're probably going to get some odd looks if you engage your admins in a conversation about their Snort installation (or the lack thereof). You should also be prepared for a little resistance if you hand over this article, or a text file with some Snort rules in it, to your admin.
That said, it's you who puts all the work into a perfectly designed and executed Web site, or a finely tuned Web application. Because of that, it's not only foolish, but even irresponsible, to entrust the protection of your hard work to someone else in totality. With a little work, some forethought, and some lengthy conversation with your admins, you've got a good chance of getting at least a few of the tips, tricks, and rules detailed in these two articles into your company's Snort setup. If you're at a smaller organization, you may end up being responsible for Snort yourself. That's okay, too; it allows you to protect your application the way it should be protected, and most of all, ensures that your Web sites will run when you're sleeping, and that cell phones, pagers, and ringers stay off late at night.
Most of all, Snort informs you about the bigger context of your Web application. Your site and app runs in a very public environment if you've chosen to locate it on the Internet; you shouldn't just assume things will go okay. However you interact with the admins and other people in your organization, a solid understanding of Snort is a huge step toward making sure your apps run long after you've developed and deployed them.
Learn
- The first part of this series, Using Snort, Part 1:
Installation and configuration (developerWorks, June 2007), walks you through the
details of getting Snort installed and ready to help you start detecting intrusions to your Web site.
- Everything about Snort begins with the Snort Web site.
- Red Hat Linux has a nice feature on securing your Red Hat Linux system with Snort. It's a bit dated, but the basic concepts all still apply.
- If you want the power of Snort, but would prefer a commercial product with professional support, check out Sourcefire's IDS built on top of Snort.
- You can get your Snort questions answered online by visiting the Snort forums online.
Get products and technologies
- The Snort downloads home has all the Snort binaries and source file downloads.
- You can download a C compiler
for Mac OS X from the Apple Developer Connection. You'll need an account, but registration and download is free.
- Download the Perl Compatible Regular Expressions library.
-
WinPcap allows Snort link-layer network access on Windows platforms.
-
Managing
Security with Snort and IDS Tools
(Kerry Cox and Christopher Gerg, O'Reilly Media, Inc.) provides a more general introduction to security, as well as a ton of Snort-specific content for managing your sites.
- The
Snort
Cookbook
(Angela Orebaugh, Simon Biles, and Jacob Babbin, O'Reilly Media, Inc.) is a terrific resource for getting into Snort and performing specific tasks, ranging from basic installation to advanced intrusion detection and network optimization.
Discuss
-
developerWorks blogs: Get involved in the developerWorks community.
Brett McLaughlin is a bestselling and award-winning non-fiction author. His books on computer programming, home theater, and analysis and design have sold in excess of 100,000 copies. He has been writing, editing, and producing technical books for nearly a decade, and is as comfortable in front of a word processor as he is behind a guitar, chasing his two sons around the house, or laughing at reruns of Arrested Development with his wife. His last book, Head First Object Oriented Analysis and Design, won the 2007 Jolt Technical Book award. His classic Java and XML remains one of the definitive works on using XML technologies in the Java language.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
WebSphere Application Server can take you to the next step in the evolution of Web Development that lends itself to the creation of rich Web 2.0 user interfaces.
- Try: Download a free trial version of WebSphere Application Server Community Edition, a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby..
- Article: This article introduces you to the web development with WebSphere Application Server Feature Pack for Web 2.0. Its a good look at solutions for creating Ajax-based web apps and mashups.
- Tutorial: This tutorial takes you through the PHP and Java steps to master Facebook application Web development with the no-charge WebSphere Application Server Community Edition Web server.
- Demo: This demo showcases the WebSphere Application Server Community Edition administrative console feature set and walks you through deployment of a Web application.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
