UTSA IS 3523 ID & Incident Response SNORT Snort is a packet sniffer on steroids. Can be placed at different points in a network to provide real time information. By logging alerts and rule violations, a systems administrator can be mindful of attacks in progress or research past incidents.
UTSA IS 3523 ID & Incident Response Snort Usage Run from the command line or as a Windows Service. Lots of options
UTSA IS 3523 ID & Incident Response Snort Options USAGE: snort [-options] snort /SERVICE /INSTALL [-options] snort /SERVICE /UNINSTALL snort /SERVICE /SHOW Options: -A Set alert mode: fast, full, console, or none (alert file alerts only) -b Log packets in tcpdump format (much faster!) -c Use Rules File -C Print out payloads with character data only (no hex) -d Dump the Application Layer -e Display the second layer header info -E Log alert messages to NT Eventlog. (Win32 only) -f Turn off fflush() calls after binary log writes -F Read BPF filters from file -h Home network = -i Listen on interface -I Add Interface name to alert output -k Checksum mode (all,noip,notcp,noudp,noicmp,none) -l Log to directory
UTSA IS 3523 ID & Incident Response More Snort Options -L Log to this tcpdump file -n Exit after receiving packets -N Turn off logging (alerts still work) -o Change the rule testing order to Pass|Alert|Log -O Obfuscate the logged IP addresses -p Disable promiscuous mode sniffing -P Set explicit snaplen of packet (default: 1514) -q Quiet. Don't show banner and status report -r Read and process tcpdump file -R Include 'id' in snort_intf.pid file name -s Log alert messages to syslog -S Set rules file variable n equal to value v -T Test and report on the current Snort configuration -U Use UTC for timestamps -v Be verbose -V Show version number -W Lists available interfaces. (Win32 only) -w Dump 802.11 management and control frames -X Dump the raw packet data starting at the link layer -y Include year in timestamp in the alert and log files -z Set assurance mode, match on established sesions (for TCP) -? Show this information are standard BPF options, as seen in TCPDump
UTSA IS 3523 ID & Incident Response Snort in Action
UTSA IS 3523 ID & Incident Response Observations of Snort - Good FREE! Large user base Community provides constant rule updates Free tools to provide log analysis and email/pager alerts
UTSA IS 3523 ID & Incident Response Observations of Snort - Bad UNIX tool ported to Windows; behaves like a UNIX tool –Difficult to configure Cryptic command line driven interface All configuration is driven by files Lacks standardized support
UTSA IS 3523 ID & Incident Response How ACID Supports SNORT ACID helps to make sense of Snort data in a visual manner. Can help analyze trends and help filter out the noise by categorizing attacks and IP addresses. Query-builder and search interface. Can provide alerts when events occur.
UTSA IS 3523 ID & Incident Response ACID Usage Acid runs as a set of PHP (PHP: Hypertext Preprocessor) web pages under IIS or Apache Reports, alerts, and information is accessed through the web interface
UTSA IS 3523 ID & Incident Response Observations of ACID - Good FREE! Nice graphical interface written in PHP, therefore user community to rely on. Free tools to provide log analysis and email/pager alerts. Helps sort through all the info from Snort.
UTSA IS 3523 ID & Incident Response Observations of ACID - ACID Lacks standardized support Lots of options to become familiar with
UTSA IS 3523 ID & Incident Response SourceFire—Commercial SNORT
UTSA IS 3523 ID & Incident Response SourceFire—GUI
UTSA IS 3523 ID & Incident Response World’s leading voice network security company. Secures & better manages enterprise voice networks (TDM, VoIP, or Hybrid) – close phone line backdoors into data networks. Established in 1998 by WheelGroup Flagship product: The ETM ® (Enterprise Telephony Management) System PSTN IDS&Enterprise Manager
UTSA IS 3523 ID & Incident Response IDS evaluation (from Network Computing 8.20.2001)
UTSA IS 3523 ID & Incident Response IDS evaluation (integrated) (from Network Computing 8.20.2001)
UTSA IS 3523 ID & Incident Response IDS evaluation (host based) (from Network Computing 8.20.2001)
UTSA IS 3523 ID & Incident Response IDS evaluation (signatures) (from Network Computing 8.20.2001)
UTSA IS 3523 ID & Incident Response Centralized IDS Hierarchy... Central Director All Business Offices Corporate
UTSA IS 3523 ID & Incident Response Partially Distributed IDS Hierarchy... Lower Domain Intermediate Domain Upper Domain Central Director Business Offices Intermediate Director Intermediate Director Intermediate Director Intermediate Director Regional Offices Corporate
UTSA IS 3523 ID & Incident Response Fully Distributed IDS Hierarchy... Lower Domain Intermediate Domain Upper Domain Central Director Business Offices Intermediate Director Intermediate Director Intermediate Director Intermediate Director Regional Offices Corporate
UTSA IS 3523 ID & Incident Response Discussion on current IDS How are signature updates accomplished? How often are signatures updated? How many are there? What is the maximum bandwidth the IDS can monitor? What network protocols can be monitored? What OS platforms does the IDS work on? Does the IDS platform interact with other devices (e.g. firewalls, routers…)? What type of reporting tools are available? How is the security manager notified of events? Host or network based? Enterprise deployable? What training is required to operate and how much time does it take to operate the IDS?
UTSA IS 3523 ID & Incident Response 50 ways to defeat an IDS 1 - Inserting extraneous characters into a standard attack typically causes detection failure. As an example, you could insert the string ‘&& true’ into a typical shell command line without ill effect on operation but with degraded IDS performance. 2 - Use tabs instead of spaces in commands. Since most current systems don’t interpret all separators in the same way, changing to non-standard separators can make them fail. You might also try ‘,’ instead of ‘;’ in the Unix shell. 3 – Closely related to number 2, you could change the separator character in the system so that (for example) % is the separator. This would confuse detection systems almost without exception. 4 - Reorder a detected attack sequence. For example, if the attack goes ‘a;b;c’ and it would also work as ‘b;a;c’, most detection systems would rank the one they were not tuned to find as unlikely to be an actual attack. 5 - Split a standard attack across more than one user. Using the ‘a;b;c’ example above, if user X types ‘a;b’ and user Y types ‘c’ the attack is almost certain to go undetected. 6 - Split a standard attack across multiple sessions. Login once and type ‘a;b’, logout, then login and type ‘c’. –From 50 Ways to Defeat Your Intrusion Detection System by Fred Cohen of Fred Cohen & Associates
UTSA IS 3523 ID & Incident Response 50 ways to defeat an IDS 7 - Split across multiple remote IP addresses/systems. Login from sites X and Y, and type ‘a’ from site X, ‘b’ from site Y, and ‘c’ from site X. 8 - Define a macro for a command used in a standard attack. For example, set a shell variable called ‘$ZZ’ to ‘cp’ and then use ‘$ZZ’ instead of ‘cp’ where appropriate. 9 - Define a macro for a parameter in a standard attack. For example, use the name ‘$P’ instead of the string ‘/etc/passwd’. 10 – Create shell scripts to replace commands you use. If you do this carefully, the detector will not associate the names you use for the scripts to the commands and will miss the whole attack. 11 - Use different commands to do the same function. For example, ‘echo *’ is almost the same as ‘ls’ in the Unix shell. 12 - Change the names in standard attacks. For example, if the standard attack uses a temporary file named ‘xxx’, try using ‘yyy’.
UTSA IS 3523 ID & Incident Response 50 ways to defeat an IDS 15 - Encrypt your attacks – for example, by using the secure shell facilities intended to increase protection by preventing snooping – including snooping by the IDS. 21 - Overwhelm the IDS sensor ports. For example, by using an echo virus against a UDP port, you might make the sensor port unable to receive further sensor inputs. 22 - Crash the IDS with ping packets. By sending long IPNG packets, many systems that run IDS systems can be crashed, causing them to fail to detect subsequent attacks. 23 – Kill the IDS by attacking its platform. Most IDS systems run on regular hosts which can themselves be attacked. Once the platform is taken over, the IDS can be subverted. 25 - Consume all IDS disk space then launch for real. By (for example) overrunning the disk space consumed by the IDS with innocuous but detected sequences, the IDS will fail and subsequent attacks go undetected. 41 - Attack over dial-ins instead of a network. Network-based IDS systems will never notice this activity.
UTSA IS 3523 ID & Incident Response Summary Commercial IDS doing well, but thinning IDS Evaluations conducted regularly Centralized vs Decentralized management IDS can be defeated or circumvented