Then run it with the HOME\_NET set appropriately for the networkyou're defending in your rules file.  A default rules file comes with thesnort distribution and is called ``snort.conf'' You can run this basic rulesetwith the following command line:\begin{verbatim}snort -A full -c snort.conf\end{verbatim}If it's all set right, make sure the interface is in promiscuous mode by running the command from another window:\begin{verbatim}ifconfig -a\end{verbatim}The output from ifconfig should show if the interface is in promiscuous mode.  If it's not, there should be a way to set it manually.Note that the default output mode (-A full) of Snort should not beused except in very controlled environments.  It is the slowest wayto run Snort and presents several hard to recover from problemswith inode creation on filesystems.For people doing real IDS work, use something like (-A fast -b) tocombine fast alert mode with tcpdump binary log files or use theunified format coupled with Barnyard.\subsection{Where are my log files located?  What are they named?}The default location for logs is /var/log/snort. If snort is started with ``-l$<$directory$>$'', then the logs will be located in the directory specified.In the past, running Snort in daemon mode (-D) produced a file named``snort.alert.'' For consistency's sake, this has been changed. Running Snort inboth standard or daemon modes (-D) will produce a file named ``alert.''Note the log file naming convention changed between 1.8 and 1.9. That funnyalphanumeric soup at the end of the new names is a UNIX timestamp. This helpsavoid file conflicts.\subsection{Why does Snort complain about /var/log/snort?}It requires this directory to log alerts to it. Try running the command:\begin{verbatim}    mkdir -p /var/log/snort\end{verbatim}Make sure the logging directory is owned by the user Snort is running as.\subsection{Where's a good place to physically put a Snort sensor?}This is going to be heavily influenced by your organizations policy, andwhat you want to detect.  One way of looking at it is determining if youwant to place it inside or outside your firewall.  Placing an IDS outsideof your firewall will allow you monitor all attacks directed at yournetwork, regardless of whether or not they are stopped at the firewall.This almost certainly means that the IDS will pick up on more eventsthan an IDS inside the firewall, and hence more logs will be generated.Place an IDS inside your firewall if you are only interested in monitoringtraffic that your firewall let pass.  If resources permit, it may be bestto place one IDS outside and one IDS inside of your firewall.  This wayyou can watch for everything directed at your network, and anything thatmade it's way in.ADDENDA AD NAUSEUMNote: So this one still gets a lot of traffic even though it's in the FAQ. ErekAdams has noted this comprehensive and authoritative discussion of thisperpetual discussion item---mildly edited, also see faq question about switcheshubs and taps -drIf your router/switch can do port mirroring, then just connecting a network IDSto it would be fine. Or else a hub could be another option. Most network IDSescan have a NIC that acts as a passive sniffer anyway.As to where to place the sensor. I would go for both, one to monitor theexternal, one for the internal. I work in a distributor for security products,so over instrumentation is fun :) And in any case, if the traffic does not passby the Sensor it will not get monitored. So some people deploy IDS on theirinternal segments too, I believe.{\bf In ``front'' of the firewall(s):}Pro: Higher state of alert you know what attacks you are facing.Con: Wall to Wall of data, boring? If your firewall has NAT turned on, trackingthe sources originating from your internal network is difficult.{\bf ``Behind'' the firewall(s):}Pro: Only what gets through the firewall gets monitored? Less load on the IDSanalyst. You get to see what hosts are sending traffic to the internet.Con: Less idea of the state of the environment, false sense of safety.{\bf Where should IDS be placed relative to firewalls? Explore the pros and cons ofplacing IDS inside or outside firewall. What are the drawbacks of each?}\begin{itemize}  \item {\bf MARCUS RANUM from NFR Security:} "I'd put mine inside. Why should I care if    someone is attacking the outside of my firewall? I care only if they    succeed, which my IDS on the inside would ideally detect. Placing the IDS    on the outside is going to quickly lull the administrator into complacency.    I used to have a highly instrumented firewall that alerted me whenever    someone attacked it. Two weeks later I was deleting its alert messages    without reading them. Another important factor arguing for putting it    inside is that not all intrusions come from the outside or the firewall. An    IDS on the inside might detect new network links appearing, or attackers    that got in via another avenue such as a dial-in bank.''      \item {\bf CURRY from IBM:} ``The IDS should be placed where it will be able to see as    much of the network traffic you're concerned about as possible. For    example, if you're concerned about attacks from the Internet, it makes the    most sense to put the IDS outside the firewall. the most sense to put the    IDS outside the firewall. This gives it an ``unobstructed'' view of    everything that's coming in. If you put the IDS inside the firewall, then    you're not seeing all the traffic the bad guys are sending at you, and this    may impact your ability to detect intrusions.''    \item {\bf SUTTERFIELD from Wheel Group:} ``IDS ideally plays an important role both    inside and outside a firewall. Outside a firewall, IDS watches legitimate    traffic going to public machines such as e-mail and Web servers. More    importantly IDS outside a firewall will see traffic that would typically be    blocked by a firewall and would remain undetected by an internal system.    This is especially important in detecting network sweeping which can be a    first indication of attack. External systems will also give you the benefit    of monitoring those services that firewalls determine are legitimate.    Putting an IDS inside the firewall offers the added benefit of being able    to watch traffic internal to the protected network. This adds an important    element of protection against insider threats. The major drawback of IDS    inside a firewall is that it cannot see a good deal of important traffic    coming from untrusted networks and may fail to alert on obvious signals of    an impending attack.''    \item {\bf CHRIS KLAUS from ISS:} ``Outside the firewall is almost always a good    idea---it protects the DMZ devices from attack and dedicates an additional    processor to protecting the internal network. Just inside the firewall is    also useful-it detects attempts to exploit the tunnels that exist through    the firewall and provides an excellent source of data for how well your    firewall is working. Throughout your intranet may be the best place for IDS    deployment, however. Everyone agrees that attacks aren't the only things    we're worried about-there's internal mischief, fraud, espionage, theft, and    general network misuse. Intrusion detection systems are just as effective    inside the network as outside, especially if they're unobtrusive and easy    to deploy.''    \item {\bf GENE SPAFFORD:} ``The IDS must be inside any firewalls to be able to detect    insider abuse and certain kinds of attacks through the firewall. IDS    outside the firewall may be useful if you want to monitor attacks on the    firewall, and to sample traffic that the firewall doesn't let through.    However, a true IDS system is likely to be wasted there unless you have    some follow-through on what you see.''        \vspace{10pt}   Bottom Line:{\bf DRAGOS RUIU:} ``Just pick a spot you're likely to look at the logs for. :-)''\end{itemize}\subsection{Libpcap complains about permissions problems, what's going on?}You are not running Snort as root or your kernel is not configured correctly.\subsection{ I've got RedHat and ....}Check your version of libpcap.  If it's not $>=$ 0.5, you should update.\subsection{Where do I get the latest version of libpcap? }You can find the most current version at:\htmladdnormallink{http://www.tcpdump.org}{http://www.tcpdump.org/}You might also want to have a look at Phil Wood's patches to libpcap for Linux:    \htmladdnormallink{http://public.lanl.gov/cpw/}{http://public.lanl.gov/cpw/}    \subsection{Where do I get the latest version of Winpcap?}	\htmladdnormallink{http://winpcap.polito.it/}{http://winpcap.polito.it/}\subsection{What version of Winpcap do I need?\label{winpcap}}It depends. If you only have one processor, you can use the most currentversion (3.x). If you have a SMP box, you'll have to use either an olderversion ($<$ 2.3) or the 3.x version plus a patch from \htmladdnormallink{http://www.ntop.org/winpcap.html}{http://www.ntop.org/winpcap.html}.\subsection{Why does building Snort complain about missing references? }You must configure libpcap with the --install-incl option.  (On Red Hat, install the libpcap-devel rpm.)\subsection{Why does building snort fail with errors about yylex and lex\_init? }You need the lex and yacc tools or their gnu equivalents flex and bison installed.\subsection{I want to build a Snort box.  Will this $<$Insert list of hardware$>$ handle $<$this much$>$ traffic? }That depends. Lower the number of rules is a standard performance increase.Disable rules that you don't need or care about. There have been manydiscussions on 'tweaking performance' with lots of 'I handle XX mb with a \_\_\_machine setup.' being said. Look at some of the discussions on the snort-usersmailing lists.Here is an oft quoted bit on the subject from Marty:``Hardware/OS recommendations''Ok, here are the guidelines and some parameters. Intrusion detection is turninginto one of the most high performance production computing fields that is inwide deployment today. If you think about the requirements of a NIDS sensor andthe constraints that they are required to operate within, you'll probably startto realize that it's not too hard to find the performance wall with a NIDSthese days.The things a NIDS needs are:\begin{enumerate}\item  MIPS (Fast CPU)\item  RAM (More is *always* better)\item  I/O (Wide, fast busses and high performance NIC)\item  AODS (Acres Of Disk Space)\end{enumerate}A NIDS also needs to be pretty quick internally at doing its job. Snort's seenbetter days in that regard (when 1.5 came out the architecture was a lotcleaner) but it's still considered to be one of the performance leadersavailable.As for OS selection, use what you like. When we implement Data AcquisitionPlugin's in Snort 2.0 this may become more of a factor, but for now I'm hearingabout a lot of people seeing alot of success using Snort on Solaris, Linux,*BSD and Windows 2000. Personally, I develop Snort on FreeBSD and Sourcefireuses OpenBSD for our sensor appliance OS, but I've been hearing some goodthings about the RedHat Turbo Packet interface (which would require mods forSnort to use, not to mention my general objection to RedHat's breaking stuffall the time). (ed note: take a drink, see FAQ 7.2 -dr)\subsection{What are CIDR netmasks? }(Excerpt from url: \htmladdnormallink{http://public.pacbell.net/dedicated/cidr.html}{http://public.pacbell.net/dedicated/cidr.html})CIDR is a new addressing scheme for the Internet which allows for more iefficient allocation of IP addresses than the old Class A, B, and C address scheme.\begin{center}\begin{tabular}{llr}{\bf CIDR Block} & {\bf Equivalent Class C} & {\bf Addresses}\\/27 & 1/8th of a Class C & 32 hosts \\/26 & 1/4th of a Class C & 64 hosts\\/25 & 1/2 of a Class C & 128 hosts\\/24 & 1 Class C & 256 hosts\\/23 & 2 Class C & 512 hosts\\/22 & 4 Class C & 1,024 hosts\\/21 & 8 Class C & 2,048 hosts\\/20 & 16 Class C & 4,096 hosts\\/19 & 32 Class C & 8,192 hosts\\/18 & 64 Class C & 16,384 hosts\\/17 & 128 Class C & 32,768 hosts\\/16 & 256 Class C & 65,536 hosts \\ /15 & 512 Class C & 131,072 hosts\\/14 & 1,024 Class C & 262,144 hosts\\/13 & 2,048 Class C & 524,288 hosts\\\end{tabular}\end{center}For more detailed technical information on CIDR, check out the following RFCs:\begin{itemize}\item RFC 1517: Applicability Statement for the Implementation of CIDR\item RFC 1518: An Architecture for IP Address Allocation with CIDR\item RFC 1519: CIDR: An Address Assignment and Aggregation Strategy\item RFC 1520: Exchanging Routing Information Across Provider Boundaries in the CIDR Environment\end{itemize}RFCs are available at \htmladdnormallink{http://www.rfc-editor.org/rfcsearch.html}{http://www.rfc-editor.org/rfcsearch.html}\subsection{What is the use of the ``-r'' switch to read tcpdump files?  }Used in conjunction with a Snort rules file, the tcpdump data can beanalyzed for hostile content, port scans, or anything else Snort can be used to detect.  Snort can also display the packets in a decoded format, which many people find is easier to read than native tcpdump output. \section{Configuring Snort}\subsection{How do I setup snort on a `stealth' interface? }\label{stealth}In *BSD and Linux:\begin{verbatim}ifconfig eth1 up\end{verbatim}Solaris:\begin{verbatim}ifconfig eth1 plumbifconfig eth1 up\end{verbatim}For NT/W2K/XP users, try the following:NOTE: You are at your own risk if you follow these instructions.  Editingyour registry is DANGEROUS and should be done with extreme caution.  Followthese steps at your OWN risk.\begin{enumerate}\item Get your device's hex value.  ('snort -W' works for this)\item open Regedt32\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\}\item Select the network card you wish to setup as the monitoring interface (this will be the \{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX\} value).\item Set IPAddress:REG\_MULTI\_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)\item Set SubnetMask:REG\_MULTI\_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)\item Set DefaultGateway:REG\_MULTI\_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)\item Close the Registry Editor, your changes will be saved automatically.\item In a command prompt, run 'ipconfig' to verify the interface does not have an IP bound to it.\end{enumerate}If you do not recieve an IP address listing from the interface youmodified, you are good to go.  To run snort with the specified interface,use the -i flag such as 'snort -v -d -p -i1' \subsection{How do I setup a receive-only ethernet cable?}Use an ethernet tap, or build your own 'receive-only' ethernet cable.Anyway, here is the cable I use: