Problem
How do I decode and normalize application traffic such as Telnet or rpc-encoded traffic so that the rules engine can analyze it?
Solution
Using the rpc_decode and telnet_decode decoders, Snort can decode the plain-text content inside of these applications.
The Telnet decoder has no options for you to set. This decoder takes the application encoding on Telnet (port 23/tcp), FTP (port 21/tcp), SMTP (25/tcp), and NNTP (119/tcp) connections then remove the application data and sends what's left back to the Snort engine for rules comparison of the plain-text content.
# enable this line in your snort.conf file Preprocessor telnet_decode
The rpc_decode decoder has more options and some ability to change its alerts.
You can select on which ports it should decode rpc traffic. For example, if you want to enable rpc_decode in your snort.conf file to decode only Unix SUNRPC traffic ports, use the following line:
preprocessor rpc_decode: 111 32771
If you also want to normalize Microsoft rpc traffic on port 135/tcp and detect when an rpc request is fragmented, add the extra port and the alert_fragmentation option. However, this combination can generate loads of traffic.
preprocessor rpc_decode: 111 32771 135 alert_fragmentation
A smarter solution would be to filter our rpc events. The following example filters out when more than one rpc message or query is in a single rpc packet stream.
Preprocessor rpc_decode: 111 32771 no_alert_multiple_requests
The no_alert_large_fragments option tells rpc_decode not to alert on fragmented queries when they are larger than a single packet.
Preprocessor rpc_decode: 111 32771 no_alert_large_fragments
Finally, the no_alert_incomplete option tells rpc_decode not to alert on rpc messages that span more than one stream. This can be helpful for handling large rpc queries.
Preprocessor rpc_decode: 111 32771 no_alert_incomplete
Discussion
Snort has the ability to decode and normalize certain application traffic. This plain-text data can then be passed back to Snort so the rules engine can analyze it. The Telnet and rpc preprocessors are not full-blown preprocessors, but just protocol decoders. There is very little to note other than the Telnet and rpc preprocessors are of the few components of the Snort engine that actually rewrite the packets into pseudopackets. This is actually true even in the new 2.2.0 version of Snort. As the packets are handed in raw form from the stream4_reassembly preprocessor, they are normalized and stripped of their actual payload. Then they are reassembled into plain-text representations of the actual payload data stream.
For further discussion of this issueor nonissue, depending on your network environmentcheck out the snort-devel mailing list archives of this building process.
See Also
Snort-devel mailing list
Beale, Jay. Snort 2.1 Intrusion Detection. Rockland, MA: Syngress, 2004.
Detecting Port Scans and Talkative Hosts |
Installing Snort from Source on Unix
Logging to a File Quickly
How to Build Rules
Detecting Stateless Attacks and Stream Reassembly
Managing Snort Sensors
Generating Statistical Output from Snort Logs
Monitoring Network Performance
Index