![]() |
![]()
| ![]() |
![]()
NAMEflow-dscan — Detect scanning and other suspicious network activity. SYNOPSISflow-dscan [-bBhlmpwW] [-d debug_level] [-D iplist_depth] [-s state_file] [-i input_filter] [-L suppress_list] [-o output_filter] [-O excessive_octets] [-P excessive_flows] [-S port_scan_trigger] [-t ager_timeout] DESCRIPTIONThe flow-dscan utility is used to detect suspicious activity such as port scanning, host scanning, and flows with unusually high octets or packets. A source and destination suppress list is supported to help prevent false alarms due to hosts such as nameservers or popular web servers that exchange traffic with a large number of hosts. Alarms are logged to syslog or stderr. The internal state of flow-dscan can be saved and loaded to allow for interrupted operation. flow-dscan will work best if configured to only watch only inbound or outbound traffic by using the input or output interface filter option. The host scanner works by counting the length of the destination IP hash chain. If it goes above 64, then the src is considered to be scanning. The port scanner works by keeping a bitmap of the destination port number < 1024 per destination IP. If it goes above 64, the src is considered to be port scanning the destination. When a src has been flagged as scanning it will not be reported again until the record is aged out and enough flows trigger it again. A SIGHUP signal will instruct flow-dscan to reload the suppress list. A SIGUSR1 signal will instruct flow-dscan to dump its internal state. OPTIONS
EXAMPLESIn a topology where 25 is the only output interface run flow-dscan over the data in /flows/krc4. Ignore www and multicast traffic, store the internal state in dscan.statefile on exit. Use empty suppress list files dscan.suppress.src and dscan.suppress.dst. The output produced by flow-dscan typically must be manually inspected by using flow-filter and flow-print. Many of the alerts will be false until the suppress lists are populated for the local environment.
BUGSThe ager should automatically become more aggressive when a low memory condition exists. There is no upper limit on the number of records that can be allocated. If the ager is not running often enough the host will be run out of memory. AUTHORMark Fullmer maf@splintered.net SEE ALSOflow-tools(1)
|