plugins: change return codes of geany_load_module() and GeanyPluginFuncs::init
[geany-mirror.git] / tests / ctags / 3526726.tex
blobdbf072baf6620ddb40f14e90fcaf2cb1de6ba77a
1 % $Id$
3 %latex2html -info 0 -local_icons -show_section_numbers -link 2 -split +1 faq.tex
4 \documentclass{article}
5 \usepackage{html}
6 \usepackage{graphicx}
7 \usepackage{fancyhdr}
8 \usepackage{makeidx}
10 %% Margins
11 \oddsidemargin 0in
12 \evensidemargin 0in
13 \textwidth 6.5in
14 \topmargin 0in
15 \textheight 8in
16 \setlength{\parindent}{0in}
17 \setlength{\parskip}{.5\baselineskip}
19 \pagestyle{fancy}
21 \lhead{ {\sc Snort FAQ} }
22 \cfoot{ {\sc feed the pig}}
23 \rhead{Page \thepage}
25 \newcommand{\myref}[1]{(see FAQ \ref{#1})}
26 \newcommand{\myquote}[1]{\begin{quote}#1\end{quote}}
28 %\label{key} assign current counter value to key
29 %\myref{key}{print value assigned to key}
31 % To emphasise
32 % {\em blah}
34 % To bold
35 % {\bf bold face }
37 % The following characters are special characters and need to be backslashed
38 % before use:
39 % $ & % # _ { }
41 % To get a backslash, try $\backslash$
43 \makeindex
45 \begin{document}
47 \title{ The Snort FAQ }
48 \author{ The Snort Core Team }
49 \date{ }
51 % Title Page
53 \maketitle
55 \newpage
57 Suggestions for enhancements of this document are always welcome. Please email them to the \htmladdnormallink{Snort-Users}{mailto:snort-users@lists.sourceforge.net} mailing list.
59 Many people have contributed to this FAQ:
60 \begin{center}
61 \begin{tabular}{llll}
62 Marty Roesch & Fyodor Yarochkin & Dragos Ruiu & Jed Pickel\\
64 Max Vision & Michael Davis & Joe McAlerney & Joe Stewart\\
66 Erek Adams & Roman Danyliw & Christopher Cramer & Frank Knobbe\\
68 Phil Wood & Toby Kohlenberg & Ramin Alidousti & Jim Hankins\\
70 Dennis Hollingworth & Paul Howell & Stef Mit & Ofir Arkin\\
72 Jason Haar & Blake Frantz & Lars Norman S?ndergaard & Brent Erickson\\
74 Brian Caswell & Scot Wiedenfeld & Chris Green & Jeff Wirth\\
76 Edin Dizdarevic & Detmar Liesen & Don Ng & Matt Kettler\\
78 Joe Lyman & Jim Burwell & Jed Haile & Andrew Hutchinson\\
80 Jeff Nathan & Alberto Gonzalez & Jason Haar & Jeremy Hewlett
81 \end{tabular}
82 \end{center}
88 If you do not see your name on this list and you have contributed to the faq,
89 please email \htmladdnormallink{bugs@snort.org}{mailto:bugs@snort.org}.
92 Dragos Ruiu: This version of this guide has been brought to you by the kind
93 generosity and sponsorship of Wiley and Sons publishers whose support let
94 myself, and other snort developers Jeff Nathan and Jed Haile take the time to
95 work on this document and other tutorials for Snort due out in our upcoming
96 book. (route++)
99 \newpage
101 \begin{latexonly}
102 \tableofcontents
104 \newpage
105 \end{latexonly}
107 \section{Background}
109 \subsection{How do you pronounce the names of some of these guys who work on Snort?}
111 For the record, `Roesch' is pronounced like `fresh' without the `f.'
112 Additionally, `Ruiu' is pronounced like `screw you' without the `sc.'
113 Jed's last name is like `pick-el,' not `pickle.'
115 \subsection{Is Fyodor Yarochkin the same Fyodor who wrote nmap?}
117 Nope. fyodor@insecure.org is the author of nmap, and he uses the same pseudonym as the other Snort Fyodor's real surname. Yeah, it messes up my mailbox too, but I think it's too late to change either of them.
119 \subsection{Where do I get more help on Snort?}
121 Check the website, \htmladdnormallink{http://www.snort.org/}{http://www.snort.org/}. Other good resources are available in the source distribution, including the \htmladdnormallink{Snort Users Manual}{http://www.snort.org/docs} and the USAGE file. There is also a excellent mailing list, snort-users. You can find
122 info on how to signup at \htmladdnormallink{http://www.snort.org/community/mailing-lists/}{http://www.snort.org/community/mailing-lists}. You can also join
123 \#snort on irc.freenode.net.
125 \subsection{Where can I get more reading and courses about IDS?\label{courses}}
127 All of the following offer courses on Intrusion Detection:
128 \begin{itemize}
129 \item \htmladdnormallink{SANS (http://www.sans.org)}{http://www.sans.org}
130 \item \htmladdnormallink{Usenix (http://www.usenix.org/event/)}{http://www.usenix.org/event/}
131 \item \htmladdnormallink{Networld/Interop (http://www.key3media.com/interop/)}{http://www.key3media.com/interop/}
132 \item \htmladdnormallink{CanSecWest (http://www.cansecwest.com)}{http://www.cansecwest.com}
133 \end{itemize}
135 There are many good books on Intrusion Detection. Here are just a few:
137 \begin{tabular}{|p{2in}|p{1.5in}|l|l|}
138 \hline
139 {\bf Title} & {\bf Author(s)} & {\bf Publisher} & {\bf ISBN}\\
140 \hline\hline
141 Snort 2.1 Intrusion Detection, Second Edition & Brian Caswell, Jay Beale & 1931836043 \\
142 \hline
143 Tao of Network Security Monitoring, The: Beyond Intrusion Detection & Richard Bejtlich & 0321246772 \\
144 \hline
145 Intrusion Detection with Snort: Advanced IDS Techniques & Rafeeq Rehman & Prentice Hall & I0131407333\\
146 \hline
147 Snort Intrusion Detection & Ryan Russell & Syngress Media & 1931836744 \\
148 \hline
149 Snort Intrusion Detection & Jack Koziol & New Riders & 157870281X\\
150 \hline
151 Network Intrusion Detection: An Analyst's Handbook & Stephen Northcutt & New Riders & 0735708681 \\
152 \hline
153 Intrusion Signatures and Analysis & Stephen Northcutt & New Riders & 0735710635 \\
154 \hline
155 TCP/IP Illustrated, Volume 1 The Protocols & W. Richard Stevens & Addison-Wesley & 0201633469 \\
156 \hline
157 Intrusion Detection & Rebecca G. Bace & MacMillan Technical Publishing & 1578701856 \\
158 \hline
159 The Tao of Network Security Monitoring: Beyond Intrusion Detection & Richard Bejtlich & Addison-Wesley & 0321246772 \\
160 \hline
161 Snort 2.1 Intrusion Detection, Second Edition & Brian Caswell \& Jay Beale & Syngress Publishing & 1931836043 \\
162 \hline
163 \end{tabular}
166 \subsection{Does Snort handle IP defragmentation?}
168 Yes, use {\tt preprocessor frag3}.
170 \subsection{Does Snort perform TCP stream reassembly?}
172 Yes, check out the stream4 preprocessor \myref{stream4} that does stateful
173 analysis session login, TCP reassembly and much, much more.
175 \subsection{Does Snort perform stateful protocol analysis?}
177 Yes. Stream4 does this as well. See \myref{stream4}.
179 \subsection{I'm on a switched network, can I still use Snort?}
181 {\bf Short version:}
183 Being able to sniff on a switched network depends on what type of switch is
184 being used. If the switch can mirror traffic, then set the switch to mirror all
185 traffic to the Snort machine's port.
187 {\bf Extended version:}
189 There are several ways of deploying NIDS in switched environments which all
190 have their pros and cons. Which method applies to your needs depends on what
191 kind of segments you want to monitor and on your budget. Here are the most
192 common methods:
194 \begin{enumerate}
195 \item {\bf Switch mirror:} If the switch can mirror traffic, then set the switch to
196 mirror all traffic to the Snort machine's port.
197 \begin{itemize}
198 \item Advantages:
199 \begin{itemize}
200 \item Simple method, works with most decent switches.
201 \end{itemize}
202 \item Drawbacks:
203 \begin{itemize}
204 \item If the switch is a fast Ethernet switch, you can mirror 100Mbit/s
205 max. Since each switch port is capable of handling 100Mbit/s for each
206 direction, the bandwidth per port sums up to 200Mbit/s, so the switch
207 will not be able to mirror all packets at high network utilization.
209 \item Some switches suffer from performance degradation through port
210 mirroring.
211 \end{itemize}
212 \end{itemize}
213 \item {\bf Hub:} Insert a hub in line, so you can simply tap all traffic. Works
214 fine for home networks, will lose data due to collisions at loads greater
215 than 50\%---so a 10Mbps hub should be fine for T1/E1, DSL or cablemodem. If
216 you have a DS3 or greater, you should investigate taps.
217 \begin{itemize}
218 \item Advantages:
219 \begin{itemize}
220 \item Simple method
221 \item No impact on switch performance and no config changes
222 \item Low cost
223 \end{itemize}
224 \item Drawbacks:
225 \begin{itemize}
226 \item Loss of full-duplex capabilities
227 \item Additional single point of failure
228 \item Collision loss at above 50\% load levels
229 \end{itemize}
230 \end{itemize}
231 \item {\bf Network taps:} Use network taps (e.g. Shomiti/Finisar [\htmladdnormallink{http://www.shomiti.com}{http://www.shomiti.com}] and Netoptics [\htmladdnormallink{http://www.netoptics.com}{http://www.netoptics.com}). You can find some rather good information in the papers by Jeff Nathan. You can find the papers at
232 \htmladdnormallink{http://www.snort.org/docs/\#deploy}{http://www.snort.org/docs/\#deploy}.
233 \begin{itemize}
234 \item Advantages:
235 \begin{itemize}
236 \item No impact on switch performance and no special configuration
237 \item Stealth---i.e., sending data back to the switch is disabled
238 \item No single point of failure, ``fail-open'' if the tap power fails
239 \end{itemize}
240 \item Drawbacks:
241 \begin{itemize}
242 \item The datastream is split into TX and RX, so you need two NICs
243 \item The two datastreams have to be recombined, i.e. merged, if you don't
244 want to lose the capability of doing stateful analysis. This can be
245 done by using channel bonding. Information can be found at
246 \htmladdnormallink{http://sourceforge.net/projects/bonding}{http://sourceforge.net/projects/bonding}.
247 \item Cost
248 \end{itemize}
249 \end{itemize}
251 \item {\bf Throw money at it:} Tap switch ports (using the forementioned
252 network taps) but only tap all incoming packets (RX lines of the switch
253 ports), connecting those tap ports to a dedicated gigabit switch, which is
254 capable of mirroring up to ten RX taplines to one single dedicated gigabit
255 port, which is connected to a gigabit IDS machine.
256 \begin{itemize}
257 \item Advantages:
258 \begin{itemize}
259 \item Maximum coverage (i.e. monitor all switchports)
260 \item No performance degradation or re-configuration of the switch
261 \end{itemize}
262 \item Drawbacks:
263 \begin{itemize}
264 \item Mucho \$\$\$
265 \end{itemize}
266 \end{itemize}
267 \end{enumerate}
269 \subsection{Is Snort vulnerable to IDS noise generators like ``Stick'' and ``Snot''?}
271 It is now possible to defeat these kinds of noise generators with
272 the stream4 preprocessor (see \myref{stream4}). Even without the stream4 preprocessor
273 enabled, Snort will weather the alert storm without falling over
274 or losing a lot of alerts due to its highly optimized nature.
275 Using tools that generate huge amounts of alerts will warn a good
276 analyst that someone is trying to sneak by their defenses.
278 \subsection{Can Snort be evaded by the use of polymorphic mutators on shellcode?}
280 Yes, and this could defeat some of the NOP sled detection signatures,
281 but the ordinary exploit rules should not be affected by this kind
282 of obfuscation. The fnord preprocessor attempts to detect polymorphic
283 shellcode attempts.
285 \subsection{Does Snort log the full packets when it generates alerts? }
287 Yes, the packets should be in the directory that has the same IP address as the
288 source host of the packet which generated the alert. If you are using binary
289 logging, there will be a packet capture file (.pcap) in the logging directory
290 instead.
292 \section{Getting Started}
294 \subsection{Where do I find binary packages for BlueHat BSD-Linux-RT?}
296 Repeat after me:
298 \begin{verbatim}
299 Go to http://www.snort.org/snort-downloads
300 Click the link for the <release> tar.gz
301 tar zxvf snort-<release>.tar.gz
302 cd <release>
303 ./configure
304 make
306 make install
307 mkdir /var/log/snort
308 cd etc
309 vi snort.conf
310 snort -D -c snort.conf
311 exit
312 \end{verbatim}
314 ...and if you want to use our binary package uninstaller :-):
315 \begin{verbatim}
316 cd <release>; make uninstall
317 \end{verbatim}
319 And if you must, you can find some binaries at \htmladdnormallink{http://www.snort.org/snort-downloads}{http://www.snort.org/snort-downloads}.
320 You can also find Snort in most BSD ports' trees.
322 \subsection{How do I run Snort?}
324 Run Snort in sniffer mode and make sure it can see the packets.
326 \begin{verbatim}snort -dv\end{verbatim}
328 Then run it with the HOME\_NET set appropriately for the network
329 you're defending in your rules file. A default rules file comes with the
330 snort distribution and is called ``snort.conf'' You can run this basic ruleset
331 with the following command line:
333 \begin{verbatim}snort -A full -c snort.conf\end{verbatim}
335 If it's all set right, make sure the interface is in promiscuous mode by running the
336 command from another window:
338 \begin{verbatim}ifconfig -a\end{verbatim}
340 The output from ifconfig should show if the interface is in promiscuous mode.
341 If it's not, there should be a way to set it manually.
343 Note that the default output mode (-A full) of Snort should not be
344 used except in very controlled environments. It is the slowest way
345 to run Snort and presents several hard to recover from problems
346 with inode creation on filesystems.
348 For people doing real IDS work, use something like (-A fast -b) to
349 combine fast alert mode with tcpdump binary log files or use the
350 unified format coupled with Barnyard.
352 \subsection{Where are my log files located? What are they named?}
354 The default location for logs is /var/log/snort. If snort is started with ``-l
355 $<$directory$>$'', then the logs will be located in the directory specified.
357 In the past, running Snort in daemon mode (-D) produced a file named
358 ``snort.alert.'' For consistency's sake, this has been changed. Running Snort in
359 both standard or daemon modes (-D) will produce a file named ``alert.''
361 Note the log file naming convention changed between 1.8 and 1.9. That funny
362 alphanumeric soup at the end of the new names is a UNIX timestamp. This helps
363 avoid file conflicts.
365 \subsection{Why does Snort complain about /var/log/snort?}
367 It requires this directory to log alerts to it. Try running the command:
368 \begin{verbatim}
369 mkdir -p /var/log/snort
370 \end{verbatim}
371 Make sure the logging directory is owned by the user Snort is running as.
373 \subsection{Where's a good place to physically put a Snort sensor?}
375 This is going to be heavily influenced by your organizations policy, and
376 what you want to detect. One way of looking at it is determining if you
377 want to place it inside or outside your firewall. Placing an IDS outside
378 of your firewall will allow you monitor all attacks directed at your
379 network, regardless of whether or not they are stopped at the firewall.
380 This almost certainly means that the IDS will pick up on more events
381 than an IDS inside the firewall, and hence more logs will be generated.
382 Place an IDS inside your firewall if you are only interested in monitoring
383 traffic that your firewall let pass. If resources permit, it may be best
384 to place one IDS outside and one IDS inside of your firewall. This way
385 you can watch for everything directed at your network, and anything that
386 made it's way in.
388 ADDENDA AD NAUSEUM
390 Note: So this one still gets a lot of traffic even though it's in the FAQ. Erek
391 Adams has noted this comprehensive and authoritative discussion of this
392 perpetual discussion item---mildly edited, also see faq question about switches
393 hubs and taps -dr
395 If your router/switch can do port mirroring, then just connecting a network IDS
396 to it would be fine. Or else a hub could be another option. Most network IDSes
397 can have a NIC that acts as a passive sniffer anyway.
399 As to where to place the sensor. I would go for both, one to monitor the
400 external, one for the internal. I work in a distributor for security products,
401 so over instrumentation is fun :) And in any case, if the traffic does not pass
402 by the Sensor it will not get monitored. So some people deploy IDS on their
403 internal segments too, I believe.
405 {\bf In ``front'' of the firewall(s):}
407 Pro: Higher state of alert you know what attacks you are facing.
409 Con: Wall to Wall of data, boring? If your firewall has NAT turned on, tracking
410 the sources originating from your internal network is difficult.
412 {\bf ``Behind'' the firewall(s):}
414 Pro: Only what gets through the firewall gets monitored? Less load on the IDS
415 analyst. You get to see what hosts are sending traffic to the internet.
417 Con: Less idea of the state of the environment, false sense of safety.
419 {\bf Where should IDS be placed relative to firewalls? Explore the pros and cons of
420 placing IDS inside or outside firewall. What are the drawbacks of each?}
422 \begin{itemize}
423 \item {\bf MARCUS RANUM from NFR Security:} "I'd put mine inside. Why should I care if
424 someone is attacking the outside of my firewall? I care only if they
425 succeed, which my IDS on the inside would ideally detect. Placing the IDS
426 on the outside is going to quickly lull the administrator into complacency.
427 I used to have a highly instrumented firewall that alerted me whenever
428 someone attacked it. Two weeks later I was deleting its alert messages
429 without reading them. Another important factor arguing for putting it
430 inside is that not all intrusions come from the outside or the firewall. An
431 IDS on the inside might detect new network links appearing, or attackers
432 that got in via another avenue such as a dial-in bank.''
434 \item {\bf CURRY from IBM:} ``The IDS should be placed where it will be able to see as
435 much of the network traffic you're concerned about as possible. For
436 example, if you're concerned about attacks from the Internet, it makes the
437 most sense to put the IDS outside the firewall. the most sense to put the
438 IDS outside the firewall. This gives it an ``unobstructed'' view of
439 everything that's coming in. If you put the IDS inside the firewall, then
440 you're not seeing all the traffic the bad guys are sending at you, and this
441 may impact your ability to detect intrusions.''
443 \item {\bf SUTTERFIELD from Wheel Group:} ``IDS ideally plays an important role both
444 inside and outside a firewall. Outside a firewall, IDS watches legitimate
445 traffic going to public machines such as e-mail and Web servers. More
446 importantly IDS outside a firewall will see traffic that would typically be
447 blocked by a firewall and would remain undetected by an internal system.
448 This is especially important in detecting network sweeping which can be a
449 first indication of attack. External systems will also give you the benefit
450 of monitoring those services that firewalls determine are legitimate.
451 Putting an IDS inside the firewall offers the added benefit of being able
452 to watch traffic internal to the protected network. This adds an important
453 element of protection against insider threats. The major drawback of IDS
454 inside a firewall is that it cannot see a good deal of important traffic
455 coming from untrusted networks and may fail to alert on obvious signals of
456 an impending attack.''
458 \item {\bf CHRIS KLAUS from ISS:} ``Outside the firewall is almost always a good
459 idea---it protects the DMZ devices from attack and dedicates an additional
460 processor to protecting the internal network. Just inside the firewall is
461 also useful-it detects attempts to exploit the tunnels that exist through
462 the firewall and provides an excellent source of data for how well your
463 firewall is working. Throughout your intranet may be the best place for IDS
464 deployment, however. Everyone agrees that attacks aren't the only things
465 we're worried about-there's internal mischief, fraud, espionage, theft, and
466 general network misuse. Intrusion detection systems are just as effective
467 inside the network as outside, especially if they're unobtrusive and easy
468 to deploy.''
470 \item {\bf GENE SPAFFORD:} ``The IDS must be inside any firewalls to be able to detect
471 insider abuse and certain kinds of attacks through the firewall. IDS
472 outside the firewall may be useful if you want to monitor attacks on the
473 firewall, and to sample traffic that the firewall doesn't let through.
474 However, a true IDS system is likely to be wasted there unless you have
475 some follow-through on what you see.''
477 \vspace{10pt}
478 Bottom Line:
480 {\bf DRAGOS RUIU:} ``Just pick a spot you're likely to look at the logs for. :-)''
482 \end{itemize}
483 \subsection{Libpcap complains about permissions problems, what's going on?}
485 You are not running Snort as root or your kernel is not configured
486 correctly.
488 \subsection{ I've got RedHat and ....}
490 Check your version of libpcap. If it's not $>=$ 0.5, you should update.
492 \subsection{Where do I get the latest version of libpcap? }
494 You can find the most current version at:
496 \htmladdnormallink{http://www.tcpdump.org}{http://www.tcpdump.org/}
498 You might also want to have a look at Phil Wood's patches to libpcap for Linux:
500 \htmladdnormallink{http://public.lanl.gov/cpw/}{http://public.lanl.gov/cpw/}
502 \subsection{Where do I get the latest version of Winpcap?}
504 \htmladdnormallink{http://winpcap.polito.it/}{http://winpcap.polito.it/}
506 \subsection{What version of Winpcap do I need?\label{winpcap}}
508 It depends. If you only have one processor, you can use the most current
509 version (3.x). If you have a SMP box, you'll have to use either an older
510 version ($<$ 2.3) or the 3.x version plus a patch from \htmladdnormallink{http://www.ntop.org/winpcap.html}{http://www.ntop.org/winpcap.html}.
512 \subsection{Why does building Snort complain about missing references? }
514 You must configure libpcap with the --install-incl option. (On Red Hat,
515 install the libpcap-devel rpm.)
517 \subsection{Why does building snort fail with errors about yylex and lex\_init? }
519 You need the lex and yacc tools or their gnu equivalents flex and bison
520 installed.
522 \subsection{I want to build a Snort box. Will this $<$Insert list of hardware$>$ handle $<$this much$>$ traffic? }
524 That depends. Lower the number of rules is a standard performance increase.
525 Disable rules that you don't need or care about. There have been many
526 discussions on 'tweaking performance' with lots of 'I handle XX mb with a \_\_\_
527 machine setup.' being said. Look at some of the discussions on the snort-users
528 mailing lists.
530 Here is an oft quoted bit on the subject from Marty:
532 ``Hardware/OS recommendations''
534 Ok, here are the guidelines and some parameters. Intrusion detection is turning
535 into one of the most high performance production computing fields that is in
536 wide deployment today. If you think about the requirements of a NIDS sensor and
537 the constraints that they are required to operate within, you'll probably start
538 to realize that it's not too hard to find the performance wall with a NIDS
539 these days.
541 The things a NIDS needs are:
542 \begin{enumerate}
543 \item MIPS (Fast CPU)
544 \item RAM (More is *always* better)
545 \item I/O (Wide, fast busses and high performance NIC)
546 \item AODS (Acres Of Disk Space)
547 \end{enumerate}
549 A NIDS also needs to be pretty quick internally at doing its job. Snort's seen
550 better days in that regard (when 1.5 came out the architecture was a lot
551 cleaner) but it's still considered to be one of the performance leaders
552 available.
554 As for OS selection, use what you like. When we implement Data Acquisition
555 Plugin's in Snort 2.0 this may become more of a factor, but for now I'm hearing
556 about a lot of people seeing alot of success using Snort on Solaris, Linux,
557 *BSD and Windows 2000. Personally, I develop Snort on FreeBSD and Sourcefire
558 uses OpenBSD for our sensor appliance OS, but I've been hearing some good
559 things about the RedHat Turbo Packet interface (which would require mods for
560 Snort to use, not to mention my general objection to RedHat's breaking stuff
561 all the time). (ed note: take a drink, see FAQ 7.2 -dr)
563 \subsection{What are CIDR netmasks? }
565 (Excerpt from url: \htmladdnormallink{http://public.pacbell.net/dedicated/cidr.html}{http://public.pacbell.net/dedicated/cidr.html})
567 CIDR is a new addressing scheme for the Internet which allows for more i
568 efficient allocation of IP addresses than the old Class A, B, and C address
569 scheme.
571 \begin{center}
572 \begin{tabular}{llr}
573 {\bf CIDR Block} & {\bf Equivalent Class C} & {\bf Addresses}\\
574 /27 & 1/8th of a Class C & 32 hosts \\
575 /26 & 1/4th of a Class C & 64 hosts\\
576 /25 & 1/2 of a Class C & 128 hosts\\
577 /24 & 1 Class C & 256 hosts\\
578 /23 & 2 Class C & 512 hosts\\
579 /22 & 4 Class C & 1,024 hosts\\
580 /21 & 8 Class C & 2,048 hosts\\
581 /20 & 16 Class C & 4,096 hosts\\
582 /19 & 32 Class C & 8,192 hosts\\
583 /18 & 64 Class C & 16,384 hosts\\
584 /17 & 128 Class C & 32,768 hosts\\
585 /16 & 256 Class C & 65,536 hosts \\
586 /15 & 512 Class C & 131,072 hosts\\
587 /14 & 1,024 Class C & 262,144 hosts\\
588 /13 & 2,048 Class C & 524,288 hosts\\
589 \end{tabular}
590 \end{center}
592 For more detailed technical information on CIDR, check out the following RFCs:
595 \begin{itemize}
596 \item RFC 1517: Applicability Statement for the Implementation of CIDR
597 \item RFC 1518: An Architecture for IP Address Allocation with CIDR
598 \item RFC 1519: CIDR: An Address Assignment and Aggregation Strategy
599 \item RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment
600 \end{itemize}
602 RFCs are available at
603 \htmladdnormallink{http://www.rfc-editor.org/rfcsearch.html}{http://www.rfc-editor.org/rfcsearch.html}
605 \subsection{What is the use of the ``-r'' switch to read tcpdump files? }
607 Used in conjunction with a Snort rules file, the tcpdump data can be
608 analyzed for hostile content, port scans, or anything else Snort can be
609 used to detect. Snort can also display the packets in a decoded format,
610 which many people find is easier to read than native tcpdump output.
613 \section{Configuring Snort}
615 \subsection{How do I setup snort on a `stealth' interface? }\label{stealth}
617 In *BSD and Linux:
618 \begin{verbatim}ifconfig eth1 up\end{verbatim}
620 Solaris:
622 \begin{verbatim}ifconfig eth1 plumb
623 ifconfig eth1 up\end{verbatim}
625 For NT/W2K/XP users, try the following:
627 NOTE: You are at your own risk if you follow these instructions. Editing
628 your registry is DANGEROUS and should be done with extreme caution. Follow
629 these steps at your OWN risk.
631 \begin{enumerate}
632 \item Get your device's hex value. ('snort -W' works for this)
633 \item open Regedt32
634 \item Navigate to: HKEY\_LOCAL\_MACHINE$\backslash$SYSTEM$\backslash$CurrentControlSet$\backslash$Services$\backslash$Tcpip$\backslash$Parameters$\backslash$\linebreak Interfaces$\backslash$\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX\}
635 \item Select the network card you wish to setup as the monitoring interface (this will be the \{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX\} value).
636 \item Set IPAddress:REG\_MULTI\_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)
637 \item Set SubnetMask:REG\_MULTI\_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)
638 \item Set DefaultGateway:REG\_MULTI\_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)
639 \item Close the Registry Editor, your changes will be saved automatically.
640 \item In a command prompt, run 'ipconfig' to verify the interface does not have an IP bound to it.
641 \end{enumerate}
643 If you do not recieve an IP address listing from the interface you
644 modified, you are good to go. To run snort with the specified interface,
645 use the -i flag such as 'snort -v -d -p -i1'
647 \subsection{How do I setup a receive-only ethernet cable?}
649 Use an ethernet tap, or build your own 'receive-only' ethernet cable.
650 Anyway, here is the cable I use:
652 \begin{verbatim}
653 LAN Sniffer
654 1 -----\ /-- 1
655 2 ---\ | \-- 2
656 3 ---+-*------ 3
657 4 - | - 4
658 5 - | - 5
659 6 ---*-------- 6
660 7 - - 7
661 8 - - 8
662 \end{verbatim}
664 Basically, 1 and 2 on the sniffer side are connected, 3 and 6
665 straight through to the LAN. 1 and 2 on the LAN side connect to 3 and
666 6 respectively. This fakes a link on both ends but only allows
667 traffic from the LAN to the sniffer. It also causes the 'incoming'
668 traffic to be sent back to the LAN, so this cable only works well on
669 a hub. You can use it on a switch but you will get ...err...
670 interesting results. Since the switch receives the packets back in on
671 the port it sent them out, the MAC table gets confused and after a
672 short while devices start to drop off the switch. Works like a charm
673 on a hub though.
675 Another method which uses a capacitor and should work on 100mbs links:
677 \htmladdnormallink{http://www.geocities.com/samngms/sniffing\_cable}{http://www.geocities.com/samngms/sniffing_cable}
679 And another:
681 The UTP Y-Cable specified by Joe Lyman:
683 A less noisy option: it involves a couple of cat 5 cables and a single speed
684 hub. The idea is to use the rcv cables for the wire going to the sniffer box
685 and use the xmit cables from another hub port. This will give you a link light
686 and allow your sniffer to rcv only. Cannot xmit because the xmit cables are not
687 connected. This has been successfully used on netgear single speed hubs. It
688 wont work on dual speed hubs due to the negotiation of speed.
690 Pin outs. They are reversed in the picture in order to prevent lines from
691 crossing, and I only included the pins used.
693 \begin{verbatim}
694 * []HUB PORT 1 HUB PORT 2
696 ----- -----
698 x x r r r r x x
700 6 3 2 1 1 2 3 6
702 | | | | | |
704 | | | ----------- |
706 | | -------------
716 6 3 2 1
718 r r x x
720 ----
722 SNIFFER
724 x = xmit
726 r = rcv
727 \end{verbatim}
728 You could make it a single cable by adding a battery to simulate the voltage
729 from the xmit cables on the nic, but batteries die.
731 It's not recommended to cut the transmit side, shunt it to ground (pin 2). Some
732 OS's will disable the interface if PIN 1 does not indicate a completed circuit.
734 \subsection{What are HOME\_NET and EXTERNAL\_NET?}
736 HOME\_NET and EXTERNAL\_NET are standard variable names that all of the Snort.org
737 rules use. HOME\_NET refers to the network(s) that you want to protect, where
738 EXTERNAL\_NET is the network(s) that you think attacks would come from.
740 \subsection{My network spans multiple subnets. How do I define HOME\_NET?}
742 Snort 1.7 supports IP lists. You can assign a number of addresses to
743 a single variable. For example:
745 \begin{verbatim}var HOME_NET [10.1.1.0/24,192.168.1.0/24]\end{verbatim}
747 NOTE: Not all preprocessors support IP lists at this time. Unless
748 otherwise stated, assume that any preprocessor using an IP list variable
749 will use the first value as the HOME\_NET. The portscan preprocessor
750 is an example. To catch all detectable portscans, pass 0.0.0.0/0 in
751 as the first parameter.
753 \begin{verbatim}preprocessor portscan: 0.0.0.0/0 5 3 portscan.log\end{verbatim}
755 Use the portscan-ignorehosts preprocessor to fine tune and ignore
756 traffic from noisy, trusted machines.
758 \subsection{How do I set EXTERNAL\_NET?}
760 Many people set EXTERNAL\_NET to ``any''.
761 \begin{verbatim}
762 var EXTERNAL_NET any
763 \end{verbatim}
764 By setting it to ``any'' Snort will alert you on any traffic matching a rule
765 coming into or leaving your network.
767 To cut down on the work that Snort has to do, many people set it to ``not
768 HOME\_NET.''
769 \begin{verbatim}
770 var EXTERNAL_NET !$HOME_NET
771 \end{verbatim}
772 This tells Snort to define EXTERNAL\_NET as everything except HOME\_NET. For most
773 people this is the best thing to set it to.
775 \subsection{How can I run Snort on multiple interfaces simultaneously?}
777 LINUX: If you aren't running snort on linux 2.1.x/2.2.x kernel (with LPF
778 available) the only way is to run multiple instances of snort, one instance per
779 interface (with the -i option specifying the interface). However for linux
780 2.1.x/2.2.x and higher you can use libpcap library with S. Krahmer's patch
781 which allows you to specify 'any' as interface name. In this case snort will be
782 able to process traffic coming to all interfaces.
784 *BSD: Use the ``bridge'' interface to combine your nics into a logical
785 interface (bridge0).
787 \subsection{My IP address is assigned dynamically to my interface, can I use Snort with it?}
789 Yes. With Snort 1.7 and later, $<$interface$>$\_ADDRESS variable is available.
790 The value of this variable will be always set to IP address/Netmask of the
791 interface which you run snort at. if interface goes down and up again (and
792 an IP address is reassigned) you will have to restart snort. For earlier
793 versions of snort numerous scripts to achieve the same result are
794 available.
797 \subsection{I have one network card and two aliases, how can I force Snort to ``listen'' on both addresses?}
799 If you're using at least version 1.7, you can specify an IP list like
800 this:
802 \begin{verbatim}var HOME_NET [ 192.168.10.0/24, 10.1.1.1/16 ]\end{verbatim}
804 If you're using something older (version 1.6.3-patch2 or whatever) you can
805 re-specify the HOME\_NET variable multiple times like this (for example):
807 \begin{verbatim}
808 var HOME_NET 10.1.1.0/24
809 include misc.rules
810 var HOME_NET 192.168.1.0/24
811 include misc.rules
812 \end{verbatim}
814 \subsection{How do I ignore traffic coming from a particular host or hosts?}
816 There are two basic ways to ignore traffic from a host:
817 \begin{itemize}
818 \item Pass Rules
819 \item BPF Filters
820 \end{itemize}
821 Details:
822 \begin{enumerate}
823 \item Pass Rules:
824 \begin{itemize}
825 \item Advantages:
826 \begin{itemize}
827 \item Gives you rule based control over the packets.
828 \item Puts all your changes into 'one place'-snort.conf.
829 \end{itemize}
830 \item Disadvantages:
831 \begin{itemize}
832 \item Reverses the Rule order, can cause some headaches in tracking down
833 problems.
834 \item One poorly written pass rule can 'blind' your whole network.
835 \item The more specific the pass rule is, the more CPU snort needs to process
836 it which may be important on loaded nets.
837 \end{itemize}
838 \item Example:
840 For example to ignore ALL ICMP traffic from host <foo> using a pass
841 rule:
842 \begin{verbatim}
843 pass icmp <foo> any -> $HOME_NET any
844 \end{verbatim}
845 \end{itemize}
846 \item BPF Filters:
847 \begin{itemize}
848 \item Advantages:
849 \begin{itemize}
850 \item Drops the packet at the BPF interface, which saves on processing.
851 \item Speeds up Snort since it 'never sees' those packets.
852 \end{itemize}
853 \item Disadvantages:
854 \begin{itemize}
855 \item Poorly constructed filters can 'blind-side' you.
856 \end{itemize}
857 \item Example:
858 \begin{itemize}
859 \item To ignore all traffic from 192.168.0.1:
860 \begin{verbatim}
861 snort <commandline options> not host 192.168.0.1
862 \end{verbatim}
863 \item To ignore all ICMP ECHO-REQUESTS (pings) and ICMP-ECHO REPLY's (ping
864 reply) from host $<$foo$>$:
865 \begin{verbatim}
866 snort <options> ``not ( (icmp[0] = 8 or icmp[0] = 0) and host <foo> )''
867 \end{verbatim}
868 \end{itemize}
869 \end{itemize}
870 \end{enumerate}
872 \subsection{How do I get Snort to log the packet payload as well as the header?}
874 It depends on how your Snort configuration logs. If it logs in binary format,
875 you'll have to process the binary log in order to get cleartext. You also might
876 have ``-A $<$foo$>$'' on the command line. Command line options always take
877 override the .conf file.
879 \subsection{Why are there no subdirectories under /var/log/snort for IP addresses?}
881 It depends on how your snort configuration logs. If it logs in binary
882 format, you'll have to process the binary log in order to get cleartext.
884 \subsection{How do you get Snort to ignore some traffic?}
886 Snort can be made to ignore traffic in a number of different ways:
887 \begin{enumerate}
888 \item Specify bpf filters on the command line the tcpdump man page
889 has a description of bpf filters.
890 \item Use a pass rule
891 \item The portscan preprocessor has it's own special exclusion list
892 with the portscan-ignorehosts.rules file directive
893 \end{enumerate}
895 \subsection{Why does the portscan plugin log ``stealth'' packets even though the host is in the portscan-ignorehosts list? }
897 These types of tcp packets are inherently suspicious, no matter where
898 they are coming from. The portscan detector was built with the assumption
899 that {\em stealth} packets should be reported, even from hosts which are not
900 monitored for portscanning. An option to ignore ``stealth'' packets may be
901 added in the future.
903 \subsection{What the heck is a ``Stealth scan''?}
905 A Stealth scan can refer to more than one type of scan.
906 \begin{itemize}
907 \item {\bf Half-Open or SYN scan:} Instead of completing the full TCP
908 three-way-handshake a full connection is not made. A SYN packet is sent to
909 the system and if a SYN/ACK packet is received it is assumed that the port
910 on the system is active. In that case a RST/ACK will be sent which will
911 determined the listening state the system is in. If a RST/ACK packet is
912 received, it is assumed that the port on the system is not active.
913 \item {\bf FIN scan:} According to RFC 793 a system should send back an RST for all TCP
914 ports closed when they receive a FIN packet for a specific port.
915 \item {\bf XMAS tree scan:} According to RFC 793 a system should send back an RST for
916 all TCP ports closed when they receive a FIN/URG/PUSH packet for a specific
917 port.
918 \item {\bf NULL scan:} According to RFC 793 a system should send back an RST for all TCP
919 ports closed when they receive a packet without any specified IP flags for
920 a specific port.
921 \item {\bf Slow scan:} Any of the above scans could be used as a slow scan. A slow scan
922 is when the attacker sends packets at a {\bf very} slow rate. Sometimes these
923 scans can be conducted over hours, days, or weeks. The idea is since they
924 are so slow, the victim's security measures won't ``notice'' the scan.
925 \end{itemize}
927 \subsection{What the heck is a SYNFIN scan?}
929 SYNFIN scans got their name because there are both the SYN and FIN flags set.
931 \subsection{Which takes precedence, commandline or rule file ?}
933 The command line always gets precedence over the rules file. If people
934 want to try stuff out quickly without having to manually edit the rules
935 file, they should be able to override many things from the command
936 line.
938 \subsection{How does rule ordering work?}
940 {\bf For $=>$ 2.0:}
942 Please see the documents on v2.0 at:
943 \htmladdnormallink{http://www.snort.org/docs/development-papers/}{http://www.snort.org/docs/development-papers/}.
945 {\bf For $<=$ 1.9.X:}
947 Marty has answered this many times on the snort-users mailing list. Here is
948 an excerpt from a post on Thu, 22 Feb 2001 00:31:53 -0500, titled {\em ``Re:
949 [Snort-users] order of evaluation of rules.''}
951 Currently, the data structures that store Snort rule data are the
952 RuleTreeNodes (RTN) and the OptTreeNodes (OTN). These data structs are
953 stored in a two dimensinal linked list structure with the RTNs forming
954 the top row of the ``Array'' and the OTNs forming the columns under the
955 RTNs. Here's an ASCII illustration from the infamous ``lisapaper'':
957 \begin{verbatim}
958 RTN RTN RTN
959 -------------- -------------- -----
960 | Chain Header | | Chain Header | | Chai
961 | | | | |
962 | Src IP | | Src IP | | Src
963 | Dst IP |----->| Dst IP |----->| Dst .....
964 | Src Port | | Src Port | | Src
965 | Dst Port | | Dst Port | | Dst
966 | | | | |
967 -------------- -------------- -----
971 OTN \|/ OTN \|/
972 -------V------ --------V-------
973 | Chain Option | | Chain Option |
974 | | | : |
975 | Content | :
976 | TCP Flags | :
977 | ICMP Data |
978 | Payload Size |
979 | etc. |
981 ---------------
985 OTN \|/
986 -------V------
987 | Chain Option |
989 | Content |
990 | TCP Flags |
991 | ICMP data |
992 | Payload Size |
993 | etc. |
995 --------------
999 \end{verbatim}
1001 Rules with similar rule headers (i.e. all the CGI rules, the old stealth
1002 port scan detection rules, most of the rules that focus on any single
1003 service, etc) are grouped under a single RTN for the sake of efficiency
1004 and the applicable OTNs are hung below them. For instance, if you have
1005 three rules like this:
1007 \begin{verbatim}
1008 alert tcp any any -> $HOME 80 (content: "foo"; msg: "foo";)
1009 alert tcp any any -> $HOME 80 (content: "bar"; msg: "bar";)
1010 alert tcp any any -> $HOME 80 (content: "baz"; msg: "baz";)
1011 \end{verbatim}
1013 They all get grouped under the same RTN and the OTNs are ``hung'' beneath
1014 them like this:
1016 \begin{verbatim}
1019 --------------------
1020 | SIP: any |
1021 | SP: any |
1022 | DIP: $HOME |
1023 | DP: 80 |
1024 --------------------
1027 OTN \|/
1028 ---------v----------
1029 | content: foo |
1030 | msg: foo |
1031 ---------------------
1034 OTN \|/
1035 ---------v----------
1036 | content: bar |
1037 | msg: bar |
1038 ---------------------
1041 OTN \|/
1042 ---------v----------
1043 | content: baz |
1044 | msg: baz |
1045 ---------------------
1046 \end{verbatim}
1048 This is an efficient way to do things because we only need to check the
1049 data in the RTN once with this method. There is actually another
1050 dimension to this array: the function pointer list. Each node in the
1051 ``array'' has a linked list of function pointers attached to it. The
1052 functions in this list are the tests that need to be done to determine
1053 whether the data in the current packet matches the current rule node's
1054 information. Having this function pointer list gives us great
1055 efficiency and flexibility: we don't need to perform tests for things
1056 the current rule doesn't contain (e.g., ``any'' ports/IPs, packet content
1057 on non-content rules, etc). It also allows us to analyze the packet
1058 with any function without having to make major modifications to the
1059 whole program (which was the case in versions prior to version 1.5).
1061 There are a couple of implications of this architecture. For the sake
1062 of this discussion on rules ordering, the one we're interested in is
1063 that rule order is tricky to figure out. For instance:
1065 \begin{verbatim}
1066 alert tcp any any -> $HOME 80 (content: "foo"; msg: "foo";)
1067 alert tcp any any -> $HOME 1:1024 (flags: S; msg: "example";)
1068 alert tcp any any -> $HOME 80 (flags: S; msg: "Port 80 SYN!";)
1069 alert tcp any any -> $HOME 80 (content: "baz"; msg: "baz";)
1070 \end{verbatim}
1072 gets built like this:
1074 \begin{verbatim}
1075 RTN RTN
1076 -------------------- --------------------
1077 | SIP: any | | SIP: any |
1078 | SP: any |-------->| SP: any |
1079 | DIP: \$HOME | | DIP: \$HOME |
1080 | DP: 80 | | DP: 1-1024 |
1081 -------------------- --------------------
1084 OTN \|/ \|/
1085 ---------v---------- ---------v----------
1086 | content: foo | | flags: S |
1087 | msg: foo | | msg: example |
1088 -------------------- --------------------
1091 OTN \|/
1092 ---------v----------
1093 | flags: S |
1094 | msg: Port 80 SYN! |
1095 --------------------
1098 OTN \|/
1099 ---------v----------
1100 | content: baz |
1101 | msg: baz |
1102 --------------------
1103 \end{verbatim}
1105 Note that all three of the port 80 rules will be checked before the
1106 ``1:1024'' rule due to the order in which the applicable RTN has been
1107 created. This is because the rules parser builds the first chain header
1108 for port 80 traffic and sticks it on the rules list, then on the next
1109 rule it sees that a new chain header is required, so it gets built and
1110 put in place. In this case you would intuitively expect to get the
1111 ``example'' message and never see the ``Port 80 SYN!,'' but the opposite is
1112 true.
1114 \subsection{How do I configure stream4?}
1115 \label{stream4}
1117 Stream4 is an entirely new preprocessor that preforms two functions:
1119 \begin{itemize}
1120 \item Stateful inspection of TCP sessions
1121 \item TCP stream reassembly
1122 \end{itemize}
1124 Marty implemented stream4 out of the desire to have more robust stream reassembly capabilities and the desire to defeat the latest ``stateless attacks'' that have been coming out against Snort (c.f. stick and snot). Stream4 is written with the intent to let Snort be able to handle performing stream reassembly for ``enterprise class'' users, people who need to track and reassemble more than 256 streams simultaneously. Marty optimized the code fairly extensively to be robust, stable, and fast. The testing and calculations I've performed lead me to be fairly confident that stream4 can provide full stream reassembly for several thousand simultaneous connections and stateful inspection for upwards of 64,000 simultaneous sessions.
1126 Stream4 is a large and complex piece of code (almost 2000 lines) and there are a lot of options associated with its runtime configuration, so I'll go over them here.
1128 \begin{verbatim}
1129 preprocessor stream4: [noinspect], [keepstats], [timeout <seconds>], [memcap]
1130 \end{verbatim}
1132 stream4\_reassemble defaults:
1133 \begin{verbatim}
1134 Reassemble client: ACTIVE
1135 Reassemble server: INACTIVE
1136 Reassemble ports: 21 23 25 53 80 143 110 111 513
1137 Reassembly alerts: ACTIVE
1138 \end{verbatim}
1141 \subsection{Where does one obtain new/modifed rules? How do you merge them in?}
1143 New rules can be downloaded via CVS \myref{cvs} or, alternatively, may be
1144 found at www.snort.org. There is a mailing list dedicated to Snort rules,
1145 called snort-sigs hosted at Sourceforge.
1147 There are some scripts/programs to help you with rule management:
1148 \begin{itemize}
1149 \item oinkmaster: A simple Perl script to update the ruleset for you.
1151 \htmladdnormallink{http://www.algonet.se/~nitzer/oinkmaster/}{http://www.algonet.se/~nitzer/oinkmaster/}
1153 \item IDS Policy Manager: A win32 application that updates the ruleset
1154 using a GUI, then uploads your rulesets via scp.
1156 \htmladdnormallink{http://www.activeworx.com/idspm}{http://www.activeworx.com/idspm}
1158 \item snortpp: a program to merge multiple files into one master file sorted by
1159 SID.
1161 \htmladdnormallink{http://dragos.com/snortpp.tgz}{http://dragos.com/snortpp.tgz}
1162 \end{itemize}
1164 There is also this script that might be useful:
1165 \begin{verbatim}
1166 * []#!/bin/sh
1167 ###########################################################################
1168 ####
1170 # Das Skript zum Herunterladen und installieren neuer IDS-Signaturen.
1172 ###########################################################################
1173 ####
1174 MAILTO="admin@mydomain.de"
1175 MACHINE="machine1"
1176 #set -x
1177 SIGS_URL1="http://www.snort.org/dl/signatures/snortrules-stable.tar.gz"
1178 MD5_URL1="http://www.snort.org/dl/signatures/snortrules-stable.tar.gz.md5"
1179 WGET="/usr/bin/wget"
1180 #WGET_PARAMS="-N"
1181 WGET_PARAMS="-t 3 -T 5 -N -a /etc/snort/snort.log -P /etc/snort"
1182 # Wget parameters:
1184 # -t : Retries (here 3)
1185 # -N : Get the file only if newer
1186 # -a : Append the log messages to the specified file
1187 # -P : Save the file to the specified directory
1188 # -T : Timeout
1189 ECHO="/bin/echo"
1190 TAR="/bin/tar"
1191 KILL="/bin/kill"
1192 PIDOF="/sbin/pidof"
1193 SNORT="/usr/local/bin/snort"
1194 SNORTUSER="snort"
1195 SNORTGROUP="snort"
1196 KILLSIG="SIGUSR1"
1197 SERVICE="/sbin/service"
1199 # Where is the Snort configuration dir:
1200 RULESPATH="/etc/snort/snortrules"
1201 SNORTCFGPATH="/etc/snort"
1202 MD5SUM="/usr/bin/md5sum"
1203 MD5SUM_PARAMS=""
1205 # The list of sensor interfacec divided by blanks
1206 IFACES="eth0"
1208 ###########################################################################
1209 ####
1210 # F U N C T I O N S
1212 ###########################################################################
1213 ####
1214 ###########################################################################
1215 ####
1216 # Die Funktion, die Snort fuer alle def. Interfaces auf dem System startet
1220 # Um sie zu erweitern muss man zwei Dinge tun:
1222 # 1. Die Parameterliste von Interfaces erweitern
1224 # 2. Das Konfigurationsfile unter /etc/snort/snort.conf_ethX anlegen #
1227 ###########################################################################
1228 ####
1229 restartsnort() {
1231 # Restarting Snort for all interfaces
1232 for i in $IFACES; do
1233 "$ECHO" "Setting up Snort for interface "$i""
1234 $ECHO "Restarting Snort..."
1235 #/usr/bin/killall snort
1236 if [ -f /var/run/snort_"$i".pid ]
1237 then
1238 PID=$("$PIDOF" "$SNORT")
1239 if [ -z "$PID" ]
1240 then
1241 "$SERVICE" snort restart
1242 else
1243 #`cat /var/run/snort_"$i".pid`
1244 "$ECHO" "Restarting Snort running with PID "$PID" and reloading the rules..."
1245 "$KILL" -s "$KILLSIG" "$PID"
1247 else
1248 "$ECHO" "No PID file for interface "$i" found under /var/
1249 run"
1251 "$ECHO" "Starting Snort"
1252 "$SNORT" -a -b -c "$SNORTCFGPATH""/snort.conf_""$i" -I -D -v
1253 -i $i -u "$SNORTUSER" -g "$SNORTGROUP"
1254 PID=`cat /var/run/snort_"$i".pid`
1255 "$ECHO" "Snort running now with PID "$PID""
1256 done
1258 ###########################################################################
1259 ####
1260 # Die Funktion zum ueberpruefen, ob und wie Snort auf dem System laeuft
1262 ###########################################################################
1263 ####
1264 checksnort() {
1265 SNORTS=$("$PIDOF" "$SNORT" | wc -w | awk '{print $1}')
1266 SNORT_PIDS=$(/usr/bin/find /var/run -name snort\_eth[0-9]\.pid -ls |
1267 wc -l | awk '{print $1}')
1268 "$ECHO" "Snort instances counted: $SNORTS"
1269 "$ECHO" "Snort PID files found: $SNORT_PIDS"
1271 # 1. Fall: Snort laeuft nicht oder PID-File nicht da:
1272 if [ "$SNORTS" = "0" -o "$SNORT_PIDS" = "0" ]
1273 then
1274 "$ECHO" "Snort seems to be down or no PID file there..."
1275 "$ECHO" "Restarting Snort for all Interfaces..."
1276 "$SERVICE" snort restart
1278 # 2. Fall: Anzahl der Instanzen ungleich der Anzahl der PID-Files
1279 if [ "$SNORTS" -gt "$SNORT_PIDS" ]
1280 then
1281 "$ECHO" "More Snort instances than found PID files..."
1282 "$ECHO" "Something is wrong outthere..."
1283 "$ECHO" "Stopping all Snort processes..."
1284 # /usr/bin/killall -9 snort
1285 "$SERVICE" snort stop
1286 "$ECHO" "Hold on... Restarting Snort now..."
1287 "$SERVICE" snort restart
1290 # 3. Fall: Anzahl der Instanzen stimmt mit der Anzahl der PID-files ueberein
1292 ###########################################################################
1293 ####
1294 ###########################################################################
1295 ####
1296 getrules() {
1297 # Get the rules, since we know that they are newer...
1298 $WGET $WGET_PARAMS $SIGS_URL1
1299 $WGET $WGET_PARAMS $MD5_URL1
1300 "$ECHO" "Readout the checksum..."
1301 # MD5-Summe auslesen
1302 if [ -f /etc/snort/snortrules-stable.tar.gz.md5 ]
1303 then
1304 MD5SUM1=`grep MD5 \
1305 /etc/snort/snortrules-stable.tar.gz.md5|awk
1306 '{print $4}'`
1307 else
1308 "$ECHO" "Error! No MD5-file found"
1309 exit 1
1311 "$ECHO" "Generating our own checksum..."
1312 # MD5-Summe bilden
1313 if [ -f /etc/snort/snortrules-stable.tar.gz ]
1314 then
1315 MD5SUM2=`md5sum /etc/snort/snortrules-stable.tar.gz|awk '{print $1}'`
1316 else
1317 "$ECHO" "Error! No rules file found"
1318 exit 1
1320 if [ "$MD5SUM1" = "$MD5SUM2" ]
1321 then
1322 "$ECHO" "The MD5-Checksum fits!"
1323 "$ECHO" "$MD5SUM1"
1324 "$ECHO" "$MD5SUM2"
1325 "$ECHO" "$MD5SUM1" >> /etc/snort/snort.log
1326 "$ECHO" "$MD5SUM2" >> /etc/snort/snort.log
1327 "$ECHO" "Proceeding..."
1328 # /bin/sleep 1
1329 else
1330 "$ECHO" "Error! Wrong checksum! Aborting!"
1331 "$ECHO" "Install rules manually!"
1332 "$ECHO" "$MD5SUM1" >> /etc/snort/snort.log
1333 "$ECHO" "$MD5SUM2" >> /etc/snort/snort.log
1334 exit 1
1336 # Extract the new rules
1337 if [ -f "/etc/snort/snortrules-stable.tar.gz" ]
1338 then
1339 "$ECHO" "Extracting Snort rules..."
1340 "$TAR" -xzvf /etc/snort/snortrules-stable.tar.gz -C /etc/snort
1341 else
1342 "$ECHO" "Lost the file! Something is wrong!"
1343 "$ECHO" "Aborting!!"
1344 exit 1
1346 # Deleting old rules
1347 # Existiert das Verzeichnis ueberhaupt?
1348 if [ -d "$RULESPATH" ]
1349 then
1350 # /bin/rm "$RULESPATH"/*.rules
1351 /bin/mv -f /etc/snort/rules/*.rules "$RULESPATH"
1352 /bin/cp -f /etc/snort/rules/classification.config "$SNORTCFGPATH"
1353 else
1354 "$ECHO" "Missing rules-directory!"
1355 "$ECHO" "Aborting!"
1356 exit 1
1359 # Cleaning up...
1360 /bin/rm -rf /etc/snort/rules
1361 # Give everything to root
1362 /bin/chown root:root ${RULESPATH}/*
1364 ###########################################################################
1365 ####
1366 # M A I N
1368 ###########################################################################
1369 ####
1370 # Error handling first
1371 FCHK=$(/usr/bin/wget -spider -N -t 3 -T 5 "$SIGS_URL1" -P /etc/snort 2>&1)
1372 ERR_MSG=$("$ECHO" "$FCHK" | egrep -oi "failed error")
1373 # Log the error message explicitly
1374 "$ECHO" "$FCHK" >> /etc/snort/snort.log
1375 # If there is a word "failed" or "error" we break..
1376 if [ "$("$ECHO" "$FCHK"| grep -i "failed")" ] || \
1377 [ "$("$ECHO" "$FCHK"| grep -i "error")" ]
1378 then
1379 "$ECHO" "Error getting the files. The server seems to be not available."
1380 "$ECHO" "Error message:"
1381 "$ECHO" "$FCHK"
1382 "$ECHO" "Aborting!"
1383 exit 0
1386 "$ECHO" "Checking/getting files..."
1387 # First extract the wget message
1388 FCHK=$(/usr/bin/wget -spider -N -t 3 -T 5 "$SIGS_URL1" \
1389 -P /etc/snort 2>&1 | grep "not retrieving")
1390 /bin/date >> /etc/snort/snort.log
1391 "$ECHO" "Wget-output:"
1392 "$ECHO" $FCHK
1393 # Logging what we've done and when
1394 "$ECHO" "$FCHK" >> /etc/snort/snort.log
1395 if [ -z "$FCHK" ]
1396 then
1397 "$ECHO" "The files on the server seem to be newer."
1398 "$ECHO" "We will get them now..."
1399 getrules
1400 # Reload rules
1401 "$SERVICE" snort reload
1402 # restartsnort
1403 else
1405 "$ECHO" "The signature files on the server are older or not newer."
1406 "$ECHO" "Doing nothing for now..."
1407 "$ECHO" "Checking if Snort is running...."
1408 checksnort
1409 exit 0
1411 # Send Email
1412 "$ECHO" -e "`ls -lA "$RULESPATH"`\n\nSnort running with PID $("$PIDOF"\
1413 "$SNORT")" | mail -s "Reloaded Snort signatures on $MACHINE"\
1414 "$MAILTO"
1415 ###########################################################################
1416 ####
1417 ###########################################################################
1418 ####
1419 exit 0
1420 #EOF
1421 \end{verbatim}
1423 \subsection{How do I use a remote syslog machine?}
1425 Add the syslog switch, -s, and put this statement syslog.conf:
1426 \begin{verbatim}
1427 auth.alert @managmentserverIP
1428 \end{verbatim}
1430 Look at your snort.conf file for more info on the facility and Priority
1431 settings.
1433 Make sure you have syslogd on the management server configured to allow syslog over
1434 UDP. Under RedHat, you can do this by editing /etc/sysconfig/syslog and adding
1435 the following line:
1436 \begin{verbatim}
1437 SYSLOGD_OPTIONS="-r -m 0"
1438 \end{verbatim}
1439 This will start syslogd with the mark interval set to 0 (turning it off) and
1440 set it to receive network connections.
1442 Then restart syslog. ``man syslogd'' for more info. You might also want to
1443 investigate syslog-ng\linebreak (\htmladdnormallink{http://www.balabit.hu/en/downloads/syslog-ng/}{http://www.balabit.hu/en/downloads/syslog-ng/}).
1445 Example invocation of snort:
1446 \begin{verbatim}
1447 /usr/local/bin/snort -c /etc/snort/snort.conf -I -A full -s 192.168.0.2:514
1448 -i rl0
1449 \end{verbatim}
1450 Note for Win32 users:
1452 Frank Knobbe wrote a patch for Snort to allow you to use `-s $<$host$>$' on the
1453 command line under Windows without nullifying the snort.conf. In other words,
1454 Snort still uses all settings from snort.conf but in addition uses the host
1455 from `-s' to send syslog alerts to. You can find the patch at:
1457 \htmladdnormallink{http://www.snort.org/dl/contrib/patches/win32syslog/}{http://www.snort.org/dl/contrib/patches/win32syslog/}
1459 \subsection{How do I get Snort and ACID working?}
1461 Acid has been unmaintained for quite some time. Use BASE instead (see below).
1463 \subsection{How do I build this BASE thing?}
1465 Read carefully through all the docs for each package. Getting BASE to work is a
1466 lot of work, since it depends on many packages. You need a working Apache, a
1467 working PHP, a working GD (and the many libraries GD depends on) and the ADODB
1468 package. This is a lot of stuff to configure.
1470 A typical sequence to get this all working on Solaris 8: Use some binary
1471 packages from a trusted Sun freeware site (sunfreeware.com). The most problems
1472 were with PHP and the GD library. GD itself needs a bunch of packages and
1473 libraries to work also. It needs the libpng stuff, the libjpeg stuff (if you
1474 want jpeg), etc, etc. Read through the readme for GD. So you either need to get
1475 these and compile them also, or get some binary packages. PHP is the most
1476 difficult thing to get compiled correctly. The PHP package needs to be compiled
1477 with lots of ``-with'' flags for GD to work properly, otherwise it gets lots of
1478 run-time unresolved reference errors. Just using a ``with'' for GD isn't
1479 sufficient. You also need to "with" each library which GD uses also, or PHP
1480 can't find the functions it needs. Here's the ``configure'' line you can use to
1481 get PHP working:
1482 \begin{verbatim}
1483 ./configure --with-mysql --with-apxs=/usr/apache/bin/apxs --with-gd
1484 --enable-sockets --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/
1485 lib --with-zlib-dir=/usr/local/lib --with-xpm-dir=/usr/local/lib
1486 \end{verbatim}
1487 These `with' statements basically have the effect of the Makefile including -L
1488 and -R statements for each library so that both the compile and run time
1489 linkers can find all the functions needed to find in the Apache module
1490 environment. Apache doesn't seem to consult the LD\_LIBRARY\_PATH when running a
1491 module (or PHP doesn't, or there's some config item in the Apache conf files,
1492 but you can just use the ``withs'').
1494 Basically, you need to work from the bottom up. So you need to obtain/compile
1495 any libraries that GD needs and install them, and any libraries/packages those
1496 packages need. Then once you get GD compiled properly and installed, compile
1497 PHP. Then make a PHP script that calls phpinfo() and carefully examine the page
1498 produced. Once satisfied PHP is working, then the 'foundation' is ready for the
1499 other stuff. If they succeed, then install ADODB and BASE, tweak the config
1500 files, and it should all work. (heh, heh)
1502 BASE website: \htmladdnormallink{http://base.secureideas.net/}{http://base.secureideas.net/}
1504 \section{Rules and Alerts}
1506 \subsection{Errors loading rules files}
1508 Some common ones:
1510 \begin{itemize}
1511 \item \begin{verbatim}ERROR telnet.rules:YYY => Port value missing in rule!\end{verbatim}
1512 \item \begin{verbatim}ERROR telnet.rules:YYY => Bad port number: "(msg:"blah"\end{verbatim}
1513 \item \begin{verbatim}ERROR telnet.rules:YYY => Couldn't resolve hostname blah\end{verbatim}
1514 \end{itemize}
1516 What's going on?
1518 ``telnet.rules'' is the file where the syntax error occurred, and ``YYY'' is the
1519 line number it occurred on. There are a couple of possibilities:
1521 \begin{enumerate}
1522 \item The rule is missing a port value, has an invalid port number, or a bad hostname - in which case the ruleset author/maintainer should be notified.
1524 \item More often, the rule is just fine, but a variable in it was not declared. Open the rules file, look at the rule on the line number provided, and confirm that the variables it uses have been declared. You can read more about variables at
1525 \htmladdnormallink{http://www.snort.org/docs/writing\_rules/chap2.html\#tth\_sEc2.1.2}{http://www.snort.org/docs/writing\_rules/chap2.html\#tth\_sEc2.1.2}
1526 \end{enumerate}
1528 \subsection{Snort says ``Rule IP addr (``1.1.1.1'') didn't x-late, WTF?''}
1530 Get rid of the quotes around the IP address and try again.
1532 \subsection{Snort is behind a firewall (ipf/pf/ipchains/ipfilter) and awfully quiet...}
1534 Your firewall rules will also block traffic to the Snort processes.
1536 Note: This does not apply if Snort is installed {\bf on} the firewall box.
1538 \subsection{Does snort see packets filtered by IPTables/IPChains/IPF/PF?}
1540 Snort operates using libpcap. In general it sees everything the network adapter
1541 driver sees before the network stack munges it. Linux IPTables, Linux IPChains,
1542 BSD PF and IPF and other packet filters do not prevent snort from seeing a
1543 packet that is present on the network wire. Even if an inbound packet is denied
1544 by the packet filter Snort will still see and analyze the packet if it is
1545 listening to that interface. Snort/pcap sees whatever comes out of or goes into
1546 the network adapter.
1548 Note however that Snort is affected to the extent that the stream of data on
1549 the network wire is affected. Thus Snort will not see outbound packets which
1550 were denied while being sent since they will never reach the network adapter.
1552 Under OpenBSD you can snort just the PF rejects by using the /dev/pflogN
1553 interface.
1555 \subsection{I'm getting large amounts of $<$some alerts type$>$. What should I do? Where can I go to find out more about it? }
1557 Some rules are more prone to producing false positives than others.
1558 This often varies between networks. You first need to determine if it
1559 is indeed a false positive. Some rules are referenced with ID numbers.
1560 The following are some common identification systems, and where to go
1561 to find more information about a particular alert.
1563 \begin{tabular}{|l|l|l|}
1564 \hline
1565 {\bf System} & {\bf Example} & {\bf URL} \\
1566 \hline\hline
1567 IDS & IDS182 & \htmladdnormallink{http://www.whitehats.com/IDS/182}{http://www.whitehats.com/IDS/182} \\
1568 \hline
1569 CVE & CVE-2000-0138 &
1570 \htmladdnormallink{http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0138}{http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0138} \\
1571 \hline
1572 Bugtraq & BugtraqID 1 & \htmladdnormallink{http://www.securityfocus.com/vdb/bottom.html?vid=1}{http://www.securityfocus.com/vdb/bottom.html?vid=1} \\
1573 \hline
1574 McAfee & Mcafee 10225 & \htmladdnormallink{http://vil.nai.com/vil/dispVirus.asp?virus\_k=10225}{http://vil.nai.com/vil/dispVirus.asp?virus\_k=10225} \\
1575 \hline
1576 Nessus & Nessus 11073 &
1577 \htmladdnormallink{http://cgi.nessus.org/plugins/dump.php3?id=11073}{http://cgi.nessus.org/plugins/dump.php3?id=11073}\\
1578 \hline
1579 \end{tabular}
1581 It may be necessary to examine the packet payload to determine if the
1582 alert is a false positive. The packet payload is logged using the -d
1583 option. If you determine the alerts are false positives, you may want
1584 to write pass rules for machines that are producing a large number of them.
1585 If the rule is producing an unmanageable amount of false positives from
1586 a number of different machines, you could pass on the rule for all traffic.
1587 This should be used as a last resort.
1589 \subsection{What about all these false alarms? }
1591 Most think that a pile of false positives is infinitely preferable. Then
1592 people can turn off what they don't want. The reverse, having a small rule
1593 set, can lure people into complacency thinking that Snort is doing ``its
1594 thing'' and there is nothing to worry about.
1597 \subsection{What are all these ICMP files in subdirectories under /var/log/snort? }
1599 Most of them are likely destination unreachable and port unreachables that
1600 were detected by snort when a communications session attempt fails.
1603 \subsection{Why does the program generate alerts on packets that have pass rules? }
1605 The default order that the rules are applied in is alerts first, then pass
1606 rules, then log rules. This ordering ensures that you don't write 50 great
1607 alert rules and then disable them all accidently with an errant pass rule. If
1608 you really want to change this order so that the pass rules are applied first,
1609 use the ``-o'' command line switch, or the ``order'' config directive.
1611 One other thing to keep in mind is that the alert might be generated from a
1612 preprocessor. If that is the case, then no pass rule will help you minimize the
1613 false positives. You will need to use a BPF filter.
1615 \subsection{What are all these ``ICMP destination unreachable'' alerts? }
1617 ICMP is the acronym for Internet Control Message Protocol
1618 They are failed connections ICMP unreach packet carries first 64
1619 bits(8bytes) or more of the original datagrami and the original IP header.
1621 The ICMP Destination Unreachable (message type 3) is sent back to the
1622 originator when an IP packet could not be delivered to the destination
1623 address. The ICMP Code indicates why the packet could not be delivered.
1624 The original codes are:
1626 \begin{itemize}
1627 \item0 - net unreachable
1628 \item1 - host unreachable
1629 \item2 - protocol unreachable
1630 \item3 - port unreachable
1631 \item4 - fragmentation needed and DF bit set
1632 \item5 - source route failed
1633 \end{itemize}
1635 As far as why... ``it all depends...''
1637 ICMP Unreachable Error Messages are divided into two groups:
1638 \begin{enumerate}
1639 \item ICMP Unreachable Error Messages issued by routers (all 16 of them)
1640 \item ICMP Unreachable Error Messages issued by a Host (only 2)
1641 \end{enumerate}
1643 What are the only 2 issued by a host?
1644 ICMP Port Unreachable - the destination port on the targeted host is
1645 closed (a.k.a. not in a listening state).
1646 ICMP Protocol Unreachable - the protocol we were trying to use is not
1647 being used on the targeted host.
1650 Both ICMP Type field and Code field indicates why the packets could
1651 not be delivered. Some snort ICMP alerts" are informational like the ICMP
1652 alerts found in icmp-info.rules. At this time there are no references
1653 or even classtypes associated with these rules.
1655 Other rules are more likely to be associated with untoward activity. For
1656 example, in icmp.rules you will find:
1658 \begin{verbatim}
1659 alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP ISS Pinger";
1660 content:"|495353504e475251|";itype:8;depth:32; reference:arachnids,158;
1661 classtype:attempted-recon; sid:465; rev:1;)
1662 \end{verbatim}
1664 which has a reference where the importance might be determined by checking
1665 out the arachnids reference. The classtype may indicate more or
1666 less the relative importance of the event.
1668 When a destination UDP port is closed on the targeted host, a.k.a. not
1669 in a listening state, the targeted host will issue an ICMP Port Unreachable
1670 error message back to the offending packets source IP address, given in
1671 the query. Some programs use these messages, like traceroute with *nix
1672 based machines. Windows based machines (tracert) will default to
1673 ICMP Echo requests...
1675 For further information about this, see:
1676 \begin{itemize}
1677 \item IP - ftp://ftp.isi.edu/in-notes/rfc791.txt
1678 \item ICMP - ftp://ftp.isi.edu/in-notes/rfc792.txt
1679 \item TCP - ftp://ftp.isi.edu/in-notes/rfc793.txt
1680 \item UDP - ftp://ftp.isi.edu/in-notes/rfc768.txt
1681 \end{itemize}
1685 \htmladdnormallink{http://www.iana.org/assignments/icmp-parameters}{http://www.iana.org/assignments/icmp-parameters}
1687 Actually, putting this URL somewhere handy is a good idea:
1689 \htmladdnormallink{http://www.iana.org/}{http://www.iana.org/}
1691 There is also a good ICMP paper on
1692 \htmladdnormallink{http://www.sys-security.com/}{http://www.sys-security.com/}
1694 \subsection{Why do many Snort rules have the flags P (TCP PuSH) and A (TCP ACK) set? }
1696 One of the reasons it alerts on a PA flags is to minimize the false
1697 positive. You will only get an alert upon successful connections. If you
1698 want to see all the attempts, you either have to modify the signatures, add
1699 you own signatures or use your firewall logs to see if an attempt to
1700 specific a port occurred.
1703 \subsection{What are these IDS codes in the alert names? }
1705 IDS means "Intrusion Detection Signature" and identifies a
1706 known attack attempt. You can learn more about a specific IDS id
1707 at the arachNIDS search engine on
1708 \htmladdnormallink{http://www.whitehats.com/}{http://www.whitehats.com/}.
1709 The ``references'' keyword in rules can also be a good pointer
1710 for further research.
1713 \subsection{Snort says BACKDOOR SIGNATURE... does my machine have a Trojan? }
1715 If you are dumping the data part of the packet, review it.
1716 These rules are known to have high false rates as most of them
1717 are just based on numeric port numbers.
1720 \subsection{What about ``CGI Null Byte attacks?'' }
1722 It's a part of the http preprocessor. Basically, if the http decoding
1723 routine finds a \%00 in an http request, it will alert with this message.
1724 Sometimes you may see false positives with sites that use cookies with
1725 urlencoded binary data, or if you're scanning port 443 and picking up
1726 SSLencrypted traffic . If you're logging alerted packets you can check
1727 the actual string that caused the alert. Also, the unicode alert is
1728 subject to the same false positives with cookies and SSL. Having the packet
1729 dumps is the only way to tell for sure if you have a real attack on your
1730 hands, but this is true for any content-based alert.
1732 \subsection{Why do certain alerts seem to have `unknown' IPs in BASE? }
1734 See the BASE FAQ at \htmladdnormallink{http://base.secureideas.net/faq.php}{http://base.secureideas.net/faq.php}
1736 \subsection{Can priorities be assigned to alerts using BASE? }
1738 See the BASE FAQ at \htmladdnormallink{http://base.secureideas.net/faq.php}{http://base.secureideas.net/faq.php}
1740 \subsection{What about `SMB Name Wildcard' alerts? }
1742 Whitehats IDS177
1743 \htmladdnormallink{http://dev.whitehats.com/cgi/test/new.pl/Show?\_id=netbios-name-query}{http://dev.whitehats.com/cgi/test/new.pl/Show?\_id=netbios-name-query}
1744 specifies traffic coming from {\em outside} of your local network. Allowing
1745 netbios traffic over public networks is usually very insecure.
1747 If the rule you are using also refers to ingres traffic only, then it
1748 would explain why you don't see a lot of false positives. For anyone
1749 reading that does see a lot of false postiives - if you change your rule
1750 to reflect the source address as being !\$HOME (or whatever variable you
1751 use to represent your internal network), then you should see most of the
1752 false positives go away.
1754 The value of this chack is that a default administrative share C\$ ADMIN\$ or
1755 some such has been accessed. This shouldn't happen in normal use - when
1756 people want to share files they should be implicitely defining the shares
1757 and ACL.
1759 \subsection{What the heck is a SYNFIN scan? }
1761 SYNFIN scans got their name because there are both the SYN and FIN flags set.
1763 \subsection{I am getting too many ``IIS Unicode attack detected'' and/or ``CGI Null Byte attack detected'' false positives. How can I turn this detection off? }
1765 These messages are produced by the http\_decode preprocessor. If you wish
1766 to turn these checks off, add -unicode or -cginull to your http\_decode
1767 preprocessor line respectively.
1769 \begin{verbatim}preprocessor http_decode: 80 8080 -unicode -cginull\end{verbatim}
1771 Your own internal users normal surfing can trigger these alerts in the
1772 preprocessor. Netscape in particular has been known to trigger them.
1774 Instead of disabling them,try a BPF filter to ignore your outbound http
1775 traffic such as:
1777 \begin{verbatim}snort -d -A fast -c snort.conf not (src net xxx.xxx and dst port 80)\end{verbatim}
1779 This has worked very well for us over a period of 5-6 months and Snort is
1780 still very able to decode actual and dangerous cgi null and unicode attacks
1781 on our public web servers.
1783 \subsection{How do I test Snort alerts and logging?}
1785 Try a rule that will fire off all the time like:
1787 \begin{verbatim}alert tcp any any -> any any (msg:"TCP traffic";)\end{verbatim}
1789 Also take a look at sneeze at http://snort.sourceforge.net/sneeze-1.0.tar
1790 Sneeze is a false positive generator that reads snort signatures and generates
1791 packets that will trigger the rules.
1793 \subsection{What is the difference between ``Alerting'' and ``Logging''?}
1795 There are two primary output facilities in Snort, logging and alerting. The
1796 alerting facility exists to let you know that something interesting has
1797 happened. The logging facility exists to log full packet information to the
1798 output format (pcap, ascii, database, etc).
1800 The ``alert'' action in Snort is hard coded to do two things when an event is
1801 detected by Snort, write an event to the alert facility and log as much as
1802 possible/desired to the output facility. The ``log'' action merely logs the
1803 current packet to the logging facility without generating an alert. This is
1804 done so you can log interesting things (telnet sessions, whatever) without
1805 having to generate an alert on every packet.
1807 The database plugin is something of an anomaly because it doesn't separate the
1808 two functionalities very much. The ``log'' option attaches the log facility and
1809 the ``alert'' option attaches it to the alert facility. What this means in
1810 practical terms is that if the db plugin is in alert mode, it will only receive
1811 output from alert rules, whereas if it's in ``log'' mode it will receive output
1812 from both log and alert rules.
1814 \subsection{Are rule keywords ORed or ANDed together?}
1816 >From Section 2.1 of the Snort Manual:
1817 \myquote{
1818 All of the elements in that make up a rule must be true for the indicated
1819 rule action to be taken. When taken together, the elements can be
1820 considered to form a logical AND statement. At the same time, the various
1821 rules in a Snort rules library file can be considered to form a large
1822 logical OR statement.
1824 \subsection{Can Snort trigger a rule by MAC addresses?}
1826 Not exactly. Snort logs MAC addresses and other L2 info within the packets. The
1827 arpwatch pre-processor can watch for games with MAC address changes. But there
1828 is no facility for triggering Rules form the L2 information. The content search
1829 keywords and depth and offset begin from the L3 payload, though we haven't
1830 tried playing with really big offsets yet :-).
1832 \subsection{How can I deactivate a rule?}
1834 Rules can be called from an included file in snort.conf, which tells Snort to
1835 follow the path to the rules file specified, and load it at initialization.
1836 Rules can also be included in snort.conf directly. If you want to deactivate a
1837 single rule within any list of rules, you can use one of these techniques:
1839 \begin{enumerate}
1840 \item Delete the rule and re-initialize Snort
1841 \item Place a \# in front of the rule, commenting it out, and re-initialize Snort
1842 \item Write a pass rule with the same properties in local.rules (or wherever you
1843 prefer), and re-initialize Snort with the -o option.
1844 \end{enumerate}
1846 \subsection{How can I define an address to be anything except some hosts?}
1848 Use the ! operator. E.g.:
1850 \begin{verbatim}
1851 var EXTERNAL_NET !$HOME_NET
1852 \end{verbatim}
1853 Note that the negation operator does not work inside a list so the following
1854 will NOT work:
1855 \begin{verbatim}
1856 var EXTERNAL_NET [!192.168.40.0/24,!10.14.0.0/16]
1857 \end{verbatim}
1858 but this will work:
1859 \begin{verbatim}
1860 var EXTERNAL_NET ![192.168.40.0/24,10.14.0.0/16]
1861 \end{verbatim}
1862 \subsection{After I add new rules or comment out rules how do I make Snort reload?}
1864 Usually a kill -HUP will work just fine. But if you are running inside of a
1865 chroot setup, this will not work as expected \myref{chroot}. If you're running
1866 like inside of a chroot jail, your best bet would be to kill and restart the
1867 snort process instead.
1869 \subsection{Where do the distance and within keywords work from to modify content
1870 searches in rules?}
1872 The ``distance'' keyword gives you a relative offset from the end of the last
1873 match, so it basically acts as a wildcarding mechanism. You can also use the
1874 new ``within'' keyword to limit how deep into the packet from the end of the
1875 distance it'll search before it stops.
1877 \subsection{How can I specify a list of ports in a rule?}
1879 You can't yet. You can specify a range of ports between X and Y with the
1880 notation X:Y. See the users manual (\htmladdnormallink{http://www.snort.org/docs/writing\_rules/chap2.html\#tth\_sEc2.2.4}{http://www.snort.org/docs/writing\_rules/chap2.html\#tth\_sEc2.2.4}) for more info on port ranges.
1882 \subsection{How can I protect web servers running on ports other than 80?}
1884 It is possible... It's a kludge, but it can work. Since the newer rules use
1885 the \$HTTP\_PORTS variable, you simply reset it and re-run the rules for the other
1886 ports.
1888 For example:
1889 \begin{verbatim}
1890 var HTTP_PORTS 80
1891 include web.rules
1892 var HTTP_PORTS 8080
1893 include web.rules
1894 \end{verbatim}
1896 \subsection{How do I turn off ``spp:possible EVASIVE RST detection'' alerts?}
1898 You want to pass the ``disable\_evasion\_alerts'' argument to stream4 in
1899 snort.conf.
1901 \subsection{Is there a private SID number range so my rules don't conflict?}
1903 Yes. Private SIDs start at 1000000.
1905 \subsection{How long can address lists, variables, or rules be?}
1907 The Snort parser has an 8K limit on variables and rules {\bf after} expansion. In
1908 practice, this is not a major limitation. :-)
1910 \subsection{What do the numbers (ie: [116:56:1]) in front of a Snort alert mean?}
1912 For this explanation, we'll use the following example:
1913 \begin{verbatim}
1914 [**] [116:56:1] (snort_decoder): T/TCP Detected [**]
1915 \end{verbatim}
1916 The first number is the Generator ID, this tells the user what component
1917 of Snort generated this alert. For a list of GIDs, please read
1918 etc/generators in the Snort source. In this case, we know that this event
1919 came from the ``decode'' (116) component of Snort.
1921 The second number is the Snort ID (sometimes referred to as Signature
1922 ID). For a list of preprocessor SIDs, please see etc/gen-msg.map.
1923 Rule-based SIDs are written directly into the rules with the ``sid''
1924 option. In this case, ``56'' represents a T/TCP event.
1926 The third number is the revision ID. This number is primarily used when
1927 writing signatures, as each rendition of the rule should increment this
1928 number with the ``rev'' option.
1931 \section{Getting Fancy}
1933 \subsection{I hear people talking about ``Barnyard''. What's that?\label{barnyard}}
1935 Barnyard is a output system for Snort. Snort creates a special binary output
1936 format called ``unified.'' Barnyard reads this file, and then resends the data
1937 to a database backend. Unlike the database output plugin, Barnyard is aware of
1938 a failure to send the alert to the database, and it stops sending alerts. It is
1939 also aware when the database can accept connections again and will start
1940 sending the alerts again.
1942 \subsection{Are there other output systems for Snort besides ``Barnyard''?\label{spoolers}}
1944 FLoP (Fast Logging Project) and Mudpit are two other programs that can be used.
1946 FLoP adds a patch to Snort that creates an output plugin that writes alerts to
1947 a Unix domain socket instead of a file. These alerts (which are stored in memory)
1948 are then sent to a central server where they are then written to a database.
1949 Advantages are that database requests are made locally rather than over
1950 the wire and files don't need to be stored on the sensor.
1952 \htmladdnormallink{http://www.geschke-online.de/FLoP/}{http://www.geschke-online.de/FLoP/}
1954 Mudpit is similar to Barnyard in that it uses Snort's unified output. It however
1955 has the ability to process both alert and log files in parallel, choosing one
1956 that contains more information on a particular event.
1958 \htmladdnormallink{http://farm9.org/Mudpit/}{http://farm9.org/Mudpit/}
1960 \subsection{How do I process those Snort logs into reports?}
1961 \begin{enumerate}
1962 \item Barnyard \myref{barnyard} can be used to process unified output files into a number of
1963 formats, including output to a database for further analysis.
1964 \item SnortSnarf, a tool for producing HTML out of snort alerts for navigating
1965 through these alerts.
1967 % \htmladdnormallink{http://www.silicondefense.com/snortsnarf/}{http://www.silicondefense.com/snortsnarf/}
1969 \item If you want to set up logging to a database you could try BASE:
1971 \htmladdnormallink{http://base.secureideas.net/}{http://base.secureideas.net/}
1973 \item You can manipulate the unified output files directly without a separate
1974 database and browse/correlate them with Cerebus:
1976 \htmladdnormallink{http://dragos.com/cerebus/}{http://dragos.com/cerebus/}
1978 \item For GUI front ends with simple log browsing, look at:
1979 \begin{itemize}
1980 \item HenWen (OSX)
1982 \htmladdnormallink{http://homepage.mac.com/nickzman}{http://homepage.mac.com/nickzman}
1984 \htmladdnormallink{http://home.attbi.com/~rickzman/software/HenWen1.0.sit.bin}{http://home.attbi.com/~rickzman/software/HenWen1.0.sit.bin}
1986 \item IDS Center (Win32) \label{IDSCenter}
1988 \htmladdnormallink{http://www.packx.net/}{http://www.packx.net/}
1990 \item Puresecure (UNIX and Win32) (Formerly known as Demarc.)
1992 \htmladdnormallink{http://www.demarc.com/downloads/puresecure/}{http://www.demarc.com/downloads/puresecure/}
1994 \item SnortCenter (UNIX and Win32)
1996 \htmladdnormallink{http://users.pandora.be/larc/}{http://users.pandora.be/larc/}
1998 \item IDS Policy Manager (Win32)
2000 \htmladdnormallink{http://www.activeworx.com/IDSPM/}{http://www.activeworx.com/IDSPM/}
2001 \end{itemize}
2002 \end{enumerate}
2004 \subsection{How do I log to multiple databases or output plugins?}
2006 Feed the unified output files through Barnyard twice to separate databases,
2007 or...
2009 You can build redundancy by using multiple output plugins. Here are some
2010 examples.
2012 Multiple instantiations of the database plugin:
2013 \begin{verbatim}
2014 output log_database: mysql, dbname=snort host=localhost user=xyz
2015 output log_database: mysql, dbname=snort host=remote.loghost.com user=xyz
2016 \end{verbatim}
2017 Remote database and local tcpdump:
2018 \begin{verbatim}
2019 output log_database: mysql, dbname=snort host=remote.loghost.com user=xyz
2020 output log_tcpdump: /var/log/snort.tcpdump
2021 \end{verbatim}
2022 Then you can replay the tcpdump file through snort to recreate the database.
2024 CAVEAT: Just playing back the log packets might not trigger some of the state
2025 dependent pre-processors.
2027 \subsection{How can I test Snort without having an Ethernet card or a connection to other computers? }
2029 You have to use routing between two dummy devices:
2031 \begin{verbatim}
2032 modprobe -a dummy # (The dummy device has to be build by the kernel)
2033 ifconfig dummy0 192.168.0.1
2034 ifconfig dummy0:0 192.168.0.2
2035 telnet 192.168.0.3 12345
2036 \end{verbatim}
2038 It's important that the second IP is on the same interface and not, e.g.
2039 dummy1 or dummy2 and that the IP you try to access is {\em not} one of those you
2040 put on the interfaces. Use snort's ability to hear in promiscious mode on an
2041 IP address range. (HOME\_NET=192.168.0.0/16)
2043 \subsection{How to start Snort as a win32 service? }
2045 \begin{enumerate}
2046 \item You must use complete paths for everything. This means EVERYTHING: Command
2047 line, configuration files, everything.
2049 Examples: All include statements must be full paths:
2051 WRONG: include scan-lib
2053 CORRECT: include C:\( \backslash \)snort\( \backslash \)scan-lib
2055 All command line options must be full paths:
2057 WRONG: snort.exe -l ./log
2059 CORRECT: snort.exe -l C:\( \backslash \)snort\( \backslash \)log
2061 \item YOU MUST ALWAYS HAVE A LOGGING DIRECTORY SET VIA THE COMMAND LINE (-l
2062 switch). If you do not set a logging directory the service will not start
2063 and, on NT/Win2k, your bootup will hang for about 4 minutes.
2064 \item Make sure that snort runs correctly from the command line, without yet
2065 worrying about any service related issues. Test that all of your desired
2066 command line parameters are causing snort to function as you expect, such
2067 as correctly generating logging and alert output. If you can't get this
2068 part to work, then you don't have much hope of snort miraculously starting
2069 to work as a service.
2070 \item Once you have step (3) running correctly, modify the command line
2071 parameters you used in step (3) to include the additional parameters
2072 ``/SERVICE /INSTALL.'' For example, if your command line in step (3) was:
2073 \begin{verbatim}
2074 snort -i1 -lC:\( \backslash \)snort\( \backslash \)log -cC:\( \
2075 backslash \)snort\( \backslash \)snort.conf
2076 \end{verbatim}
2077 then you should change it to be:
2078 \begin{verbatim}
2079 snort /SERVICE /INSTALL -i1 -lC:\( \backslash \)snort\( \backslash \)
2080 log -cC:\( \backslash \)snort\( \backslash \)snort.conf
2081 \end{verbatim}
2082 Verify that the command line parameters were received correctly by running
2083 the command `snort /SERVICE /SHOW.'
2084 \item Start the service by running the command:
2085 \begin{verbatim}
2086 net start snortsvc
2087 \end{verbatim}
2088 Note that versions 1.9 (build 228), 2.0 (build 50), or any versions newer
2089 than these, will add entries to the Win32 event Log if there is ever a
2090 problem starting the service.
2091 Stop the service by running the command:
2092 \begin{verbatim}
2093 net stop snortsvc
2094 \end{verbatim}
2095 \item The service can be uninstalled by running the command:
2096 \begin{verbatim}
2097 snort /SERVICE /UNINSTALL
2098 \end{verbatim}
2099 \end{enumerate}
2101 \subsection{Is it possible with snort to add a ipfilter/ipfw rule to a firewall? }
2103 Yes. Select the appropriate DAQ module for your system. IPQ, NFQ, and IPFW
2104 DAQs are available, among others. See README.daq for details. Other
2105 possibilities are listed below.
2107 \begin{itemize}
2108 \item SnortSam
2109 \htmladdnormallink{http://www.snortsam.net}{http://www.snortsam.net}
2111 \item You also might wat to look at inline-snort at:
2112 \htmladdnormallink{http://www.snort.org/dl/contrib/patches/snort-inline}{http://www.snort.org/dl/contrib/patches/snort-inline}
2113 \item Guardian is available and is part of the contrib section at \htmladdnormallink{http://www.snort.org}{http://www.snort.org}.
2115 Guardian is a perl script which uses Snort to detect attacks,
2116 and then uses IPchains to deny any further attacks. The Guardian webpage can be found at:
2117 \htmladdnormallink{http://www.chaotic.org/~astevens/Guardian/index.html}{http://www.chaotic.org/~astevens/Guardian/index.html}
2118 or you can use the mirror,
2119 \htmladdnormallink{http://www.cyberwizards.com/~midnite/Guardian/index.html}{http://www.cyberwizards.com/~midnite/Guardian/index.html}
2121 \end{itemize}
2122 But one caveat... running external binaries can also be a performance
2123 limiter and your should read the caution below...
2125 CHRISTOPHER CRAMER wrote:
2127 \myquote{
2128 I'm sure this has been mentioned before in similar discussions, but this
2129 feels like a \_really\_ bad idea. What if the bad guys realize what is
2130 going on and make use of your blocking method as a DoS attack. All one
2131 would have to do start sending a series of triggering packets with spoofed
2132 IP addresses.
2134 Since I am no longer interested in breaking into your site, but rather
2135 making your life hell, I don't worry about the resulting data getting back
2136 to me. All I have to do is start proceeding up a list of IP addresses
2137 that I think you should no longer be able to talk to. When you come in
2138 the next morning, you find that you can no longer access the world.
2140 Just my \$0.02.
2143 Danger Will Robinson: Conventional wisdom says that
2144 auto-blocking is inherently dangerous.
2146 However, for those that like to live at the
2147 bleeding edge of tech (and the separate
2148 process scanning logs and processing
2149 firewall commands sounds like a good
2150 way to do this...):
2152 Please remember to include an exclusion list and put
2153 on them important sites such as root servers, other
2154 important dns servers (yours, and important sites for
2155 your users), and in general any host you don't want
2156 to receive phone calls about being DoSed when
2157 they are spoofed - usually inconveniently like that
2158 first time you actually manage to get on vacation....
2159 (i.e. imagine ``Crisis: the CEO can't reach his favorite
2160 redlite.org game.... you have to fly back from the
2161 Carribean ASAP....'')
2163 \subsection{What is the best way to use Snort to block attack traffic?}
2165 \begin{verbatim}snort-inline > hogwash >> SnortSAM|Guardian >> flexresp\end{verbatim}
2168 \subsection{Snort complains about the ``react'' keyword...}
2170 Rerun configure with the --enable-flexresp option and rebuild/reinstall.
2172 \subsection{How do I get Snort to e-mail me alerts?}
2174 You can't. Such a process would slow Snort down too much to make it of any use.
2175 Instead, log to syslog and use swatch or logcheck to parse over the plaintext
2176 logfiles.
2178 With the Logsurfer docs, this might get you on the road to doing something with
2179 Snort and Logsurfer:
2180 \begin{itemize}
2181 \item
2182 \htmladdnormallink{http://www.obfuscation.org/emf/logsurfer/snort.txt}{http://www.obfuscation.org/emf/logsurfer/snort.txt}
2183 \end{itemize}
2184 JASON HAAR provided an example Swatch (3.1beta) config that emails alerts:
2186 \begin{itemize}
2187 \item \htmladdnormallink{http://www.theadamsfamily.net/~erek/snort/snort-swatch.conf.txt}{http://www.theadamsfamily.net/~erek/snort/snort-swatch.conf.txt}
2188 \end{itemize}
2189 Here are some docs on swatch:
2190 \begin{itemize}
2191 \item \htmladdnormallink{http://www.oit.ucsb.edu/~eta/swatch/}{http://www.oit.ucsb.edu/~eta/swatch/}
2192 \item \htmladdnormallink{http://www.stanford.edu/~atkins/swatch}{http://www.stanford.edu/~atkins/swatch}
2193 \item \htmladdnormallink{http://rr.sans.org/sysadmin/swatch.php}{http://rr.sans.org/sysadmin/swatch.php}
2194 \item \htmladdnormallink{http://www.enteract.com/~lspitz/swatch.html}{http://rr.sans.org/sysadmin/swatch.php}
2195 \item \htmladdnormallink{http://www.cert.org/security-improvement/implementations/i042.01.html}{http://www.cert.org/security-improvement/implementations/i042.01.html}
2196 \end{itemize}
2198 IDS Center \myref{IDSCenter} on Win32 will also mail alerts.
2200 \subsection{How do I log a specific type of traffic and send alerts to syslog?}
2202 An example addition to snort.conf:
2203 \begin{verbatim}
2204 ruletype redalert {
2205 type alert
2206 output alert_syslog: LOG_LOCAL2
2207 output database: alert, postgresql, user=user dbname=snort password=pwd
2209 \end{verbatim}
2211 Go into your local.rules and make sure you have something like:
2213 \begin{verbatim}
2214 redalert tcp any any -> any any (msg:"REDRUM REDRUM"; content:"redalerttest")
2215 \end{verbatim}
2217 Then just do a telnet and type `redalerttest.' Presto, alerts to both.
2219 \subsection{Is it possible to have Snort call an external program when an alert is raised?}
2221 Calling another program from within your main IDS loop is
2222 generally a bad idea. Having your IDS block while waiting
2223 for $<$something$>$ of dubious reliability and origin nevermind
2224 timing while the packets are piling up is inviting packet loss.
2225 Especially with the already oh-so-consistent ``Gee I think
2226 I'll go away for a minute'' rock steady even cpu slicing
2227 Windows gives you (that's sarcasm, sorry). Go with the
2228 second approach.... process invokation is expensive on
2229 Windows.
2231 You want to keep that IDS task humming and munching
2232 packets as efficiently as possible with as few interruptions
2233 as possible, imho, and not be invoking the penalty of
2234 process invocation.... particularly on Windows where
2235 process invocation is much much heavier task than *nix.
2237 Even in a secondary process... You'll probably find
2238 something that stays ``awake'' all the time will work out
2239 much more nicely than something that gets ``woken up''
2240 on a per alert basis for the aforementioned reasons.
2242 As a better alternative go check out swatch or logwatch.
2243 Also for those new to UNIX, logging alerts to syslog and then using
2244 ``tail -f /var/log/messages'' might be what you are looking for.
2246 \subsection{How can I use Snort to log HTTP URLs or SMTP traffic?}
2248 It can be done with Snort, but you might find it faster to use mailsnarf and
2249 urlsnarf from Dug Song's dsniff package. Dsniff is available from:
2251 \htmladdnormallink{http://www.monkey.org/~dsong/dsniff/}{http://www.monkey.org/~dsong/dsniff/}
2253 You can get a win32 port of dsniff at:
2255 \htmladdnormallink{http://www.datanerds.net/~mike/dsniff.html}{http://www.datanerds.net/~mike/dsniff.html}
2257 \subsection{What are some resources that I can use to understand more about source
2258 addresses logged and where they are coming from?}
2260 \begin{itemize}
2261 \item \htmladdnormallink{http://www.arin.org/}{http://www.arin.org/}
2262 \item \htmladdnormallink{http://www.caida.org/tools/utilities/netgeo/}{http://www.caida.org/tools/utilities/netgeo/}
2263 \item \htmladdnormallink{http://netgeo.caida.org/perl/netgeo.cgi}{http://netgeo.caida.org/perl/netgeo.cgi}
2264 \item \htmladdnormallink{http://standards.ieee.org/regauth/oui/oui.txt}{http://standards.ieee.org/regauth/oui/oui.txt}
2265 \item \htmladdnormallink{http://www.codito.de/manufactor\_hash}{http://www.codito.de/manufactor_hash}
2266 \item \htmladdnormallink{http://coffer.com/mac\_find/}{http://coffer.com/mac_find/}
2267 \item \htmladdnormallink{http://www.idefense.com/Intell/CI022702.html}{http://www.idefense.com/Intell/CI022702.html}
2268 \item \htmladdnormallink{http://www.idefense.com/excelfiles/All.zip}{http://www.idefense.com/excelfiles/All.zip}
2269 \end{itemize}
2271 Also, try ``dig.''
2273 \subsection{How do I understand this traffic and do IDS alert analysis?}
2275 \begin{enumerate}
2276 \item You'll need to understand some basics of IP, TCP, and UDP. Things like
2277 destination addresses, source addresses, common ports, what TCP SYN, FIN
2278 and RST mean, etc. The same kind of basic knowledge of the internet you
2279 need to successfully configure a multi-interface router applies here,
2280 although you don't need to know router syntax. Some useful online
2281 references:
2282 \begin{itemize}
2283 \item A truly basic ``intro to TCP/IP'' \htmladdnormallink{http://pclt.cis.yale.edu/pclt/COMM/TCPIP.HTM}{http://pclt.cis.yale.edu/pclt/COMM/TCPIP.HTM}
2284 \item A reasonable looking TCP/IP FAQ: \htmladdnormallink{http://www.itprc.com/tcpipfaq/default.htm}{http://www.itprc.com/tcpipfaq/default.htm}
2285 \item A basics of firewalls, DMZ's, etc.
2287 \htmladdnormallink{http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html\_single/Firewall-HOWTO.html}{http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Firewall-HOWTO.html}
2288 \end{itemize}
2289 \item You'll need to understand some basics of how network attacks work. I'd
2290 recommend skimming over ``Smashing the Stack for fun and profit'' by Aleph
2291 one. A deep understanding isn't necessary, but a casual read of this will
2292 give you some helpful basics in understanding the kinds of things that
2293 happen in an attack, and give you a better understanding of what to look
2294 for.
2296 \htmladdnormallink{http://www.insecure.org/stf/smashstack.txt}{http://www.insecure.org/stf/smashstack.txt}
2298 \item A good guide on securing systems is helpful, something like this one:
2300 \htmladdnormallink{http://www.openna.com/products/books/sol/solus.php}{http://www.openna.com/products/books/sol/solus.php}
2302 \htmladdnormallink{http://www.seifried.org/lasg/}{http://www.seifried.org/lasg/}
2304 \item You'll need to understand the basics of internet servers, ie: what DNS,
2305 HTTP, FTP, SMTP, etc. are for. Most of that should be covered in the
2306 various other references made here.
2307 \item An excellent reference on ``oddball'' traffic patterns commonly seen at
2308 network borders, also very helpful:
2310 \htmladdnormallink{http://www.robertgraham.com/pubs/firewall-seen.html}{http://www.robertgraham.com/pubs/firewall-seen.html}
2311 \item Also take a look at the ``Recommended Reading'' section \myref{courses}
2312 \end{enumerate}
2315 \subsection{How can I examine logged packets in more detail?}
2317 If you are using unified logging, you can use Barnyard \myref{barnyard} or the unified log to pcap converter written by Dragos:
2319 \htmladdnormallink{http://dragos.com/logtopcap.c}{http://dragos.com/logtopcap.c}
2321 You can also use the \texttt{getpacket} program from the FLoP project \myref{spoolers}
2323 You can then get additional decoding of the packet contents by analyzing these
2324 pcap files with either:
2325 \begin{itemize}
2326 \item Tcpdump - http://www.tcpdump.org
2327 \item Ethereal - http://www.ethereal.com
2328 \end{itemize}
2330 \section{Problems}
2331 \subsection{ I think I found a bug in Snort. Now what?}
2333 Get some more diagnostic information and post it to ``snort-users'' at
2334 \htmladdnormallink{http://www.sourceforge.net/lists/listinfo/snort-users}{http://www.sourceforge.net/lists/listinfo/snort-users}.
2336 To get diagnostic information, compile snort as either:
2338 \begin{verbatim}make clean; make CFLAGS=-ggdb\end{verbatim}
2341 \begin{verbatim}make clean; make "CFLAGS=-ggdb -DDEBUG" \end{verbatim}
2343 trace coredump as:
2345 \begin{verbatim}
2346 gdb /path/to/snort /path/to/snort/core
2348 gdb> where
2349 gdb> bt
2350 gdb> print $varname, varname, \$\$varname etc..
2351 \end{verbatim}
2353 or if corefile isn't generated, Snort should be started as:
2355 \begin{verbatim}
2356 gdb snort
2358 gdb> run snort\_args\_go\_here
2359 \end{verbatim}
2361 Then, when it crashes:
2362 \begin{verbatim}
2363 gdb> where
2364 gdb> bt
2365 gdb> print \$varname, varname, \$\$varname etc..
2366 \end{verbatim}
2368 \subsection{SMB alerts aren't working, what's wrong? }
2370 The SMB alerting output plugin was removed in Snort 2.1 due to security issues.
2372 \subsection{Snort says ``Garbage Packet with Null Pointer discarded!'' Huh?}
2374 This was an internal diagnostic message triggered by an old bug
2375 in early versions of the defragmentation preprocessor. Upgrade to
2376 to the latest version of Snort.
2378 \subsection{Snort says ``Ran Out Of Space.'' Huh?}
2380 This is an internal diagnostic message when the defragmentation
2381 preprocessor runs into its ~32MB hard allocation space limit.
2382 Tell Dragos about it $<$dr@kyx.net$>$.
2384 \subsection{My BASE db connection times-out when performing long operations (e.g.
2385 deleting a large number of alerts).}
2387 PHP has an internal variable set to limit the length an script can execute. It
2388 is used to prevent poorly written code from executing indefinitely. In order to
2389 modify the time-out value, examine the 'max\_execution\_time' variable found in
2390 the 'php.ini' configuration file.
2392 \subsection{Why does snort report ``Packet loss statistics are unavailable under Linux?''}
2394 The Linux IP stack doesn't report lost packet stats. This also has been
2395 recently fixed with the 2.4+ kernel in the new version of libpcap...upgrade
2396 kernels and libpcap and it should now work.
2398 \subsection{My /var/log/snort directory gets very large...}
2400 Try this script to archive the files:
2402 \begin{verbatim}
2403 * []#!/bin/sh
2406 # Logfile rotation script for snort writen by jameso@elwood.net.
2408 # This script is pretty basic. We start out by setting some vars.
2409 # Its job is tho rotate the days logfiles, e-mail you with what
2410 # it logged, keep one weeks worth of uncompressed logs, and also
2411 # keep compressed tgz files of all the logs. It is made to be run
2412 # at midnight everynight. This script expects you to have a base
2413 # dir that you keep all of your logs, rule sets etc in. You can
2414 # see what sub dirs it expects from looking at the var settings
2415 # below.
2417 # Things to note in this script is that we run this script at 12
2418 # every night, so we want to set the dirdate var the day the script
2419 # runs minus a day so we label the files with the correct day. We
2420 # Then create a dir for the days logs, move the log files into
2421 # todays dir. As soon as that is done restart snort so we don't miss
2422 # anything. Then delete any logs that are uncompressed and over a
2423 # week old. Then compress out todays logs and archive them away, and
2424 # end up by mailling out the logs to you.
2426 # Define where you have the base of your snort install
2427 snortbase=/usr/snort
2428 # Define other vars
2429 # logdir - Where the logs are kept
2430 # oldlogs - Where you want the archived .tgz logs kept
2431 # weeklogs - This is where you want to keep a weeks worth of log files uncompressed
2432 # dirdate - Todays Date in Month - Day - Year format
2433 # olddirdate - Todays date in the same format as dirdate, minus a week
2434 logdir=$snortbase/log
2435 oldlogs=$snortbase/oldlogs
2436 weeklogs=$snortbase/weeklogs
2437 # When I first wrote this script, I only ran it on BSD systems. That was a
2438 # mistake, as BSD systems have a date command that apperently lets you walk the
2439 # date back pretty easily. Well, some systems don't have this feature, so I had
2440 # to change the way that dates are done in here. I left in the old way, because
2441 # it is cleaner, and I added in a new way that should be portable. If anyone
2442 # has any problems, just let me know and I will try to fix it.
2444 # You have to change the system var to either bsd or other. Set it to bsd if
2445 # your system supports the "-v" flag. If you are not sure, set it to other.
2446 system=bsd
2447 if [ $system = bsd ]
2448 then
2449 dirdate=`date -v -1d "+%m-%d-%y"`
2450 olddirdate=`date -v -8d "+%m-%d-%y"`
2451 elif [ $system = other ]
2452 month=`date "+%m"`
2453 yesterday=`expr \`date "+%d"\` - 1`
2454 eightday=`expr \`date "+%d"\` - 8`
2455 year=`date "+%y"`
2456 dirdate=$month-$yesterday-$year
2457 olddirdate=$month-$eightday-$year
2460 # Create the Dir for todays logs.
2461 if [ ! -d $weeklogs/$dirdate ]
2462 then
2463 mkdir $weeklogs/$dirdate
2466 # Move the log files into todays log dir. This is done with
2467 # a for loop right now, because I am afriad that if alot is
2468 # logged there may be to many items to move with a "mv *"
2469 # type command. There may a better way to do this, but I don't
2470 # know it yet.
2471 for logitem in `ls $logdir` ; do
2472 mv $logdir/$logitem $weeklogs/$dirdate
2473 done
2475 # Kill and restart snort now that the log files are moved.
2477 kill `cat /var/run/snort_fxp0.pid`
2479 # Restart snort in the correct way for you
2481 /usr/local/bin/snort -i fxp0 -d -D -h homeiprange/28 -l /usr/snort/log \
2482 -c /usr/snort/etc/08292k.rules > /dev/null 2>&1
2484 # Delete any uncompressed log files that over a week old.
2486 if [ -d $weeklogs/$olddirdate ]
2487 then
2488 rm -r $weeklogs/$olddirdate
2491 # Compress and save the log files to save for as long as you want.
2492 # This is done in a sub-shell because we change dirs, and I don't want
2493 # to do that within the shell that the script runs in.
2495 (cd $weeklogs; tar zcvf $oldlogs/$dirdate.tgz $dirdate > /dev/null 2>&1)
2497 # Mail out the log files for today.
2499 cat $weeklogs/$dirdate/snort.alert | mail -s "Snort logs" you@domain.com
2500 cat $weeklogs/$dirdate/snort_portscan.log |
2501 mail -s "Snort portscan logs" you@do
2502 main.com
2503 \end{verbatim}
2505 \subsection{Why does the `error deleting alert' message occur when attempting to delete an alert with BASE? }
2507 Most likely the DB user configure in BASE does not have sufficient
2508 privileges. In addition to those privileges granted to log the alerts into
2509 the database (INSERT, SELECT), DELETE is also required.
2511 This permission related issue can be confirmed by manually inserting a row
2512 into the database, then trying to delete it.
2514 \begin{enumerate}
2515 \item Log into MySQL with the same credentials (i.e. username, password) as you use in BASE:
2516 \begin{verbatim}
2517 mysql -u -p
2518 \end{verbatim}
2519 \item Insert a test row into the event table:
2520 \begin{verbatim}
2521 mysql> INSERT INTO event (sid, cid, signature, timestamp)
2522 VALUES (1,1000000, "test", "0");
2523 \end{verbatim}
2524 (this assumes that you don't already have a row with an event ID=1000000. If
2525 you do just choose another event id \#)
2527 \item Now delete this newly inserted row:
2529 \begin{verbatim}mysql> DELETE FROM event WHERE sid=1 AND cid=10000000; \end{verbatim}
2531 If you were not able to delete, this confirms that this is a permission
2532 problem. Re-login to mysql as root, and issue a GRANT command (giving the
2533 DELETE permission) to the BASE DB user:
2535 \begin{verbatim}GRANT DELETE on snort.* to base@localhost\end{verbatim}
2537 (this assumes that my alert database is 'snort', username is 'base', and
2538 logging from the 'localhost')
2540 \end{enumerate}
2541 \subsection{BASE appears to be broken in Lynx }
2543 See the BASE FAQ at \htmladdnormallink{http://base.secureideas.net/faq.php}{http://base.secureideas.net/faq.php}
2545 \subsection{I am getting `snort [pid] uses obsolete (PF\_INET, SOCK\_PACKET)' warnings. What's wrong?}
2547 You are using an older libpcap version with recent linux kernel. There should be
2548 no problem with it as long as your kernel supports SOCK\_PACKET socket
2549 type. To get rid off the warning message however, you'll have to upgrade
2550 to some recent version of libpcap (a copy from www.tcpdump.org is recommended).
2552 \subsection{On HPUX I get device lan0 open: recv\_ack: promisc\_phys: Invalid argument}
2554 It's because there's another program running using the DLPI service.
2555 The HP-UX implementation doesn't allow more than one libpcap program
2556 at a time to run, unlike Linux (from snort.c).
2558 \subsection{Snort is dying with a `can not create file' error and I have plenty of diskspace. What's wrong?}
2560 You may run out of free inodes, which basically also means you can not create
2561 more files on the partition. The obvious solution is to rm some. ;-)
2563 \subsection{I am using Snort on Windows and receive an ``OpenPcap() error upon startup: ERROR: OpenPcap() device open: Error opening adapter'' message. What's wrong? }
2565 Either winpcap is not installed, or you are using an incompatible version.
2566 Try upgrading to the latest version (2.3 as of 01/17/03). It is available
2567 from \htmladdnormallink{http://netgroup-serv.polito.it/winpcap/}{http://netgroup-serv.polito.it/winpcap/}.
2568 It might also be an issue with SMP machines \myref{winpcap}.
2570 \subsection{Snort is not logging to my database}
2572 There are a number of problems that may be causing Snort to fail to log to a
2573 database. You should check these:
2574 \begin{enumerate}
2575 \item You did not set up the database plugin in your configuration file.
2576 \item You are using an older database schema, and should update it by running the create scripts from the ./schemas directory of the source tarball.
2577 \item You are using a command line option that overrides what you have in your configuration file. This is most often -A or -s. NOTE: If you wish to log to syslog as well, specify so in your configuration file rather then the command line.
2578 \item There is a problem with your database configuration itself. Make sure the user you specify has the correct permissions, or that the database is even up and running.
2579 \end{enumerate}
2581 \subsection{Portscans are not being logged to my database }
2583 You need to change the output facility to 'alert' rather then 'log'. The
2584 portscan preprocessor calls output plugins registered as 'alert' plugins
2585 rather then 'log'.
2587 \begin{verbatim}output database: alert, mysql, user=snort dbname=snort host=localhost\end{verbatim}
2589 \subsection{Snort is not logging to syslog}
2591 There are a number of problems that may be causing snort to fail to log to syslog. You should check these:
2592 \begin{itemize}
2593 \item You are using a command line option that overrides what you have in your configuration file. This is most often -A.
2594 \item It may be logging to the wrong place. Make sure syslog is configured correctly.
2595 \end{itemize}
2598 \subsection{I am still getting bombarded with spp\_portscan messages even though the IP that I am getting the portscan from is in my \$DNS\_SERVERs var }
2600 Try adding /32 netmasks to those addresses:
2602 \begin{verbatim}var DNS_SERVERS \[xxx.xx.0.3/32,xxx.xxx.0.2/32\]\end{verbatim}
2604 And make sure the \$DNS\_SERVERS variable is on the portscan-ignorehosts line:
2606 \begin{verbatim}preprocessor portscan-ignorehosts: $DNS_SERVERS\end{verbatim}
2608 \subsection{Why does chrooted Snort die when I send it a SIGHUP? \label{chroot}}
2610 It's a known problem with permissions. Workaround, restart snort instead.
2612 But the short answer is this: Due to the way the execv(2) call works, it
2613 "Restarts" snort from scratch. This has the odd side effect of making
2614 HUPS to a chrooted snort become recursive. For example, chroot to /snort.
2615 It now sees /snort as / . Now HUP snort. Snort now expects to have
2616 /snort/snort as /. In other words, you have to re-create your directories
2617 for your jail inside it. 4 HUPS and you will be in
2618 /snort/snort/snort/snort.
2620 \subsection{My snort crashes, how do I restart it?}
2622 Try one of these two shell scripts or daemontools (refer to website to
2623 daemontools)
2625 \begin{verbatim}
2626 * []#!/bin/sh
2627 #snorthup: Snort Restarter and Crash Logger
2628 #(dr@kyx..net with help from kmaxwell@superpages.com)
2630 $conf = "snort.conf"
2631 for $IFACE in fxp0 fxp1
2633 if [ -f /var/run/snort_$IFACE.pid ]; then
2634 if ! ps -p `cat /var/run/snort_$IFACE.pid` > /dev/null ; then
2635 /usr/bin/logger -p user.notice snorthup: removing bogus pidfile
2636 /usr/bin/
2637 logger -p user.notice snorthup: restarting absentee snort o
2638 n $IFACE with conf file $i
2639 rm -f /var/run/snort_$IFACE.pid
2640 /usr/local/bin/snort -D -c $conf -i $IFACE
2642 else
2643 /usr/bin/
2644 logger -p user.notice snorthup: restarting snort on $IFACE with
2645 conf file $conf
2646 /usr/local/bin/snort -D -c $conf -i $IFACE
2648 done
2649 \end{verbatim}
2650 Another version:
2651 \begin{verbatim}
2652 * []#!/bin/ksh
2653 # snortstartd: Snort (Re)Starter
2654 # Dom De Vitto (dom@devitto..com)
2655 # (original idea by dr@kyx..net & kmaxwell@superpages.com)
2657 # Note: You'd better get CONF and INTERFACES right or
2658 # this script will just keep trying to start snort.
2659 # Path to echo, sed, test, ps, grep, logger, rm, and sleep.
2661 PATH=$PATH:/usr/bin:/usr/local/bin ; export PATH
2663 # Point this to your conf file:
2665 CONF="/usr/local/share/examples/snort/snort.conf"
2667 # Which interfaces should Snort run on, e.g.:
2669 INTERFACES="hme0 hme1"
2671 # Wait this many seconds between checks:
2673 CHECKEVERY=5
2675 # Full path to Snort:
2677 SNORTBINARY=/usr/local/bin/snort
2679 while :; do
2680 for INT in $INTERFACES
2682 GREPSTRING="`echo $SNORTBINARY -N -D -c $CONF -i $INT|sed
2683 's?\/?\\\/?g'`"
2684 PSCMDLINES=`(ps augxww 2>/dev/null||ps -ef 2>/dev/null) | grep
2685 "$GREPSTRING"|wc -l`
2686 if [ $PSCMDLINES = 0 ]; then
2687 logger -p user.notice -t "$0" "Starting Snort on $INT."
2688 $SNORTBINARY -N -D -c $CONF -i $INT 2>&1 > /dev/null
2690 done
2691 sleep $CHECKEVERY
2692 done
2693 \end{verbatim}
2695 \subsection{Why can't snort see one of the 10Mbps or 100Mbps traffic on my autoswitch hub?}
2697 Basically it's a function of the design and all autoswitching hubs will
2698 behave in this way. It's the result of just not being able to stuff all
2699 the 100 Mbps traffic into the 10Mbps CSMA/CD. One solution I use to the
2700 problem is these new cheapie four port switches... put all the 10Mbps on
2701 it's own hub/switch/whatever and then route that to the 100Mbps hub I use
2702 for monitoring but put a cheapie switch in between that works as an
2703 adapter basically mediating the 10 up to 100 and vice versa.
2706 The bad thing about hubs that {\em don't} have this ``feature,'' is that
2707 in order to support 10bt devices, they throttle the entire hub speed
2708 down to 10bt if there is one or more 10bt only devices hooked up to it.
2709 I have seen this behavior (and did the bandwidth tests to proove it) on
2710 old 3com office connect 10/100 hubs (newer ones do the 2 hubs with a switch
2711 thing.) So, the point of what I am saying is, since these old hubs have
2712 no switching capabilities, and they don't know which port the traffic is
2713 supposed to go to (no switch=no arp table), they have to throttle bandwidth.
2715 None of the hubs and switches have any significant amount of storage
2716 on the ethernet chip sets, and therefore {\em any} non-layer-three box that
2717 has 100 $->$ 10 capability can only handle small amounts of traffic before
2718 the chip set drops incoming packets on the floor. Guess one might call
2719 that throttled bandwidth, but at the expense of retransmission timeouts
2720 and retransmissions at the end nodes.
2722 If the box has a backplane, multiple cards and some network management
2723 functions, there is a higher {\em probability} the manufacturer has some
2724 additional buffering going on to keep dropped packets from happening
2725 on at least small bursts of traffic.
2727 In the most generic of terms, if a box supports 100 ``full-duplex,'' then
2728 its a switch (regardless of what the manufacturer calls it). If it
2729 supports 100 $->$ 10, there is 50-50 chance the box has some MAC address
2730 awareness. If a box only supports 10 $->$ 10 or 100 $->$ 100, there is a
2731 high probability it is not MAC address aware and therefore functions
2732 like a hub.
2734 Many hubs have different back planes, i.e., one for 10 and one for 100.
2736 >From a definition standpoint, a hub segment whether it be 10 or 100 is
2737 a single broadcast/collision domain. You will not see ANY traffic
2738 between segements without a bridge or layer3 route function between
2739 them.
2741 In a switched environment, typically each port is a separate collision
2742 domain but one big broadcast domain. VLANs can be created in some to
2743 separate into separate broadcast domains and some have built in layer
2744 3 functionality which basically connects a router into the backplane
2745 so that it can route between vlans at wire speed.
2747 Think of a switch as a bridge with many ports. (that's what it is).
2748 Some switches support port mirroring or span ports. When you want to
2749 ``sniff'' frames in a switched environment (beyond just
2750 broadcast/multicast traffic) you need to be able to "see" the unicast
2751 traffic (telnet,http for example). You set up a port to mirror
2752 traffic from the ports that have the devices your interested in to the
2753 port you have your analysis device plugged into. Without doing so,
2754 you don't see the unicast conversations because the traffic is getting
2755 "switched" accross the backplane so pc on port 1 talks to server on
2756 port 2 and no other ports get this traffic. If server on port 2
2757 broadcasts or multicasts, the information is flooded out all ports.
2758 (multicast can be controlled on some switches so only those ports that
2759 have listening stations get the traffic. Not all switches have these
2760 capabilities.
2762 An excellent book on the topic is Interconnections by Radia Perlman.
2763 (Bridges and Routers).
2765 Additional caveat: if you deal with full duplex on a switched port,
2766 only a tap would save you - users have succesfully used Shomiti's
2767 ones on 100MB FD ports, and used two Snort instances, capturing
2768 traffic on both directions. Port mirroring didn't work in that case ...
2770 \subsection{Trying to install snort it says: ``bad interpreter: No such file or
2771 directory''}
2773 Usually this error comes from editing files on Windows machines. Often it shows
2774 up on the ./configure step. The configure script should be looking for the /bin
2775 /sh shell as its interpreter. If /bin/sh doesn't exist then you'll get this
2776 error. Check that whatever comes after the \#! on the first line of configure is
2777 actually there.
2779 If the file has been edited on a Windows machine it can sometimes Add CR/LF
2780 (VM) characters on the end of each line, so \#!/bin/sh becomes \#!/bin/shVM and
2781 as the ctrl-v/ctrl-m characters are special, and hidden by default on most
2782 editors, it can create a really hard to find problem. To remove the extra CR
2783 characters that UNIXish machines don't like, simply use the dos2unix command:
2784 \begin{verbatim}
2785 * []dos2unix <infile> <outfile>
2786 \end{verbatim}
2787 If your OS doesn't have dos2unix, then you can use:
2788 \begin{verbatim}
2789 * []cat <infile> | tr -d ``\r'' > <outfile>
2790 \end{verbatim}
2792 \subsection{I'm not seeing any interfaces listed under Win32.}
2794 The reason you're seeing nothing in the interface list is a WinPcap problem. In
2795 previous versions of WinPcap there is a 1K buffer, which overflows if you have
2796 many interfaces (i.e., 10+). This has been replaced with an 8K buffer in more
2797 recent versions of WinPcap. The current snort distribution should already be
2798 linking against the newer WinPcap libraries, which should resolve this problem.
2799 Try obtaining a more recent build of snort.
2801 \subsection{It's not working on Win32, how can I tell if my problem is Snort or
2802 WinPcap?}
2804 See if WinDump will work with WinPcap. This should help you isolate which
2805 component is being bogus.
2807 \subsection{I just downloaded a new ruleset and now Snort fails, complaining about the
2808 rules.}
2810 First, make sure you downloaded the right ruleset for your version of snort.
2811 Snort.org generally hosts a ruleset for the released version of Snort, as well
2812 as rules for the development branch and sometimes copies for older versions of
2813 snort. This is generally the case for ``unknown keyword in rule'' type errors.
2815 If you have the rules that are correct for your version of snort be aware that
2816 the snort rules tarball contains a snort.conf file. From time to time the
2817 snort.conf included with the rules gets changed as new .rules files are added,
2818 and new variables are added to support a better ruleset. When downloading new
2819 rulesets you should always give the included snort.conf a quick look-over to
2820 see if new includes or vars have been added, or at least be aware you should
2821 consult it if things do not work as expected. This is generally the case if you
2822 get messages indicating that something is undefined in a rule.
2824 \subsection{Why am I seeing so many ``SMTP RCPT TO overflow'' alerts ?}
2826 That rule looks for a TCP frame going to your SMTP server which contains more
2827 than 800 bytes of data. Any email can easily set that off if pipelining is
2828 used. SMTP command pipelining allows several command lines lines to be sent as
2829 a single packet without waiting for an OK response. Any good high-volume
2830 mailserver will try to pipeline where possible, resulting in a single TCP frame
2831 containing a series of command lines, each of which is not very long, but in
2832 aggregate easily exceed the 800 byte threshold, particularly if there is a
2833 large recipient list.
2835 For more info on pipelining:
2837 \htmladdnormallink{http://www.faqs.org/rfcs/rfc1854.html}{http://www.faqs.org/rfcs/rfc1854.html}
2839 If your mailservers are not vulnerable to these overflows you can disable this
2840 rule and regain some peace...
2842 \subsection{I'm getting lots of *ICMP Ping Speedera*, is this bad?}
2844 Quite ordinary. Windows update uses speedera based DNS, among other things. Of
2845 course, if the speedera traffic is coming from a Dialup account (as there have
2846 been reports of) it's likely a hacker tool. ;-)
2848 \subsection{Why are my unified alert times off by +/- N hours?}
2850 Unified log and alert files are stored in UTC.
2852 \subsection{I try to start Snort and it gives an error like ``ERROR: Unable to open
2853 rules file: /root/.snortrc or /root//root/.snortrc.'' What can I do to fix this?}
2855 When Snort starts, it looks at the command line and checks for ``-c /some/path/
2856 snort.conf.'' If thats not there, then it will look for the one of the following
2857 files:
2859 \begin{itemize}
2860 \item /etc/snort.conf
2861 \item ./snort.conf
2862 \item \$HOMEDIR/snort.conf
2863 \item \$HOMEDIR/.snortrc
2864 \item ./.snortrc
2865 \end{itemize}
2867 Make sure your .conf is in one of those locations and then Snort will be able
2868 to find it or use the -c parameter to tell Snort the full pathname to the
2869 snort.conf.
2870 \begin{verbatim}
2871 snort -c /usr/local/etc/snort.conf
2872 \end{verbatim}
2874 \subsection{Snort fails to respond to a kill signal on Linux. Why?}
2876 In Snort 2.6, a change was made to switch from performing the Snort
2877 shutdown function within the signal handlers. This was done to remove
2878 reentrant code from the signal handlers, and the vulnerabilities that
2879 entailed. The signal handler now simply sets a flag and returns.
2881 Snort now uses pcap\_dispatch() with a read timeout value. So, when a
2882 signal is received when snort is waiting for packets, the signal handler
2883 sets the flag and goes back to waiting for a packet. If the timeout
2884 is then reached, pcap\_dispatch() returns and Snort sees it received a
2885 signal to exit and exits cleanly.
2887 Per the pcap(3) man page, ``Not all platforms support a read timeout;
2888 on platforms that don't, the read timeout is ignored.'' Linux is one
2889 of the systems where this is not currently supported.
2891 Snort does receive the signal, but until a packet arrives, it does
2892 not get the chance to exit cleanly. There have been a number of
2893 patches created to implement the timeout on linux, and one example
2894 can be found here.
2896 \htmladdnormallink{http://www.ethereal.com/lists/ethereal-dev/199812/msg00019.html}{http://www.ethereal.com/lists/ethereal-dev/199812/msg00019.html}
2898 \subsection{A Rule with PCRE causes a failure to load snort.conf. Why?}
2900 Newer Snort rules are using PCRE named expressions (also known as
2901 named captures). PCRE only supports this with versions 4.0 and
2902 later, and if an earlier version of libpcre is being used, Snort will
2903 print the following error at startup.
2905 \begin{verbatim}
2906 unrecognized character after (?
2907 Fatal Error, Quitting..
2908 \end{verbatim}
2910 A rule that may cause this problem is shown.
2912 \begin{verbatim}
2913 alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT Microsoft
2914 Agent v1.5 ActiveX clsid access"; flow:established,to_client;
2915 content:"F5BE8BD2-7DE6-11D0-91FE-00C04FD701A5"; nocase;
2916 pcre:"/<object\s*[^>]*\s*classid\s*=\s*(?P<q1>\x22|\x27|)\s*clsid\s*\x3a\s*
2917 {?\s*F5BE8BD2-7DE6-11D0-91FE-00C04FD701A5\s*}?\s*(?P=q1)(\s|>)/si";
2918 reference:cve,2005-1214; reference:cve,2006-3445; reference:cve,2007-1205;
2919 reference:url,www.microsoft.com/technet/security/bulletin/MS05-032.mspx;
2920 reference:url,www.microsoft.com/technet/security/bulletin/MS06-068.mspx;
2921 reference:url,www.microsoft.com/technet/security/bulletin/MS07-020.mspx;
2922 classtype:attempted-user; sid:4172; rev:3;)
2923 \end{verbatim}
2925 As of Snort 2.7.0, the minimum version of libpcre is 4.0. Because of
2926 various performance improvements and bug fixes within libpcre, it is
2927 recommended that Snort be compiled with libpcre version 7.0 or later.
2928 Visit \htmladdnormallink{http://www.pcre.org}{http://www.pcre.org} for
2929 details.
2931 \section{Development}
2934 \subsection{How do you put Snort in debug mode? }
2936 In Snort 1.9 or higher,
2938 \begin{enumerate}
2940 \item ./configure --enable-debug
2942 \item Look up the sections of Snort you'd like to debug ( look at src/snort\_debug.h )
2943 and bitwise-or the flags together to create a hex value.
2945 For example,
2946 \begin{verbatim}
2947 #define DEBUG_PARSER 0x00000002
2949 #define DEBUG_PATTERN_MATCH 0x00001000
2950 \end{verbatim}
2952 To debug just the parser:
2953 \begin{verbatim}
2954 export SNORT_DEBUG=0x2
2955 \end{verbatim}
2957 To debug both the parser and pattern matcher:
2958 \begin{verbatim}
2959 export SNORT_DEBUG=0x1002
2960 \end{verbatim}
2962 Debugging preprocessors is similar, eg to debug frag3:
2963 \begin{verbatim}
2964 export SNORT_PP_DEBUG=0x1
2965 \end{verbatim}
2967 \item Run snort as normal. You will need to redirect output to a file
2968 to cope with the large amounts of debug output.
2969 \end{enumerate}
2971 \section{Miscellaneous}
2972 \subsection{What's this about a Snort drinking game?}
2974 :-) Check it out for yourself:
2975 \htmladdnormallink{http://www.theadamsfamily.net/~erek/snort/drinking\_game.txt}{http://www.theadamsfamily.net/~erek/snort/drinking_game.txt}
2978 %\begin{thebibliography}
2979 %\bibitem[cite74]
2980 %\end{thebibliography}
2982 \end{document}