My personal favorite set of rules. They detect when a host on your
local network is sending a known response to a successful attack.
While it might not be as useful as catching the attacker before he
has succeeded, the alerts these rules generate are very often not
false positives. There are some that are a little noisy—in
particular the rule that alerts on a "403 -
Forbidden" HTTP response.
Detects traffic generated by backdoor network connections,
including those created by attackers using many rootkits and stealthy
remote control applications (like subseven,
netbus, and deepthroat).
Watches for illegal packet header
settings like a TCP and UDP port 0 traffic, or a SYN packet to a
Disabled by default. It watches for people using
instant messengers and other Internet
chat protocols. If this activity is
against your organization's security policy, enable
this rule set.
Alerts on traffic generated by many well-known distributed
The Stacheldraht rules can be noisy, since
they are just looking for specific words in the payload that may be
common in your environment.
Actually not referenced by default in the
snort.conf file; really just a museum of old
Alerts on attacks against DNS servers (including detection of
Detects traffic generated by known
attacks. It will detect some specifically named attacks like
winnuke and jolt, but will
also detect classes of attacks like IGMP and
This is where new types of rules are included. This file is included
by default, so check it for new rules. Very often this is just an
Includes the signatures of many known
exploits. Seeing an alert generated by these rules should not cause
immediate panic. They indicate that an exploit
attempt has occurred. When you see one of these
alerts, verify that the target system is, in fact, vulnerable to the
attack. Hopefully, you have the system patched or updated to address
the vulnerability the exploit attempted to attack.
Alerts on many known types of attack against the
finger service that runs by default on many
Unix-based operating systems. If you have the finger service disabled
on your systems (I do, where possible), you can disable this rule
Generates alerts when known attacks are detected against the
This noisy little set of rules is disabled by default. It may be
useful when troubleshooting a specific ICMP problem on your network, but in
general it just generates noise and should remain disabled.
Alerts when it sees the signs of pings
specific to particular attack tools. These alerts can be very useful.
The "destination unreachable" rules
can be very noisy, though, and if you choose to keep this set of
rules enabled, consider turning off the loud
Generates alerts when known attacks against the
IMAP email service are detected.
Disabled by default. They generate alerts on a variety of traffic
that is normally found on a healthy, secure network. They may be
useful in troubleshooting some issues, though.
that you create.
Contains rules that don't fit easily into other
categories. In my experience, they generate a large number of false
positives on traffic that should not be a concern on a network that
utilizes reasonable defense-in-depth strategies. I usually disable
this entire rule set.
Disabled by default. If it is against your
organization's security policies to run
multimedia applications across the
network, enable this rule set.
Detects known attacks against
mySQL database servers.
Detects several of the recent Windows-attacking worms that
are causing headaches for network and system administrators around
the world. Some of the alerts can generate false positives (namely
the administrative share access rules and the rules that alert on SMB
and NetBIOS access). If the Snort sensor is watching Internet traffic
only and NetBIOS traffic is not allowed in or out of your
environment, consider disabling this rule set.
Contains signatures that indicate attack against
Detects known attacks against
Oracle database servers.
Watches for traffic generated by other
IDSs. If you are the only
person authorized to run an IDS in your environment, this can be a
relevant concern. You can likely disable this rule set.
Disabled by default. They detect activity generated
by peer to peer software. Peer to
peer clients can represent a dangerous vector for the introduction of
viruses, worms, and other malicious code into your environment. If
your organization has policies against the use of such software,
enable this rule set.
Disabled by default. It contains rules that watch for activity that
may against some organization's security policies
(for example, an alert will be generated by PC Anywhere and VNC
traffic, or an anonymous FTP login). Consider reviewing the rules in
this file and leaving those that match your policies enabled, while
disabling the rest (after enabling the rule set itself, of course).
Generates alerts when known POP2 email service attacks
Generates alerts when known POP3 email service attacks
Disabled by default, these rules will alert when a variety of
off-color packet contents go by on the wire. If it is against your
organization's security policy to visit such content
on the Internet, consider enabling the rule set (but be prepared for
some... interesting alerts).
Generates alerts on attacks against the remote procedure call (RPC) services employed
by nearly every operating system. If the sensor is watching Internet
traffic and RPC activity is not allowed in or out of the environment,
consider disabling this set of rules. If the sensor is watching
internal traffic, some tuning may be necessary, depending on the
types of systems running on the network.
(rlogin, rsh, and
rexec) are detected on the network. These are
powerful commands to control remote systems. If you use these in your
environment, you may want to disable this rule set.
Detects a variety of different
network and service scans, from deceptive
portscans to SSH and UpnP service scans. It detects the signatures of
some specific scanning tools, too.
Disabled by default. It will detect shellcode in the
packet payload that is attempting to compromise a variety of systems.
This shellcode may be the payload of a successful attack that does
not have its own signature. Since these rules are designed the check
the payloads of all traffic, they can cause a significant performance
hit when enabled.
Generates alerts when known SMTP email service attacks
Detects a variety of SNMP traffic. SNMP is used to manage
devices on a network and many vulnerabilities have been detected in
the protocol. If you are running a sensor that is only watching
Internet traffic and SNMP traffic is not allowed in or out, you can
disable this rule set.
Detects known attacks against Microsoft SQL Server database servers.
Alerts on dangerous traffic transmitted in telnet sessions.
Alerts on attacks against the TFTP service.
Disabled by default. This rule set is not being actively maintained
and the rules really just watch for a variety of file extensions
transmitted in email traffic. The real virus signatures are located
within the specific service's rule sets now.
Disabled by default. It generates alerts when known generic attacks
against web servers are detected. Consider enabling
it, since it does not generate a large number of false positives.
Generates alerts when known attacks against CGI services are
Generates alerts when potentially dangerous web client traffic is
detected. Most of these alerts are based on Microsoft
Outlook Web Access traffic and
generate a large number of false positives. Consider disabling this
Generates alerts when known attacks against
Coldfusion web application
services are detected.
Generates alerts when known attacks against
Frontpage web authoring services are
Detects known attacks against Microsoft Internet Information Server (IIS) web
Generic web attack detection rules.
Detects attacks against web servers running
PHP applications (primarily runs on
Apache, but it is possible to run on IIS).
Detects attacks against remote X-Windows