Frequently Asked Questions¶
Q. Suricata is not alerting on attacks against TCP sessions and/or the http.log is not showing all requests.¶
A. This might be an issue of packets with broken TCP checksums. To check this, "tail" your stats.log (in /var/log/suricata by default) like this:
tail -f /var/log/suricata/stats.log | grep "tcp.invalid_checksum"
Many network interfaces perform checksum offloading nowadays, causing Suricata to see invalid checksums. This behavior of the NIC can be disabled using "ethtool" on Linux. Alternatively, in Suricata you can disable the checksum validation by setting the "stream.checksum_valdation" to "no". See the suricata.yaml documentation.
Also, an additional discussion of the issue is at #311.
Q. fast.log, http.log or another line based log grows out of control, what to do?¶
A. The best way is to use a form of log rotation. The OS almost certainly provides a log rotation infrastructure. See "man logrotate" and Log Rotation.
cp http.log http.log.1 && > http.log
Replaces http.log with an empty file, without the need for a restart. The http.log.1 file contains the old log entries and can be archived or deleted depending on your needs.
Q. I found a problem in an older version of Suricata, what should I do?¶
A. Upgrade to the latest stable version. If the problem persists, please report it to us. See Reporting Bugs. If you're willing and able to try the latest dev version, you're our hero.
Q. The older version of Suricata comes with my distribution, what should I do?¶
A. Still upgrade to the latest version. If you can't, report the problem to your distribution.
Q. Suricata does not take my configuration variable into account, what should I do?¶
A. It is probably a formatting issue in your YAML configuration. You can get from suricata the result of configuration parsing. For that uses suricata -c CONF.YAML --dump-config and check if the variable is correctly set. If If it is the case, then please report a bug. If not, please check your file and specifically indentation of it.
Q. I have a single queue NIC like e1000e and stats.log reports many kernel_drops¶
A. If you are using AF_PACKET make sure the have set the cluster-type to cluster_flow. When cluster_flow is set, the kernel is delivering the packet on the different listening socket by doing a flow based load balancing. It computes a key corresponding to the flow tuple and deliver each packet with same key to the same socket. On Suricata side, one capture thread is dedicated to each socket and thus there is a load balancing on all CPUs due to this.
Q. I tried to run suricata as a specific user but got the "capng_change_id for main thread failed" error messsage!¶
A. You need the libcap-ng and your kernel needs to have CONFIG_SECURITY_FILE_CAPABILITIES set to YES.
Q. I get "Failure when trying to get feature via ioctl: Operation not permitted"?¶
A. This is fixed with 2.6.33 and newer kernels, it's still an issue in 2.6.32.
Q. Does the 32bit Windows installer work on 64bit Windows as well?¶
A. Yes, it runs in 32bit compatibility mode.
Q. How does suricata manage the deprecated threshold value within some ET rules in inline (IPS) mode?¶
A. It's using the same behaviour as snort, theat means it drops every packet not only the ones matching the threshold setting. The rules should be converted to detection_filter and event_filter.
Q. How does Automatic Protocol Detection work? Known bypasses? Issues? FP/FNs?¶
A. Patterns and/or 'probing parsers'. Both sides of the connection are evaluated and compared.
Q. Specifically for HTTP traffic - how does it determine the traffic is HTTP? Does a request have to be seen for the HTTP classification of the flow to happen or can it detect on just server response?¶
A. Patterns. Detection only on response also works.
Q. Can I match on 'http*' buffers on any port (assuming it is HTTP traffic?)_¶
A. Yes.
Q. Should I write rules looking for HTTP traffic as 'alert tcp any any -> any any' or 'alert http any any -> any any' or still use something like $HTTP_PORTS where appropriate for performance/memory reasons (more efficient rule groups)?¶
A. alert http or alert tcp with http_* keywords is enough. HTTP_PORTS is unnecessary.
Q. I know I can bypass Snort's HTTP Inspect http_client_body matching by setting multiple Content-Length headers.¶
A. In case of anomalies we set http events.
Q. Are pipelined HTTP request appropriately handled/reassembled (application layer)?¶
A. Yes.
Q. How are the http* buffers populated? e.g. Is http_method just the first word in the request packet before whitespace, URI the next word, and headers start after first CRLF?_¶
A. Parsed by libhtp, but in general yes.
Q. Is http_header just between the first CRLF and the next CRLFCRLF and the http*_body start after that?_¶
A. Individual headers are parsed by libhtp and for http_header reassembled into a buffer.
Q. How does parsing handle non-RFC compliant HTTP traffic that just uses LF instead of CRLF for separator?¶
A. Should work.
Q. 'alert http' vs 'alert tcp' - does 'alert http' affect protocol detection or is this just another check for rule matching?¶
A. Another check.
Q. When is 'alert http' appropriate and when is it not?¶
A. It's not strictly necessary when using http_* keywords, as they imply it. If goal is to limit non-http keyword matches to a http session, then it makes sense.
Q. Inspection depth. From the docs: "how much of the request/client body is inspected is controlled in your suricata.yaml, in the "libhtp" section, The request-body-limit setting.". Different limits for libhtp and non-http traffic? Which is one (e.g. htp) is smaller? Is the htp limit always enforced if the traffic is classified as HTTP regardless of ports and if it is 'alert http' or not?¶
A. Lowest limit will have precedence.
Q. Flowbits. Can a rule set a flowbit and another one check/alert on it for the same packet?¶
A. Yes.
Q. Alerting. Can you configure how many alerts get generated for each packet/reassembled stream/inspection window?¶
A. No.
Q. Reassembly. How is this affected by inspection depth? Is it a sliding window?¶
A. App layer is updated based on ACK'd data (IDS) or non-ACK'd data as it comes in (IPS). Raw content matches use a non-sliding window approach, with random limits.
Q. When does the reassembled data get flushed for inspection? ACK? RST and/or connection close (FINs)? Timeouts (different in inline mode?)? reassembly depth reached? Do packets get inspected individually AND part of a reassembled stream (assuming reassembly happens)¶
A. Depends on rule: some keywords force stream, others packet. If packet wasn't added to the stream engine, it's inspected directly. Check --engine-analysis
Q. Does Suricata have something like PAF to do intelligent application layer reassembly and flushing?¶
A. We have a similar approach for HTTP, but not for others yet.
Q. Gzip. Depth?¶
A. No specific settings. Controlled by body limits, stream depth.
Q. Do you have to call 'file_data' first to match on gzip decoded data?¶
A. Yes.
Q. fast_pattern.Is case sensitive but will it be case insensitive if 'nocase' is set on the content match used by the fast pattern matcher?¶
A. Yes.
Q. Can you use a negated content match as fast pattern?¶
A. Yes.
Q. fast_pattern:only¶
A. Not really implemented, 'only' silently ignored when encountered in a rule. Will be treated as 'fast_pattern;'.
Q. Limit to fast pattern string? truncation?Do fast pattern strings get truncated (e.g. 20 bytes)?¶
A. No.
Q. Can you enable truncation for fast pattern string?¶
A. No.
Q. Is there a performance reason to limit the length of fast pattern strings? (popular opinion is 'yes')¶
A. Needs case specific investigation.
Q. Are leading NULL bytes stripped out from fast pattern string like Snort?¶
A. No.
Q. Selection of fast pattern string when 'fast_pattern' is not explicitly set. Is it just longest content match?¶
A. Not entirely, we have a little algorithm trying to calc a 'strength' for the patterns. --engine-analysis dumps fast pattern info.
Q. Is there a selection priority (http buffers take precedence over regular content?)¶
A. It shouldn't be hard to test this with some rules and --engine-analysis
Q. Can you print out fast pattern string used by the Suricata engine (like Snort's '--print-debug-fast-pattern')?¶
A. Yes you can turn it on in yaml and run suricata with --engine-analysis
Q. What can and can't be used by the fast pattern matcher (e.g. in Snort you can't use 'http_raw*' buffers)?_¶
A. Can: all HTTP, DNS. Can't yet: tls buffers
Q. urilen - does it take into account proxy requests? e.g. the leading 'http://server.tld'.Can you tell it not to use the full proxy URI and just consider the data after the tld?¶
A. Per HTTP personality setting "uri-include-all". Documented in yaml.
Q. Can you use isdataat within http* buffers?_¶
A. Yes.
Q. TLS/SSL - not inspecting encrypted stream after handshake?¶
A. Inspecting records still, for heartbleed for example.
Q. http_user_agent. How is this populated? What if there is no space after 'User-Agent:' (e.g. 'User-Agent:RFC_Compliant'). What if 'user-agent:' is a lowercase?¶
A. It's normalized to handle that.
Q. How does dsize work with reassembly?¶
A. It doesn't. Sigs using dsize will inspect packet only.
Q. Does dsize only apply to individual packets?¶
A. Yes
Q. Can/does dsize apply to reassembled application layer PDU?¶
A. No.
Q. Does Suricata support byte_test, byte_jump, and/or byte_extract? Any simple math functionality? e.g. extract bytes X and Y and if X is greater than Y + 2 then alert¶
A. Yes
Q. Lua scripting. What Suricata version(s) support this?¶
A. All current.
Q. Lack of CRLF in http_user_agent and http_cookie buffers. Also CRLFCRLF at end of http_header buffer. HTTP Cookie header not in http_header buffer -- prevents detecting header ordering using http_header buffers for requests/responses that include position of Cookie header.¶
A. We mimic Snort here. http_raw_header does have it.
Q. Is it faster to match normalized buffer vs raw buffers vs just plain content matches?¶
A. More specific is generally better.
Q. Alert debugging - enabling debugging can be compiled in but what is the best way to troubleshoot a rule not firing? Can you see what pieces of the rule match/pass and at what specific point (e.g. which content match, dsize check, etc.) the rule gets identified as not matching?¶
A. Check alert-debug.log. Real debugging can be tricky.
Q. How does Suricata replay a pcap file through the engine when running with '-r' and a pcap file? Pseudo interface?¶
A. libpcap API has a method of reading files. We use this.
Q. Issues with asynchronous routing/sensor only seeing half of the traffic. Does a 3WHS have to be seen for the flow to be classified as "established"?¶
A. Depends on setting. We have async and midstream options. Both default to disabled.
Q. For flow, is 'client' set as the src of the first traffic seen or is it more intelligent (based off 3WHS)?¶
A. Normally first packet is considered to server. In midstream/async modes we can switch direction currently only for the SYN/ACK. In the future we may add more.
Q. IPS (inline) mode vs IDS mode.How is reassembly different?¶
A. We process unACK'd segments. If we forwarded a segment that is retransmitted with different data we normalize it to look like the original we passed.
Q. Do you have any good "cheat sheets" you can share?¶
A. This is the closest: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Self_Help_Diagrams
Q. Suricata doesn't like mixing packet and stream keywords e.g. 'dsize' and 'http_header'.¶
A. Correct. Dsize forces packet inspection, so can be bypassed easily for TCP data.
Q. I am running Suricata inline in AF-PACKET mode, reject and drop rules don't send tcp reset which result in slow browsing and client hanging.Does AF-packet mode support tcp reset?¶
A. The setup is done via the host-mode variable in suricata.yaml. If set to "router" then the reset packet is sent on the interface with a route to the IP. If set to "sniffer-only" then we use the reception interface to send the
reset packet. "auto" setting tries to do its best using "router" if mode is IPS and "sniffer-only" if not.
Q. Detect SYN flood¶
A. These sigs can be used to detect SYN floods as they happen, however they may have a high impact on CPU utilization on some systems.
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL DOS Unusually fast SYN packets inbound, Potential DOS"; flags: S,12; threshold: type both, track by_dst, count 5000, seconds 5; classtype:misc-activity; sid:5;)
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL DOS Unusually fast SYN packets outbound, Potential DOS"; flags: S,12; threshold: type both, track by_dst, count 5000, seconds 5; classtype:misc-activity; sid:6;)
Q. Identify top talkers¶
A. tcpdump -tnn -c 100000 -i eth2 | awk -F "." '{print $1"."$2"."$3"."$4}' | sort | uniq -c | sort -nr | awk ' $1 > 100 '
Q. Error opening file: "/etc/suricata/threshold.config"¶
A. This can either be fixed by creating an empty file with touch /etc/suricata/threshold.config or copying the one shipped with suricata
Q. Using Pcap capture with GRO or LRO activated can lead to capture problems¶
A. This means you have some network offloading active on your NIC, you should turn it off, for more details see NIC-offloading