." snort_inline(8) June 26, 2005 .TH "snort_inline" 8 .SH NAME snort_inline \- A network intrustion prevention system based on snort .SH SYNOPSIS .B snort_inline <\-Q | \-J [divert_port]> ... .SH DESCRIPTION snort_inline is a modified version of Snort that processes packets directly from a firewall, versus reading from the raw ethernet layer. It interacts with the firewall by reading packets, and either dropping, rejecting, altering, or passing them onto your network based on your snort rules. .PP snort_inline is intended to run on a machine (router) between two networks. It will operate on packets traversing the two networks. That is, snort_inline requires packets to be "inline" with the network flow to make the proper decision. .PP snort_inline supports all options currently configured with snort, but adds two addtional flags, \-Q or \-J, depending on what platform snort_inline is running on. snort_inline currently supports two firewall types: Linux IPTABLES and FreeBSD IPFW. .SH OPTIONS .TP .B \-Q Process packets from Linux IPTables Queues. This option tells snort_inline to interact with the Linux IPTables Queues by reading packets from the queue, performing the necessary snort signature-based action, and informing IPTables what to do with the packet. .TP .B \-J [divert_port] Process packets from FreeBSD IPFW divert sockets. This option tells snort_inline to interact with FreeBSD IPFW using a divert socket. The optional \fIdivert_port\fP indicates which divert port to listen on. Default is 8000. It should be the same as your ipfw rule divert port. .SH "LINUX SETUP" .TP In order for you to use snort_inline with Linux, you must make sure the ip_queue module is loaded. If it is not loaded, you will see the error: "Failed to send netlink message: Connection refused". Either recompile your kernel to support ip_queue, or load the the module by executing: insmod ip_queue .SH "FREEBSD SETUP" .TP In order for you to use snort_inline with FreeBSD, you must compile your kernel with \fBoptions IPDIVERT\fP. This allows ipfw to send packets to snort_inline. For compiling instructions, see the handbook @ http://www.freebsd.org. .SH "RULES" .TP snort_inline uses the same rule semantics as the regular snort. However, a few new rule types have been created to trigger actions inside of snort_inline: .I drop The drop action tells the firewall to drop the packet without any form of response to the sender. The drop action is logged in the normal configured snort way. .I sdrop The sdrop action tells the firewall to drop the packet without any form of response to the sender. No log is generated by snort_inline. .I reject The reject action tells the firewall to drop the packet and tells snort_inline to send a rejects packet(s) to the sender. The reject packet(s) is either a TCP-Reset packet (if TCP) OR a ICMP-PORT-UNNREACHABLE (if UDP). In order for a TCP-reset packet to be sent, an IP address must be configured on an interface; otherwise the packet will never be sent. If you are operating in bridged mode on Linux, you can avoid having an IP on an interface by using layer2resets config option. .I reinject The reinject action tells snort_inline to reinject the matched packets back into the IPFW firewall at the rule number specified by the config option 'ipfw_reinject_rule'. This action only works if you are running FreeBSD IPFW snort_inline. .TP Additonally, content replacement has been added into snort_inline. The rule option \fIreplace\fP allows you to write rules that alter the content of the packet. The content being replaced MUST BE THE SAME SIZE as the replacement. See EXAMPLE RULES for further information. .PP Also, the current Rule application order within snort_inline is as follows: .nf ->activation->dynamic->drop->sdrop->reject->reinject->alert->pass->log .fi .SH "EXAMPLE RULES" .TP reject tcp any any -> $HOME_NET 80 (msg:"TCP port 80";) This rule will trigger on inbound traffic to port 80 (http). The inbound packets that trigger on this rule will be dropped by the firewall, logged via snort_inline, and a TCP reset packet(s) will be sent to the sender if this traffic. .TP drop tcp any any -> $HOME_NET 80 (msg:"TCP port 80";) This rule will trigger on inbound traffic to port 80 (http). The inbound packets that trigger on this rule will be dropped by the firewall and logged via snort_inline. .TP sdrop tcp any any -> $HOME_NET 80 (msg:"TCP port 80";) This rule will trigger on inbound traffic to port 80 (http). The inbound packets that trigger on this rule will be dropped by the firewall. No log entries will be created. .TP .nf alert udp any any <> any 53 (msg: "replace"; content: "yahoo"; replace: "xxxxx";) .fi This rule will trigger on traffic to port 53 (DNS). The payload of the packets that trigger on this rule will be inspected for the content yahoo and replaced with xxxxx. .SH "CONFIG OPTIONS" .TP .B config layer2resets[:MAC_ADDRESS] Tells snort_inline to use layer2 resets. If MAC_ADDRESS is not specified, the mac address of the bridge will be used as the source mac in the packet. If MAC_ADDRESS is specified, e.g. 00:06:76:DD:5F:E3 , then the reset will be sent with source mac = MAC_ADDRESS specified. layer2 resets are only for Linux IPTables snort_inline. .TP .B Stream4 additonal options: .IP enforce_state This option causes snort to drop TCP packets that are not associated with an existing TCP session, and is not a valid TCP initiator. If you enable this option it is adviced to increase the timeout to something like an hour (3600). .IP midstream_drop_alerts By default, when running in inline mode, snort will silently drop any packets that were picked up in midstream and would have caused an alert to be generated, if not for the 'flow: established' option. This is to mitigate stick/snot type attacks when the user hasn't enabled inline_state. If the user wants to see the alerts that are silently dropped, then enable this keyword. Note that by enabling this keyword, the user has opened themselves up to stick/snot type attacks. .IP stream4inline This forces stream4 to do packet reassembly on a sliding window, what this means is that we are doing reassembly in real-time, and no more of this postmortem uberpacket creation alert but can't drop non-sense. Be careful though we are performing session drops so this means that this option has to be used in conjunction with enforce_state to be effective otherwise what is the point. We are pretty sure we break the replace keyword with this one, so be careful. .TP .B stream4inline options include: .IP truncate Truncates a stream instead of flushing it. Use this for the sliding window. .IP truncate_percentage Set the percentage to cut off of the stream when we truncate (default 33). .IP window_size size in bytes of the sliding window (default: 7000). .SH "STICKYDROP PREPROCESSOR" STICKYDROP is a preprocessor plugin that provides the ability to drop attacker y for x number of seconds from a preproc like sfportscan. .TP .B STICKYDROP OPTIONS: .I max_entries X Maximum amount of attacker entries (X) allowed, to be stored in the splaytree. .I log [logfilename] Logs packets dropped by STICKYDROP to optional 'logfilename'. .TP .B STICKYDROP EXAMPLE: preprocessor stickydrop: max_entries 3000,log .TP .B STICKYDROP-TIMEOUTS: .I clamav X Time in the number of seconds (X) you want to block the source of a AV alert generated from the clamav preproc. .I portscan2 X Time in the number of seconds (X) you want to block a portscanner generated from the portscan2 preproc. .I sfportscan X Time in the number of seconds (X) you want to block a portscanner generated from the sfportscan preproc. .TP .B STICKYDROP-TIMEOUTS EXAMPLE: preprocessor stickydrop-timeouts: clamav 3000, portscan2 10000, sfportscan 100000 .TP .B STICKYDROP-IGNOREHOSTS: List of networks not to add to our block tree ever, you probably want to add your HOME _NET networks here as not to DoS yourself. .TP .B STICKYDROP-IGNOREHOSTS example: preprocessor stickydrop-ignorehosts: 192.168.1.0/24 .TP .B STICKYDROP usage The rule keyword option \fBsticky-drop\fP is used to tell snort_inline to apply stickydrop processing to the matched packets. The syntax is: .I sticky-drop:block_time,direction block_time refers to the amount of time to block in seconds and direction can be either \fBsrc\fP or \fBdst\fP. .TP .B STICKYDROP usage example: drop tcp any any -> any 80 (msg: "test"; sticky-drop: 600,src;) Tell snort_inline to apply sticky-drop to packets hitting port 80 in the source direction and to block for 600 seconds. .SH "LINUX STARTUP" In order for snort_inline to function with your iptables firewall, you must tell the firewall to ip_queue specific packets. The syntax for achieving this can be found in the IPTables reference manual. .PP An simple example: .TP .B iptables -A OUTPUT -p tcp --dport 80 -j QUEUE This tells iptables to QUEUE outbound TCP packets with destination port of 80. Once this command is given, snort_inline can now read the packet from the QUEUE for processing. .TP It is important to note that only one copy of snort_inline on LINUX can be running at a time do to the way the ip_queue module works. .TP Further examples can be found in online documentation and the snort_inline mailing lists. .SH "FREEBSD STARTUP" In order for snort_inline to function with your ipfw firewall, you must tell the firewall to forward packets through a divert port. The syntax for achieving this can be found in the \fBipfw(8)\fP man page. .PP An simple example: .TP .B ipfw add 1000 divert 8000 tcp from any to any 80 out This tells ipfw to send outbound TCP packets with destination port of 80 to divert socket 8000. snort_inline must be running with the command line option \fB-J 8000\fP to receive packets on divert port 8000. Once this command is given, snort_inline can now read the packet from the divert port 8000 for processing. .TP It is important to note that multiple copies of snort_inline on FreeBSD can be running at the same time , with different rulesets, processing different sets of packets on different divert ports. .TP Further examples can be found in online documentation and the snort_inline mailing lists. .SH "Additional Information" .TP .B Snort considerations Due to the fact that snort_inline is a modification of the snort IDS, further information on how to setup snort_inline can be retrieved by learning how to setup snort. Please see the snort documentation available at: http://www.snort.org .TP .B Snort Inline website Please visit http://www.snort-inline.org for further information such as news, Wiki, and FAQs. .TP .B README.INLINE file See the README.INLINE file located in the 'doc' directory of the distribution for futher information not covered in this manpage. Other helpful documents are located in the 'doc' directory as well. .TP .B DROP RULES Mike Clark has taken the time and energy to go through the snort ruleset to identify and consolidate rules that would meet the drop criteria. These rules are located in the rules directory in drop.rules, and should be considered "alpha". There is also a sample drop.conf file located in the etc directory of the snort_inline.tgz. The latest and greatest set of drop rules can always be found at: http://www.honeynet.org/papers/honeynet/tools/ Additionally, we have included a convert.sh script in the etc/ directory that will convert all alert rules to drop rules. All you have to do is copy it to the location of your snort rules and run it. It will convert all alert rules to drop rules; change HOME_NET to HONEYNET; and reverse the flow of the rules. Why reverse the flow of the rules? Because the original purpose of snort_inline is to control a compromised network; therefore, we need to drop packets leaving the Honeynet not entering it. .TP .B HONEYNET SNORT_INLINE TOOLKIT This is a statically compiled snort_inline binary put together by the Honeynet Project for the Linux Operating System. It comes with a set of drop.rules, the snort_inline binary, a snort-inline rotation shell script, and a good README. It can be found at: http://www.honeynet.org/papers/honeynet/tools/ .SH "CREDITS" William Metcalf , Victor Julien , Nick Rogness , Jed Haile , Rob McMillen .SH "SEE ALSO" \fBsnort\fP(8) .SH BUGS The stream4inline module can experience problems under certain network conditions and cause a fatal error.