Lesson 6
Commercial
Intrusion Detection Systems
Overview
• Common Commercial IDS
• IDS Evaluations
• Specialized IDS
UTSA IS 3523 ID & Incident Response
Common IDS Products
CISCO
Computer Associates
Enterasys Network
Internet Security Systems
Intrusion, Inc
Intruvert Networks
iPolicy Networks
NetScreen
NFR Security
Snort
Symantec Corp
TippingPoint Technologies
Tripwire Inc
UTSA IS 3523 ID & Incident Response
CISCO IDS (son of Netranger)
eTrust
Dragon
RealSecure
SecureNet,Secure Host
Intrushield
ipEnforcer
NetScreen IDP
Network Flight Recorder
Snort
Intruder Alert
UnityOne
Tripwire
Alert Screen
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] <filter options>
snort /SERVICE /INSTALL [-options] <filter 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<rules> Use Rules File <rules>
-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<bpf>
Read BPF filters from file <bpf>
-h<hn>
Home network = <hn>
-i <if>
Listen on interface <if>
-I
Add Interface name to alert output
-k<mode> Checksum mode (all,noip,notcp,noudp,noicmp,none)
-l <ld>
Log to directory <ld>
•
UTSA IS 3523 ID & Incident Response
More Snort Options
-L <file> Log to this tcpdump file
-n <cnt> Exit after receiving <cnt> 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 <snap> Set explicit snaplen of packet (default: 1514)
-q
Quiet. Don't show banner and status report
-r <tf>
Read and process tcpdump file <tf>
-R <id> Include 'id' in snort_intf<id>.pid file name
-s
Log alert messages to syslog
-S <n=v> 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
<Filter Options> are standard BPF options, as seen in TCPDump
UTSA IS 3523 ID & Incident Response
Snort in Action
UTSA IS 3523 ID & Incident Response
Snort Raw Output
Snort Logs – Better Information
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
ACID at Work
Alert Screen
Alert Screen – Graph
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
Emerging Open Source Products
• Bro the Network Security Monitor
• Developer: Vern Paxson
• https://www.bro.org/
• International Computer Science Institute, UC
Berkeley
• Yara
• The pattern matching swiss knife for
malware researchers
• http://plusvic.github.io/yara/
UTSA IS 3523 ID & Incident Response
Bro
• In-depth Analysis
•
Comes with analyzers for many protocols, enabling high-level semantic analysis at
the application layer
• Highly Stateful
• Keeps extensive application-layer state about the network it monitors
• Open Interfaces
•
Bro interfaces with other applications for real-time exchange of information
• Open Source
•
Bro comes with a BSD license, allowing for free use with virtually no restrictions
• Flexible
•
Bro is not restricted to any particular detection approach and does not rely on
traditional signatures.
• Forensics
•
Comprehensively logs what it sees and provides a high-level archive of a network's
activity.
• Commercially Supported –Broala.com
UTSA IS 3523 ID & Incident Response
TippingPoint IPS
•
•
•
•
Austin TX, 2002
Jan 2005: 3COM buys for $442M
2010 Hewlett-Packard (HP) – buys 3COM for $2.7B
Oct 2015, TrendMicro buys TP for $300M
SourceFire—Commercial SNORT
• Acquired by Cisco in 2015
• Rebranding??---Cisco FirePower Security Line
UTSA IS 3523 ID & Incident Response
SourceFire—GUI
UTSA IS 3523 ID & Incident Response
Bro Box One
•
•
•
•
•
•
Based on Bro 2.4.
Export to Kafka, Splunk, SFTP, Syslog
Four 1G/10G SFP+ interfaces.
Intuitive configuration.
Secure operation.
Automatic updates.
Coming: More integrations.
Coming: 40G/100G interfaces.
Coming: Stacking support.
UTSA IS 3523 ID & Incident Response
PSTN IDS&Enterprise Manager
• 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
UTSA IS 3523 ID & Incident Response
Gartner Tracking—a/o 2013
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
Corporate
Central
Director
All
Business
Offices
...
UTSA IS 3523 ID & Incident Response
Partially Distributed IDS Hierarchy
Upper
Domain
Corporate
Central
Director
Regional
Offices
Intermediate
Domain
Intermediate
Director
Intermediate
Director
Intermediate
Director
Intermediate
Director
Business
Offices
Lower
Domain
...
UTSA IS 3523 ID & Incident Response
Fully Distributed IDS Hierarchy
Upper
Domain
Corporate
Central
Director
Regional
Offices
Intermediate
Domain
Intermediate
Director
Intermediate
Director
Intermediate
Director
Intermediate
Director
Business
Offices
Lower
Domain
...
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
UTSA never
IS 3523 notice
ID & Incident
this Response
activity.
Summary
•
•
•
•
Commercial IDS doing well, but thinning
IDS Evaluations conducted regularly
Centralized vs Decentralized management
IDS can be defeated or circumvented
UTSA IS 3523 ID & Incident Response