Slightly Skeptical View on NIDS and
Network-level Intrusion Prevention

This page is devoted to network IDS (NIDS). Most NIDS are close relatives of virus scanners and share the same major problems (number of false positives; quality of signature database and timeliness of its updates, architectural weakness of the design, sloppy coding, obscure mini-languages and/or interfaces, etc).

All-in all network IDSs are probably the most over-hyped and the least useful category of IDS. Moreover the author maintains  the view that off the shelf commercial IDS boxes with closed signature sets represent a pretty typical incarnation of cargo cult science. They are toys rather than real tools. The return on investment on a typical signature based NIDS appliance in case of using closed (or even open but generic) signatures is asymptotically close to zero.

Network IDS (NIDS) is what most people understand  under acronym "IDS". They are almost synonymous with the word "IDS" . But actually they are the least useful members of IDS family. Network IDS can help only if and only if they are frequently tuned (and not pretended to be tuned as is the case of  "universal' signature updates typical for NIDS providers like ISS) and reconciled with other tools (host-based integrity checkers are probably the most important secondary source of info).  Usability of NIDS directly depends of positioning of the sensors (the less traffic they need to analyze the better are chances to distinguish signal from noise as well as the amount of efforts spend on customizing signatures (rather expensive activity that needs to be reconciled with the period "generic" upgrades of the ruleset).

The problem of distinguishing a signal from noise is a classical problem of NIDS.  NIDS operate on a very low level (Internet layer level) and all they see are raw packets. That means that they re better suited for detection of the low level (internet layer and transport layer) attacks. For the attacks occurring on higher level (level of application protocols) NIDS events the stream needs to be reconstructed and results of detection need to be correlated with events from  HIDS and log analyzers using ESM systems like Tivoli. But most NIDS are sitting between two chairs: they try to reconstruct the stream but at the same time they are sold as "real time" detection. the results of such dilemmas and related "premature optimization" is weak, contradictive architecture with multiple "ad-hoc" mini languages as we can see in Snort.

Isolated "universal" IDS with standard signature database managed by subscription (especially expensive network IDS appliances) typically are circulating air and the only positive thing about them is that they do not lead to the deterioration of the reliability of the network infrastructure like many other useless security solutions do (although they might provide a good target for attacks as ISS appliances proved more then once).

Taking into account amount of snake oil in major IDS vendors marketing (ISS is a nice example) as well as typical cost of appliances it makes sense to look for open source solutions. They might not provide too much useful information out of the box (in this sense they are not that dissimilar from their commercial counterparts; both mostly circulate air), but they are tunable and in any case you do not need to foot the bill either and while doing politically correct thing (technology-wise) can restrict the spending to the signature subscription service (less then $2K per year for Snort). 

Without customarization after the initial deployment the dreamland of network intrusion detection you either face absence of signals or bunch of false alarms. In the latter case honest approach does not work: you need to slack.

Hundreds of log entries per day, periodic useless vulnerability alarms, IDS alerts start to interfere with your normal duties without providing much return on the investment. You're suddenly faced with an entirely new set of questions, the primary one being, how to stop information overload.

For some unknown to me reason the whole industry became pretty rotten selling mostly hype and FUD. Still I need to admit that FUD sells well. The total size of the world market for network IDS is probably several hundred millions dollars and this market niche is occupied by a lot of snake oil salesmen:

Synergy Research Group reported that the worldwide network security market spending continued to be over the $1 billion in the fourth quarter of 2005, in all segments -- hybrid solutions (firewall/VPN, appliances, and hybrid software solutions), Intrusion Detection/Prevention Systems (IDS/IPS), and SSL VPN.

IDS/IPS sales increased seven percent for the quarter and were up 30 percent over 2004. Read article here.

Most money spent on IDS can be spend with much greater return on investment on ESM software as well as on improving rules in existing ( or installing additional) firewalls, log analyses and host based integrity checking.

That means that network IDS area is a natural area where open source software is more competitive then any commercial software. Simplifying we can even state that the fact of acquisition of commercial IDS by any organization can be a sign or weak or incompetent management ( although reality is more complex and sometimes such an acquisition is just a reaction on pressures outside IT like compliances-related pressures; moreover some implementations were done under the premises of "loss leader" mentality under the motto "let those jerks who want it have this sucker" ).

Actually an organization that is spending money on NIDS without first creating a solid foundation by deploying ESM commits what is called "innocent fraud" ;-). It does not matter what traffic you detect if you do not understand what exactly happening on your servers/workstations and view your traffic as an unstructured stream, a pond out of which IDS magically fish alerts. In reality as most time IDS is crying wolf even few useful alerts are buried in the noise. Also "real time" that is selling point for IDS does not really matter: most organization have no possibility to react promptly on alerts even if we assume that there are (very rare) cases when NIDS pick up useful signal instead on noise.  

A good introduction to NIDS can be found at NIST Draft Special Publication 800-94, Guide to Intrusion Detection and Prevention (IDP) Systems (Adobe PDF (2,333 KB) Zipped PDF (1,844 KB) )

A typical network IDS (NIDS) uses network card(s) in promiscuous mode, sniffing all packets on each network segment the server is connected to. Installations usually consists of several sensors and a central console to aggregate and analyze data (for example Snort can be used as a sensor and Acid as central console). NIDS can be classified into several types:

• A pure network IDS (NIDS) just watch the traffic. This is the most common type NIDS today and the least harmful. May be that's why they are the most widespread :-). Snort is a good example of basic functionality provided.  Shadow is an example more elaborate (and more complex) approach that instead of ad-hoc rules language uses the power of scripting language (Perl) for processing of packets.  Usefulness strongly depends of placement and tuning.  If pure NIDS is listening to large and complex network segment, then typically the useful signal is so buried in noise that the most NIDS are constantly "crying wolf" (producing so called 'security spam" stream of mail alerts) and after short honeymoon after the installation are completely ignored; so their value is totally symbolic: organization have it as a politically correct part of infrastructure so that (often semi-ignorant) vice president of IS can report to absolutely ignorant corporate board about the major success in securing the corporate network. Usefulness strongly depends on the subtype deployed. There are three major subtypes:
  • Signature-based NIDS. Those depends on signatures to detect vulnerabilities. This is typical approach used in rulebase for ISS and Snort (Snort can be used in different ways too) and all IDS most IDS appliances.
  • Policy/traffic rules violation detection. This is closer to imitation of firewall without actual firewall. Like in firewalls the rulebase can be quite elaborate with proper segmentation of IP space. As such they are more useful that plain-vanilla signature-based NIDS but combined approach might also work. This approach sometimes is called policy deviation approach. These policy deviations include detection of unauthorized network services, applications running on unusual ports and logs from network sessions denied by firewalls.
  • Statistically based anomaly detectors. Here abrupt changes in traffic patterns signify the problem.
  • More generic behavior based (including statistically based) anomaly detectors. That usually presuppose using a rule based expert system  for processing of the stream of the alerts and possibly correlating it with other streams. Often what vendors sell as anomalies detection NIDS is nothing more then adding to signature based core some heuristic methods similar to those used in antivirus scanners. These heuristic methods might be still highly effective for detection of port scans, distributed network probes, new forms of buffer overflows and denial of service attacks.
     
• Intrusion prevention system (IPS)  combines NIDS with the ability to modify firewall rules (or worse it acts as ad-hoc firewall itself).  It can be host-based or LAN based. HOST-based systems are less dangerous (but are dangerous). LAN based IPS are the most dangerous type as it's possible to use this capabilities for denial of service attacks. If return on the investment on pure NIDS is marginal or equal zero, then the return on investment on IPS is usually negative. There are many flavors of IPS, making this type of IDS hard to define. Commercial offerings (for example from ISS) are especially problematic and can do a lot of damage... 

  On the other side there are possibilities of adding NIDS functionality to regular firewalls and this is promising path of developing NIDS.  If you think about it NIDS can be considered to be a passive device listen to traffic and analyze only those packets that passed firewall filtering rules. That means that 90% of processing required for NIDS were already done on firewall level.  It is in this narrow sense Gartner 2003 statement that NIDS are irrelevant and we should switch to IPS might be true.
   

• A host-based NIDS that is usually integrated with host firewall (or at least it should). Theoretically those has higher return on investment then general network NIDS as rules can be highly specific and tuned to the services that are actually available on a particular computer. For example firewall can block TFTP port while NIDS can detect and report all traffic to this port (useful for detecting some network worms that used RPC holes and TFTP delivery to propagate). Reporting can be local or centralized.  They can be integrated with HIDS especially with log monitors. In case of presence of both networking IDS and host based IDS (that can communicate with each other) on the same server such an architecture would be called a hybrid IDS.

  At the same time like local firewalls they represent a danger to the networking stack of the computer they supposedly protect.

The second important classification of NIDS is the placement:

• Internet-facing NIDS. Most IDS are located on ingress to network (internet connection) either before or after the firewall. In large organization such NIDS usually are overwhelmed by the complexity of the traffic and cannot produce anything but a stream of  expensive "security spam" -- email alerts that for years are ignored by personnel (most times this is hidden -- hypocrisy and political correctness rules, but sometimes it's pretty open attitude). This IDS-generated spam is probably the most expensive spam in existence. Still because this is a politically correct thing to have few have courage to dismantle them. 
• Site-based NIDS. In a large organization site is an important logical unit of network structure and the whole network is composed on multiple interconnected sites. While to understand the whole traffic is very difficult, to understand the traffic on ingress of the site (site router) is easier and often more productive.
• Special purpose NIDS. Those are speculated on listening on certain types of traffic. One common implementation is VPN NIDS that are listening just to VPN traffic.

Organizations rarely have the resources to investigate every "security" event. Instead, they must attempt to identify and address the top issues, using the tools they've been given. This is practically impossible if an IDS is listening to a large traffic stream with many different types of servers and protocols. In this case security personnel, if any, are being forced to practice triage: tackle the highest-impact problems first and move on from there. Eventually it is replaced with even more simple approach: ignore them all ;-). Of course much depends on how well signatures are tuned to particular network infrastructure.  therefore another classification can be based on the type of signature used:

• Generic signature based. In this case like in virus scanners signatures are usually supplied by the vendor using some form of paid subscription.  The usefulness of such NIDS is usually quite low.  This is exacerbated by attempt of IDS vendors to prove their usefulness by trying duplicate functionality of  antivirus mail gateway. Architecturally this is pretty funny attempts,  but they are pretty successful as vendors always can find enough lemmings to sell their wires by speculating on virus-related FUD.
• Custom signature based NIDS. Those are more useful and usually can provide some level of useful signal. They are also more expensive as maintaining custom signature set requires high qualification.

Even is case when you limit traffic to specific segment of the internal network (for example local sites in national or international corporation, which is probably the best NIDS deployment strategy) the effectiveness of network IDS is low but definitely above zero. That can be marginally useful in this restricted environment. Moreover that might have value for network troubleshooting (especially if they also configured to act as a blackbox recorder for traffic; the latter can be easily done using TCPdump as the first stage and processing TCPdump results with snort of Perl scripts, say, each quarter of an hour).  Please not that all those talks about real time detection are 99% pure security FUD. Nothing can be done in most large organizations in less the an hour ;-)

That's why many large enterprise customers (especially those who still staff that have some clue, despite all efforts spend on outsourcing) started to defect commercial IDS vendors approximately in 2003. See my IDS Whitepaper for details.  In order to preserve their business (and revenue stream) IDS vendors started to hype intrusion prevention systems as the next generation of IDS. But IPS is a very questionable idea that mixes the role of firewall with the role of IDS sensor. It's not surprising that it backfired many times for early (and/or too enthusiastic) adopters (beta addicts). 

It is very symptomatic and proves the point about "innocent fraud" that intrusion prevention usually is advertised on the base of its ability to detect mail viruses, network worms threats and Spyware.  For any specialist it is evident that mail viruses actually should be detected on mail gateway and it is benign idiotism to try to detect then on the packet filter level.  Still idiotism might be key to commercial success and most IDS vendors pay a lot of attention to the rules or signatures that provide positive PR and that automatically drives that into virus/worms detection wonderland. There are two very important points here:

• The detection of a SMTP virus should be done on higher level of protocols (it's an extremely questionable idea to use packet filter like snort for detecting email viruses). If a particular virus/worm is propagating by mail, the detection (and blocking) should be done on mail gateway, not in IP packets analyzers. But NIDS vendors needs to survive that this is the most lucrative from PR standpoint area so the results are evident: any technical logic is bypassed by marketing. If an organization attempts to detect SMTP viruses using packet filter like snort it is usually sign on complete lack on architectural vision (as well as networking skills) of personnel or advanced stage of outsourcing.  Buyers of ISS managed services automatically qualify for this litmus test ;-)
• A new network worm typically requires new signatures and commercial IDS vendors are typically very bad (always late) in this area. That actually not completely true as two recent network worms used the same TFTP based propagation but generally copycat attempts fail. New global worm propagation usually happens when the worm author manages to find a new propagation vector.

May be things eventually improve, but right now I do not see how commercial IDS can justify the return on investment and NIDS looks like a perfect area for open source solutions. In this sense please consider this page a pretty naive (missing organizational dynamic and power grab issues in large organizations) attempt to counter "innocent fraud" to borrow the catch phrase used by famous economist John Kenneth Galbraith  in the title of his last book "The Economics of Innocent Fraud".  

Important criteria for NIDS is also the level of programmability:

• Ad-hoc NIDS use some language that evolved during the evolution of a particular implementation. Snort is a good example of this category.
• Some networking IDSs are based on using a scripting languages as the main traffic analysis engine and that's presents a considerable advantage. The early example of this approach was Shadow.  As I mentioned above speed of processing packet is not an issue. Most NIDS can happily do complex processing offline after the initial binary dumps of traffic were created by TCPdump or similar tools. Attempts to use NIDS "inline" lead to premature optimization problem and are generally detrimental to quality of NIDS as they dictate some ad-hoc solutions.  Black box approach is the only right approach if you really want to detect a useful signal a typical amount of network noise. Here Snort managed to improve from its early days and the current version of Snort supports Perl-style regular expressions. Using it offline you can create as complex expressions as you wish. That substantially improves chances to pickup useful signal.

It's rather counterproductive to place NIDS in segments with large network traffic. Mirroring port on the switches work in simple cases, but in complex cases where there are multiple virtual LANs that will not work as usually only one port can be mirrored. Also mirroring increase the load on the switch. Taps are additional component and are somewhat risky on high traffic segments unless they are designed to channel all the traffic in case of failure.  Logically network IDS belongs to firewall and some commercial firewalls have rudimentary IDS functionality. Also personal firewall with NIDS component might be even be more attractive for most consumers as they provide some insight on what is happening. They also can be useful for troubleshooting.   Their major market is small business and probably people connected by DSL or cable who fear that their home computers may be invaded by crackers.

Among open source network Intrusion Detection Systems (IDS) Snort is the most well developed and powerful solution. It covered in a separate page. But along with network-based intrusion detection, one probably should pay more attention to host-based IDS that uses log analysis and integrity checking. One should never put all eggs into one basket. The most popular integrity checker is Tripwire, but it's  too primitive for the intrusion detection. See Softpanorama Integrity Checkers

The problem is that useful signal about probes on actual intrusions is usually buried under mountains of data and wrong signal may drive you in a wrong direction.  A typical way to cope with information overload from network IDS is to rely more on the aggregation of data (for example, detect scans not single probes) and  "anomaly detection"  (imitate firewall detector or use statistical criteria for traffic aggregation). 

Misuse detection is more costly and more problematic that anomaly detection approach with the notable exception of honeypots. It might be beneficial to use a hybrid tools that combine honeypots and NIDS. Just as a sophisticated home security system might comprise both external cameras and sensors and internal monitoring equipment to watch for suspicious activity both outside and within the house - so should an intrusion detection system.

You may not know it, but a surprisingly large number of IDS vendors have license provisions that can prohibit you from communicating information about the quality and usability of their security software. Some vendors have used these software license provisions to file or threaten lawsuits to silence users who criticized software quality in places such as Web sites, Usenet newsgroups, user group bulletin boards, and the technical support boards maintained by software vendors themselves. Here open source has a definite advantage, because it may be not the best but at least it is open, has a reasonable quality (for example Snort is very competitive with most popular commercial solutions) or at least it is the cheapest alternative among several equally bad choices ;-). 

IDS often (and wrongly) are considered to be the key component for the enterprise-level security. Often that is achieved by buying fashionable but mainly useless outsourced IDS services. Generally this idea has a questionable value proposition because of the level of false positives and problems with the internal infrastructure (often stupid misconfigurations on WEB server level, inability to apply patches in a timely manner, etc.) that far outweigh and IDS-inspired capabilities.  If you are buying IDS, the good staring point is to ask to show what attacks they recently detected and negotiate one to six month trial before you pay the money ("try before you buy"). 

The problem of false positives for IDS is a very important problem that is rarely discussed on a sound technological level. I don't think there is a 'best' IDS.  But here are some considerations:

• Quality of custom signatures and the procedure for their update. Any NIDS is as good as the signature database and here we have the major problem: generic signatures while marginally useful  does not provide much interesting information. the most interesting information you can get from custom signatures, that reflect the specifics of the network architecture for a particular organization as well as implicit restriction of the traffic in the sensing point. Without constant work on custom signatures usual installation of Snort generates some interest for a month or so and then becomes completely neglected like home exercise equipment.  The same is even more true for the commercial IDS (people who install Snort are usually more technically savvy that people who buy IDS appliances). While capabilities of the current NIDS are more or OK (Snort 2.4 is one example) generic signature database is usually completely detached from the reality of your network traffic and without careful tuning cannot produce useful signals.  Also the number of rules in the database that is often stressed in marketing does not mean much:  10 000 outdated rules does not buy you anything but additional false positives.  100 current rules can do much better job.
   
• The capabilities of the box (sensor). Under heavy load most NIDS systems that have complex signature databases will perform radically differently on, say, a 1.6Ghz Pentium with 256M of RAM (desktop used for a sensor) compared to a 3.2Ghz dual CPU machine with 4G of RAM.  May be 3.2Ghz and 4G of RAM is overkill (of course it depends on the configuration), but generally you need to ensure that the sensor does not drop packets under heavy load.  Another way to ensure this is to use writing the stream into a file using TCPdump and then analyzing it with snort and other tools.
   
• Level of packet analysis. Packet capture rates don't mean much unless you also take into account what the product can do with packets after it's captured them.  That's why it's important to separate packet capture from packet analysis and do packet analysis in some batches (let's say 15 min).  How much analysis does the IDS actually do and can it recreate the session? This is a really interesting area. For example Snort is usually configured with plug-ins that do decrementing and IP reassembly into valid streams that can be then replayed.
   
• Database used for the storage of packets. What you can do with data written on the disk depends on whether you store it in database of in text (or raw binary) format.  Storing all "suspicious" packets in the database along with alerts is useful and can provide more user friendly front ends, but generally everything that can be done with database can be done without it only slower. You essentially trade speed for disk space.
   
• Integration with ESM. For example if an organization uses Tivoli it should be some Tivoli integration at least for critical NIDS alerts. That can be done via TEC log adapter or other mechanism but it needs to be done.

You probably got the idea at this point: the IQ of the network/security administrators and the ability to adapt the solution to this organization is of primary importance in the IDS area, more important then in, say, virus protection (where precooked signatures sets rules despite being a huge overkill).  

All-in-all the architecture and the level of customarization of the rulebase are more important then the capabilities of the NIDS.

Dr. Nikolai Bezroukov

NEWS CONTENTS

• 20190131 : How to audit all Commands run on a Linux system using auditd ( Jan 31, 2019 , www.thegeekdiary.com )
• 20171219 : How Security Companies Sucker Us With Lemons by Bruce Schneier ( Dec 19, 2017 , www.wired.com )
• 20070220 : NIST SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS) published ( NIST SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS) published, Feb 20, 2007 )
• 20061010 : NIST Computer Security DRAFT Publications ( NIST Computer Security DRAFT Publications, Oct 10, 2006 )
• 20061006 : [fw-wiz] FW appliance comparison - Seeking input for the forum ( [fw-wiz] FW appliance comparison - Seeking input for the forum, Oct 6, 2006 )
• 20061006 : LISA 06 Technical Sessions ( LISA '06 Technical Sessions, )
• 20061006 : R eal-time understanding of the health of a distributed system cannot be done by sucking data from a packet-level fire hose. ( )
• 20061006 : Is Intrusion Detection a Dead-End Technology - CSO Talk Back ( Is Intrusion Detection a Dead-End Technology - CSO Talk Back, )
• 20061006 : Goldens Rules Beyond the LAMP stack - A guide to open source Nagios, Xen & Asterisk ( Golden's Rules Beyond the LAMP stack - A guide to open source Nagios, Xen & Asterisk, )
• 20061006 : Snort Enterprise Implementation ( Snort Enterprise Implementation, )
• 20061006 : SecurityFocus HOME Infocus Evaluating Network Intrusion Detection Signatures ( SecurityFocus HOME Infocus Evaluating Network Intrusion Detection Signatures, )
• 20061006 : DShield - Distributed Intrusion Detection System ( DShield - Distributed Intrusion Detection System, )
• 20061006 : ITworld.com - Real hackers go to Usenix ( ITworld.com - Real hackers go to Usenix, )
• 20061006 : IDC: IDSES AND VULNERABILITY ASSESSMENT REVENUE GOING UP ( )
• 20061006 : Cisco Flow Logs and Intrusion Detection at the Ohio State University by Steve Romig, Mark Fullmer, and Suresh Ramachandran ( Cisco Flow Logs and Intrusion Detection at the Ohio State University, )
• 20061006 : Invisible Intruders: Rootkits in Practice by David Brumley ( Invisible Intruders: Rootkits in Practice, )
• 20061006 : Indicators of UNIX Host Compromise by Paul C. Brutch, Tasneem G. Brutch, and Udo Pooch ( Indicators of UNIX Host Compromise, )
• 20061006 : A Hackers Approach to ID by Mudge ( A Hacker's Approach to ID, )
• 20061006 : A Glimpse Into the Future of ID by Tim Bass and Dave Gruber ( A Glimpse Into the Future of ID, )
• 20061006 : On Reliability by John Sellens ( On Reliability, )
• 20061006 : Defending Yourself: The Role of Intrusion Detection Systems by John McHugh, Alan Christie, and Julia Allen IEEE Software: ( Defending Yourself: The Role of Intrusion Detection Systems, )
• 20000727 : Network Intrusion Detection Using Snort by Dave Wreski & Christopher Pallack ( Network Intrusion Detection Using Snort, Jul 27, 2000 )
• 20000727 : Snort Portscan Preprocessor ( Snort Portscan Preprocessor, Jul 27, 2000 )
• 20000727 : WIN32 port of snort ( WIN32 port of snort, Jul 27, 2000 )
• 20000727 : Snort Tools and Info ( Snort Tools and Info, Jul 27, 2000 )
• 20000727 : ZDNet eWEEK The software that cried wolf ( ZDNet eWEEK The software that cried wolf, )
• 20000727 : Root Prompt -Intrusion Detection by Lance E. Spitzner -- a simple tcpwrapper based approach. ( Root Prompt -Intrusion Detection, )
• 20000619 : SECURITY: LinuxSecurity.com: Network Intrusion Detection Using Snort ( SECURITY: LinuxSecurity.com: Network Intrusion Detection Using Snort, Jun 19, 2000 )

Old News ;-)

[Jan 31, 2019] How to audit all Commands run on a Linux system using auditd

Jan 31, 2019 | www.thegeekdiary.com

By admin

The audit package ties into the Linux kernel audit subsystem. The audit system audits system calls and other kernel level events, not user-space events, so we need to audit the execve() system call which is what starts executing new programs. For the example in this post, we have taken the CentOS/RHEL system, but the steps remain more or less the same for other *NIX distributions as well.

For CentOS/RHEL 7 Apply audit rules into the system

1. To keep the rules persistent after reboot or service restart, add the following rules to file /etc/audit/rules.d/audit.rules :

# vi /etc/audit/rules.d/audit.rules
-a exit,always -F arch=b32 -S execve -k auditcmd
-a exit,always -F arch=b64 -S execve -k auditcmd

2. Run " augenrules " command to recreate /etc/audit/audit.rules from all configuration files in /etc/audit/rules.d/audit.rules and restart auditd.

3. If you only want to apply the rules temporarily, run following commands as root:

# auditctl -a exit,always -F arch=b32 -S execve -k auditcmd
# auditctl -a exit,always -F arch=b64 -S execve -k auditcmd

Verify Current rules

To verify the current rules, run:

# auditctl -l

Verify audit logs

To verify audit logs for a specific keyword, run:

# ausearch -k auditcmd

Note : In CentOS/RHEL 7, to stop/start/restart auditd service, run service auditd stop|start|restart. For CentOS/RHEL 6 To log all commands

1. First, auditd needs to be running. It should be running by default, but if it's not, start it with:

# chkconfig auditd on
# service auditd start

2. If it is a 64 bit architecture then you need to add two rules to catch both 32-bit and 64-bit system calls. As root, run:

# auditctl -a exit,always -F arch=b32 -S execve
# auditctl -a exit,always -F arch=b64 -S execve

3. Run ls /tmp, these 3 events appears in /var/log/audit/audit.log . Lines are wrapped to make it easier to read here, but it's normally a single long line in the real file.

# tail -f /var/log/audit/audit.log
type=SYSCALL msg=audit(1296773801.756:35241): arch=c000003e syscall=59 
    success=yes exit=0 a0=cf2d10 a1=9da530 a2=cd4e20 a3=8 items=2 
    ppid=4146 pid=11827 auid=500 uid=500 gid=500 euid=500 
    suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts7 
    ses=3 comm="ls" exe="/bin/ls"
    subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=EXECVE msg=audit(1296773801.756:35241): argc=3 a0="ls"
    a1="--color=auto" a2="/tmp" type=CWD msg=audit(1296773801.756:35241):
    cwd="/home/username"
type=PATH msg=audit(1296773801.756:35241): item=0 name="/bin/ls" 
    inode=14418043 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 
    obj=system_u:object_r:bin_t:s0 type=PATH 
    msg=audit(1296773801.756:35241): item=1 name=(null) inode=20447259
    dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
    obj=system_u:object_r:ld_so_t:s0

The audit logs are quite verbose, but they contain the full command, including the fact that ls was aliased by the shell to ls –color=auto . The first number in parentheses is a timestamp in seconds after the epoch. This can be converted to a human-readable time with Perl:

$ perl -e 'print scalar(localtime(1296773801.756)) . "\n";'
Thu Feb  3 16:56:41 2011

The exit=0 in the SYSCALL line above is regarding the execve() system call, not the overall program.

To log all commands for specific user

1. Start auditd service:

# chkconfig auditd on
# service auditd start

2. Add audit rule:

For 64-bit architecture:

# auditctl -a exit,always -F arch=b64 -F uid=500 -S execve -k auditcmd

For 32-bit architecture:

# auditctl -a exit,always -F arch=b32 -F uid=500 -S execve -k auditcmd

Here, uid is of the user for whom auditing is enabled of all commands. Run the auditctl command as root user to add the rules.

3. Verify the logs are being generated by checking /var/log/audit/audit.log file. Once user starts executing commands the logs will appear as below:

# tail -f /var/log/audit/audit.log
type=SYSCALL msg=audit(1393407885.099:8614): arch=c000003e syscall=59 success=yes exit=0 a0=158c9b0 a1=1588f10 a2=15a7ae0 a3=18 items=2 ppid=3123 pid=3307 auid=0 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 ses=1 comm="ls" exe="/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=EXECVE msg=audit(1393407885.099:8614): argc=2 a0="ls" a1="--color=auto"
type=CWD msg=audit(1393407885.099:8614):  cwd="/home/sadaf"
type=PATH msg=audit(1393407885.099:8614): item=0 name="/bin/ls" inode=408600 dev=fc:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1393407885.099:8614): item=1 name=(null) inode=429303 dev=fc:02 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0

type=SYSCALL msg=audit(1393407910.242:8615): arch=c000003e syscall=59 success=yes exit=0 a0=15971e0 a1=158c9b0 a2=15a7ae0 a3=18 items=2 ppid=3123 pid=3310 auid=0 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1 ses=1 comm="rmdir" exe="/bin/rmdir" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=EXECVE msg=audit(1393407910.242:8615): argc=2 a0="rmdir" a1="data"

NOTE : Audit generates extensive logs since every command will be recorded, which may have a negative impact on overall system performance.

[Dec 19, 2017] How Security Companies Sucker Us With Lemons by Bruce Schneier

This George Akerlof ideas about asymmetrical information (" The Market for 'Lemons '") are probably as applicable to used car as for IDS.

Notable quotes:

"... In 1970, American economist George Akerlof wrote a paper called " The Market for 'Lemons '" (abstract and article for pay here ), which established asymmetrical information theory. He eventually won a Nobel Prize for his work, which looks at markets where the seller knows a lot more about the product than the buyer. ..."

"... Bruce Schneier is the CTO of BT Counterpane and the author of ..."

Dec 19, 2017 | www.wired.com

Encryption is the obvious solution for this problem -- I use PGPdisk -- but Secustick sounds even better: It automatically erases itself after a set number of bad password attempts. The company makes a bunch of other impressive claims: The product was commissioned, and eventually approved, by the French intelligence service; it is used by many militaries and banks; its technology is revolutionary.

Unfortunately, the only impressive aspect of Secustick is its hubris, which was revealed when Tweakers.net completely broke its security. There's no data self-destruct feature. The password protection can easily be bypassed. The data isn't even encrypted. As a secure storage device, Secustick is pretty useless.

On the surface, this is just another snake-oil security story. But there's a deeper question: Why are there so many bad security products out there? It's not just that designing good security is hard -- although it is -- and it's not just that anyone can design a security product that he himself cannot break. Why do mediocre security products beat the good ones in the marketplace?

In 1970, American economist George Akerlof wrote a paper called " The Market for 'Lemons '" (abstract and article for pay here ), which established asymmetrical information theory. He eventually won a Nobel Prize for his work, which looks at markets where the seller knows a lot more about the product than the buyer.

Akerlof illustrated his ideas with a used car market. A used car market includes both good cars and lousy ones (lemons). The seller knows which is which, but the buyer can't tell the difference -- at least until he's made his purchase. I'll spare you the math, but what ends up happening is that the buyer bases his purchase price on the value of a used car of average quality.

This means that the best cars don't get sold; their prices are too high. Which means that the owners of these best cars don't put their cars on the market. And then this starts spiraling. The removal of the good cars from the market reduces the average price buyers are willing to pay, and then the very good cars no longer sell, and disappear from the market. And then the good cars, and so on until only the lemons are left.

In a market where the seller has more information about the product than the buyer, bad products can drive the good ones out of the market.

The computer security market has a lot of the same characteristics of Akerlof's lemons market. Take the market for encrypted USB memory sticks. Several companies make encrypted USB drives -- Kingston Technology sent me one in the mail a few days ago -- but even I couldn't tell you if Kingston's offering is better than Secustick. Or if it's better than any other encrypted USB drives. They use the same encryption algorithms. They make the same security claims. And if I can't tell the difference, most consumers won't be able to either.

Of course, it's more expensive to make an actually secure USB drive. Good security design takes time, and necessarily means limiting functionality. Good security testing takes even more time, especially if the product is any good. This means the less-secure product will be cheaper, sooner to market and have more features. In this market, the more-secure USB drive is going to lose out.

I see this kind of thing happening over and over in computer security. In the late 1980s and early 1990s, there were more than a hundred competing firewall products. The few that "won" weren't the most secure firewalls; they were the ones that were easy to set up, easy to use and didn't annoy users too much. Because buyers couldn't base their buying decision on the relative security merits, they based them on these other criteria. The intrusion detection system, or IDS, market evolved the same way, and before that the antivirus market. The few products that succeeded weren't the most secure, because buyers couldn't tell the difference.

How do you solve this? You need what economists call a "signal," a way for buyers to tell the difference. Warrantees are a common signal. Alternatively, an independent auto mechanic can tell good cars from lemons, and a buyer can hire his expertise. The Secustick story demonstrates this. If there is a consumer advocate group that has the expertise to evaluate different products, then the lemons can be exposed.

Secustick, for one, seems to have been withdrawn from sale .

But security testing is both expensive and slow, and it just isn't possible for an independent lab to test everything. Unfortunately, the exposure of Secustick is an exception. It was a simple product, and easily exposed once someone bothered to look. A complex software product -- a firewall, an IDS -- is very hard to test well. And, of course, by the time you have tested it, the vendor has a new version on the market.

In reality, we have to rely on a variety of mediocre signals to differentiate the good security products from the bad. Standardization is one signal. The widely used AES encryption standard has reduced, although not eliminated, the number of lousy encryption algorithms on the market. Reputation is a more common signal; we choose security products based on the reputation of the company selling them, the reputation of some security wizard associated with them, magazine reviews, recommendations from colleagues or general buzz in the media.

All these signals have their problems. Even product reviews, which should be as comprehensive as the Tweakers' Secustick review, rarely are. Many firewall comparison reviews focus on things the reviewers can easily measure, like packets per second, rather than how secure the products are. In IDS comparisons, you can find the same bogus "number of signatures" comparison. Buyers lap that stuff up; in the absence of deep understanding, they happily accept shallow data.

With so many mediocre security products on the market, and the difficulty of coming up with a strong quality signal, vendors don't have strong incentives to invest in developing good products. And the vendors that do tend to die a quiet and lonely death.

Comment on this article.

- - -

Bruce Schneier is the CTO of BT Counterpane and the author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World .

[Feb 20, 2007] NIST SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS) published

A decent introduction for non-professionals into the topic. They avoid blatant exaggerations but there is not much useful into either. Can be useful for managers, though.

Such government documents are usually pretty much castrated as they try to please everybody (or at least to avoid the wrath of vendors for telling the truth :-). Still the authors avoid exaggerations typical for Gardner group "I love IDS" stance...

February 2007 (NIST) Adobe PDF (1,279 KB) Zipped Adobe PDF (954 KB)

[Oct 10, 2006] NIST Computer Security DRAFT Publications

August 31, 2006 (NIST) Draft Special Publication 800-94, Guide to Intrusion Detection and Prevention (IDP) Systems

Adobe PDF (2,333 KB)
Zipped PDF (1,844 KB)

NIST announces the release of draft Special Publication (SP) 800-94, Guide to Intrusion Detection and Prevention (IDP) Systems. SP 800-94 seeks to assist organizations in understanding intrusion detection system (IDS) and intrusion prevention system (IPS) technologies and in designing, implementing, configuring, securing, monitoring, and maintaining intrusion detection and prevention (IDP) solutions. It provides practical, real-world guidance for each of four classes of IDP products: network-based, wireless, network behavior anomaly detection software, and host-based. The publication also provides an overview of complementary technologies that can detect intrusions, such as security information and event management software. It focuses on enterprise IDP solutions, but most of the information in the publication is also applicable to standalone and small-scale IDP deployments. This publication replaces NIST SP 800-31, Intrusion Detection Systems.

NIST requests comments on SP 800-94 by October 20, 2006. Please submit comments to [email protected] with "Comments SP800-94" in the subject line.

[Oct 6, 2006] [fw-wiz] FW appliance comparison - Seeking input for the forum

A pretty interesting exchange of ideas on NIDS. Marcus J. Ranum performed much weaker then usual (actually zero constructive ideas) but several "IDS skeptics" like Patrick M. Hausen, Paul D. Robertson, etc performed really well and provided several interesting insights. Here are several interesting quotes:

• With that much data, and 98% of it being useless, you kind have to ask yourself, "what's the point?"
• Everything I've seen says they look for known-bad-stuff and produce alerts and false positives.
• I agree that IDS is a waste of time except if you need to provide glossy feel good reports to mgmt. Then theyr'e great!
• Why would you want a signature based IDS at all? They don't work.
  Period. Enumerating badness is a silly idea.
• Sure they do. The premise may be flawed, but the technology works, even if
  it falls into the "better than nothing" category. They're smoke detectors
  for a small subset of possible fires. Using one is still better than
  letting the house burn to the ground each and every time there's a fire.
• [Paul D. Robertson ]To me, IDS is like a left-handed screwdriver, you can send someone around
  and waste their time with it, but when it comes to fixing something, it's
  not there. If you need IDS, it's because of a failure elsewhere, and if
  you're done everything right, the value is negligable.
• That's the main reason why I don't like IDSs. A default deny
  policy combined with "log everything" achieves just the same.

LISA '06 Technical Sessions/Everything You Know About Monitoring Is Wrong Mazda A. Marvasti, Integrien Corporation

Real-time understanding of the health of a distributed system cannot be done by sucking data from a packet-level fire hose.

This talk will propose an alternative approach to managing complex distributed systems. Mazda will explain why inference from key metrics allows real-time understanding of the health of a distributed system in a way that sucking data from a packet-level fire hose does not. He'll explore the value of a steady stream of out-of-normal alerts, question the value of end-to-end service mapping, and explore whether virtualization is the silver bullet for coping with complexity.

Dr. Mazda Marvasi, Ph.D., is CTO of Integrien Corporation. Mazda leads Integrien's extensive global R&D effort as well as overseeing technology, architecture, and engineering infrastructure development at Integrien. Mazda has deep experience in leading teams in the development, deployment, and monitoring of global enterprise networks and application environments. Mazda has been recognized by "Who's Who in Science and Engineering", and received the Lockheed Leadership Fellowship Award.

Is Intrusion Detection a Dead-End Technology - CSO Talk Back

Also contains some interesting posts in feedback area

A month ago, a Gartner research report declared that intrusion detection systems were a market failure. The report and a graph depicting Gartner's "Information Security Hype Cycle" indicated that intrusion detection system (IDS) technology had gone beyond the "peak of inflated expectations" and was rapidly sliding toward the "trough of disillusionment." While, according to Gartner's Hype Cycles, some technologies emerge from that dread trough and climb respectably to a plateau of usefulness, Gartner had no such hope for IDS. It said the products have failed to provide value relative to costs and will be obsolete by 2005.

That made IDS vendors cross. People who've spent a lot of money with them weren't very psyched about this report, either.

Vendors and spenders alike accept some of the criticisms that Gartner lobs at the young technology, such as its high demands on networks and IT staff, its high requirement for maintenance and its high rate of false positives (one IDS user told Computerworld that his company's IDS generated more than 600 alerts daily). But they've called the report's prediction for IDS to completely fizzle short-sighted and emotional and alarmist. The products are evolving and improving, they say.

Intrusion detection systems typically work within a network's firewall to identify and record attempts to break into or misuse the system by sniffing packets off a switch port. They alert administrators to what they find but can't drop anything out of the flow of traffic.

Another technology often mentioned in the same breath as IDS is intrusion prevention systems (IPS), which are seen to combine the detection function of IDS but, being deployed differently, can respond more directly to perceived intrusion. The Gartner report, however, suggests that IPS is just following IDS along the hype trail to oblivion and that instead, "functionality is moving into firewalls, which will perform deep packet inspection for content and malicious traffic blocking, as well as antivirus activities."

IDS vendors say no prevention system, be it IPS or advanced firewalls, is going to stop every attack. Therefore IDS is needed for monitoring and audit functions, in order to analyze a system's weaknesses and adapt prevention policies to that.

Does that ring true to you, or is it wishful thinking from those invested in the hype? Is it time to cut bait and try something else, or is Gartner looking for its own hype?

Golden's Rules Beyond the LAMP stack - A guide to open source Nagios, Xen & Asterisk

Nagios: Your friendly network monitor

In enterprise environments with large numbers of machines and network resources, administrators often are run ragged fighting fires. Many times, the first a sys admin hears about a problem is when someone calls to complain about an application not being available. This is certainly not helpful in polishing IT's image and definitely an inefficient way to run a shop. The solution is network monitoring software that tracks the state of all resources in the environment, whether machines, network resources or services, such as SSH (Secure Socket Shell).

Nagios is a lightweight open source network monitor that can be used to help harried system administrators. Unlike some other products, Nagios does not require agent software to be placed on the monitored resource (thus the term light-weight). It is very straightforward to configure and offers the ability to group resources by type (so, all machines running SSH might fall into an SSH_group). Naturally, you can also configure it to raise an alert about a problem situation so that someone can know to go fix it.

How good is Nagios? One article cited on the Nagios site quoted an unnamed-by-request CIO who was replacing a commercial product costing $1.5 million per year with Nagios. He noted Nagios wouldn't do everything the commercial product would, but it could be extended by his staff and still offer significant savings. Nagios has had around 500K SourceForge downloads in its three-year life, so it is pretty well-established, if not that well-known.

One of the most attractive aspects of Nagios is the fact that so many extensions have been built for it and are also available as open source. Just as ACID makes Snort a much more useful tool, these extensions build on the base Nagios product and provide additional functionality.

Snort Enterprise Implementation

The purpose of this guide is to document the installation and configuration of a complete Snort implementation. This guide contains all the necessary information for installing and understanding the architectural layout of the implementation. [PDF]

SecurityFocus HOME Infocus Evaluating Network Intrusion Detection Signatures Evaluating NID Signatures, Part Two by Karen Kent Frederick September 25, 2002

In this series of articles, we present recommendations that will help readers to evaluate the quality of network intrusion detection (NID) signatures, either through hands-on testing or through careful consideration of third-party product reviews and comparisons. The first installment discussed some of the basics of evaluating NID signature quality, as well selecting attacks to be used in testing. This article will conclude the discussion on criteria for choosing attacks and then provide recommendations for generating attacks and creating a good testing environment. We begin by discussing some methods of acquiring attacks and attack traffic.

Downloading Exploits From the Web

One shortcoming with most NID evaluations is that the attacks that are used to evaluate NID signature quality are chosen in an ad hoc manner. The tester typically visits a few Web sites that have exploit source code and executables, downloads some of the files, and runs them. There are several potential problems with doing this:

• Because exploits are published by so many individuals and groups, and are hosted in so many different places, there is typically no way of verifying their authenticity. The file could have been changed or replaced since it was originally distributed.
• Some exploits claim to do one thing but really do something else; for example, a program that claims to perform a format string attack against an FTP server might actually install a backdoor on the host that runs the attack. This may be done instead of the attack, or in addition to it.
• An exploit that is available in executable form only cannot be reviewed to confirm that it does what it's supposed to. Exploits that are available in source code form are typically written in any one of several languages; many also include shellcode sequences. In order to review the code of various exploits and confirm that they meet your needs, you'd either need to be at least somewhat familiar with various languages or have access to others in your organization who have the necessary knowledge and the time to assist you.
• Many exploits are purposely "broken" by their authors before they are made publicly available. Certain instructions or values are modified so that the tool doesn't execute the attack properly. Unless you are skilled in the required languages and exploit techniques, and have the time to dig into the code and figure out how it's supposed to work and what needs to be fixed, you probably won't be able to use such exploits in your testing.
• For each exploit, you'll need to figure out how to use it. What arguments do you need to supply? What other software packages, services or other components is this exploit dependent upon? If the attack will only run from a particular operating system, you may need to acquire or set up a host to run it. If the attack targets a particular operating system, protocol and/or application, you may need to set up a host that meets the target requirements. Many exploits verify the vulnerability of the victim before actually launching the attack; for example, the exploit may connect to the victim, acquire the FTP server banner, and determine whether the FTP server is a vulnerable version based on the information in the banner message. This can rapidly become far too resource-intensive to be practical.
• This may seem like an obvious point, but the exploit is going to attack your systems. Let's assume that you are using test systems for your attack targets, systems that can be wiped out and rebuilt as needed. Suppose an attack that you run replaces your FTP server with a Trojaned version. If you want to do additional testing of the FTP attack detection capabilities of your intrusion detection system, you may first need to replace the Trojaned FTP server with the original version, as other exploits may be expecting and requiring a particular vulnerable version of the FTP server to be present.

If it isn't already clear at this point, performing intrusion detection signature testing with real exploits is often time- and resource-intensive. It can also be dangerous: running real exploits in any type of live environment is very risky. No matter how cautious you are in acquiring and evaluating exploit code, mistakes can and will still occur. A mistyped target IP address can cause a production server to be breached instead of a designated target server. To be safe and to ensure that they do not inadvertently break their own systems, readers should utilize a completely isolated test network and test hosts. Of course, this further increases the time and resources that are needed to perform IDS testing. Therefore, it is often best for all but the most skilled, enthusiastic and patient testers to avoid the use of published exploit code when performing intrusion detection signature testing.

Using IDS Testing Tools

A safer and faster alternative to using real exploits is to purchase and utilize an IDS testing tool. The best-known IDS testing tool is Blade IDS Informer, from Blade Software. Informer works by replaying IP, UDP and ICMP packets, as well as complete TCP sessions that contain various scans, probes and attacks. You can modify the source and destination IP and MAC addresses that the packets use as needed. Informer comes with hundreds of attacks, divided into categories of related attacks; the user can select which attacks or groups of attacks they would like to use. Blade regularly updates the Informer attack suite so you can keep your IDS testing fairly current with new attacks and attack techniques.

The greatest benefit behind IDS testing tools is that the vendor has gone to the trouble of doing what you might otherwise have to do – downloading and verifying exploits. The IDS testing tool vendor has the expertise to confirm the validity of each exploit and to test it in a controlled environment. The attacks are also "neutralized" by the vendor; although the attack is executed, it is altered as necessary so it does not damage the target host. Besides these attacks, the vendor may also create their own exploits and exploit traffic, based on known vulnerabilities. This gives them full control over the attack without having to rely solely on the use of published exploits.

IDS testing tools typically have other features that can be very helpful in performing intrusion detection signature testing. Testing tools normally have a user-friendly interface, which makes the process of choosing and launching attacks much easier. With a few minutes of configuration and selection, traffic from many attacks can be replayed. Think of the time you would spend setting up an IDS testing tool, versus downloading, evaluating, compiling and running even ten exploits on your own. Now think of the time if you wanted to use five hundred exploits in your testing. An additional benefit is that the tester doesn't need any knowledge as to how the attacks work as the vendor has verified what each attack does. Report generation is also at least somewhat automated, reducing the time needed to document your results.

Another nice feature of IDS testing tools is that users are not limited to only the attacks that they include – they can also create custom attacks. For example, Informer can capture and replay attack traffic generated by the user. If you want to use a particular attack, you can do so and record its traffic for future use. This points out an important aspect of intrusion detection testing: repeatability. You may wish to validate the strength of your intrusion detection system's signatures periodically, to confirm that the signatures not only identify new significant threats, but also continue to detect older threats that are still relevant in your environment. To save time, it's highly desirable for testing procedures to be easily repeatable. Both the use of a testing tool such as Informer and the ability to capture and replay your own attack traffic at a later date, without having to rerun the individual attacks, are great ways to make your intrusion detection testing more efficient and consistent.

IDS testing tools also make it possible to perform IDS testing in a wider variety of environments. We emphasized earlier that when you are testing with live and potentially dangerous exploits, it's critical to utilize an isolated test environment. If you are utilizing the standard attacks provided by the testing tool, which are modified to prevent damage, then you are probably relatively safe to run them in a production environment. This is particularly true if you modify the IP addresses of the traffic so that the source and destination addresses are unused in your environment. Also, because tools such as Informer are replaying traffic, not actually performing interactive attacks with a server, you can save substantial time and resources in terms of hardware and software deployment. As long as you have a box to run the IDS testing tool from, you can perform your testing.

Issues with Using IDS Testing Tools

As with everything, there are also some potential issues with relying solely on IDS testing tools for evaluating IDS signature strength. First, you must consider the relevance of the attacks used by the testing tool in your environment. In an environment that uses common protocols and popular applications and operating systems, it's very likely that the attacks provided by the tool will closely match the potential threats against your environment. If your environment is unusual, then you should determine how many of the IDS testing tool's attacks are pertinent for your environment. It does no good to buy a tool that performs 95% of its tests on signatures for operating systems, protocols and applications that your systems do not run.

Another issue with IDS testing tools is that you must trust that the vendor has neutralized the attacks properly. Imagine what would happen if you ran attacks on a production segment and an improperly modified attack breached one of your servers! If you are sufficiently paranoid – and in the security world, it usually pays to be paranoid – you would utilize an IDS testing tool on an isolated network. It can be as simple as setting up one host to run the IDS testing tool, a second host to run the IDS sensor software, and connecting the two hosts through a hub. Of course, if you want to evaluate the quality of signatures in an IDS sensor that's already deployed into production, such a test may not be possible. If you trust the IDS testing tool, you can run it in a production environment; if you don't, you may run its tests in an isolated environment, examine the traffic to confirm that it's not harmful, and then run the tests again in production.

You should keep in mind that the testing tool vendor may have made mistakes in the attacks so that the attack traffic it generates does not properly reflect the actual attack. This can cause inaccurate testing results – an IDS sensor may be able to detect attack X but the IDS testing tool vendor may be replaying an invalid version of attack X. Also, the IDS signature may be intended to identify a harmful part of the attack that the IDS testing tool vendor has removed from the attack so as not to damage a target system.

A final and more subtle point is that the IDS testing tools themselves may introduce a bias into the testing. If a popular IDS testing tool uses 300 known attacks, an IDS vendor may write signatures that specifically match all these known attacks. This would have the effect of giving that vendor a higher score than others on signature quality. Depending on how the signatures are written, this may be accurate – or not. Vendors may write very weak signatures that simply match the testing tool's implementation of particular attacks and don't capture any other instances of the attack. If that's the case, then the testing results will be unfairly biased toward vendors that choose to implement such weak signatures simply for the purpose of improving their test results. To counteract this, you should not rely simply on an IDS testing tool for your evaluation.

Summary

In this article, we have examined in depth two ways to test intrusion detection signature quality: by downloading published exploits from the Internet, and by utilizing an IDS testing tool, specially designed to test signature capabilities. Although there is no direct cost in downloading exploit code, it can be prohibitively expensive to base your IDS testing on downloaded code because of the extensive knowledge, time and computing resources required. Commercial IDS testing tools reduce most of the need for these resources, but their use alone may caused biased test results. The next article in this series will examine other tools that are useful for performing IDS signature testing, as well as tools that are useful in testing NID anomaly detection and the general ability for IDS sensors to detect novel attacks.

Karen Kent Frederick ([email protected]) is a Senior Intrusion Detection Analyst for EDS in Herndon, Virginia. She is a graduate of the University of Wisconsin-Parkside and is currently completing her master's in computer science, focusing in network security, through the University of Idaho's Engineering Outreach program. Karen has over 10 years of experience in technical support, system administration and information security. She holds several certifications, including SANS GIAC Certified Intrusion Analyst, GIAC Certified Unix Security Administrator, and GIAC Certified Incident Handler. She is one of the authors of "Intrusion Signatures and Analysis" and "Inside Network Perimeter Security: The Definitive Guide to Firewalls, Virtual Private Networks, Routers, and Intrusion Detection Systems".

Relevant Links

Evaluating NID Signatures
Karen Kent Frederick, SecurityFocus

DShield - Distributed Intrusion Detection System

DShield.org is an attempt to collect data about cracker activity from all over the internet. This data will be cataloged and summarized. It can be used to discover trends in activity and prepare better firewall rules.

Right now, the system is tailored to simple packet filters. As firewall systems that produce easy to parse packet filter logs are now available for most operating systems, this data can be submitted and used without much effort.

More complex patterns, such as are used by application level firewalls may be handled in the future.

Dealing with False Positives

File Format: PDF/Adobe Acrobat - View as HTML
www.raid-symposium.org/raid2000/Materials/ Abstracts/50/Julisch_foils_RAID2000.pdf

ITworld.com - Real hackers go to Usenix

Dr. Blaine Burnham presented an interesting keynote address, "Design Principles of Simplicity." "Why do buffer overflow attacks still work?" he wondered. He went on to stress that security should not be an add-on. In some ways, Dr. Burnham was preaching to the choir. I know several managers and developers who refuse to accept that security needs to be designed into the architecture from the start.

As an example to illustrate his point, he referred to weeds indigenous to the American Southwest known as goatheads. These nasty little weeds produce spiked seeds that are the bane of bicyclists. Dr. Burnham pointed out that experienced cyclists quickly learned to take countermeasures to protect their tires. Why hasn't the software industry learned to take appropriate countermeasures that protect systems before they're flattened? he asked. Security must be designed into the system, not added on later. Intrusion-detection systems (IDSs) and patches are a last resort.

... ... ...

Network Security Wizards

I first noticed Network Security Wizards (NSW) and its Dragon IDS because of the similarity in the company's name and motif to those of my own company, Wizard's Keys. This coincidence reminded me of when Rain Forest Puppy referred me to Ron Gula (NSW's CEO and founder) when I was looking at intrusion-detection systems. RFP was pretty impressed with the performance of the Dragon IDS and knew I was looking for a system to monitor Cisco PIX firewalls. As luck would have it, Ron was manning the NSW booth himself and was happy to answer my inquiries.

Ron explained: "Technically, the network IDS is the Dragon Sensor, and its basic claims to fame are operation at Gigabit Ethernet speeds without hardware acceleration and one of the deeper signature libraries available on the market. The product that analyzes PIX log files is called Dragon Squire. It currently can look at any ASCII log file or stream of SNMP traps. We currently offer log analysis for Cisco, Cisco PIX, ipfilter, ipchains, and ipfw. Checkpoint, Raptor, and Sidewinder log formats are also being produced. In addition to the firewall log files, Dragon Squire also monitors log files for Web, FTP, Sendmail, DNS, syslog, and many other applications. It also performs MD5 analysis of key system files. A version for NT will be available in Q4."

IDC: IDSES AND VULNERABILITY ASSESSMENT REVENUE GOING UP

nice advertizing ;-)

Intrusion detection and vulnerability assessment revenues will pass the $1 billion mark by 2003, a new study says. Surprisingly, though, the growth is being fueled not by fear of intruders, but a need to better monitor the internal use of networks, according to a new International Data Corporation (IDC) market study.

"Organizations are purchasing intrusion detection and vulnerability assessment products to increase control and awareness over the state of their computing environments," says Charles Kolodgy, manager of IDC's Internet Security Research, in a prepared statement. The size and complexity of corporate networks are driving the dual functionality of IDSes and vulnerability assessment products, he adds. "By scanning the network, vulnerability assessment tools provide them the information they need."

The report released last week indicates revenue from intrusion detection software will increase by 37 percent CAGR between 1999 and 2004, while vulnerability assessment products will jump 32 percent. Purchases will shift from buying IDS software outright to having it embedded in appliances or sold as part of monitoring and detection services. "Little reason exists for any company outside the Fortune 200 to not seriously consider outsourcing the management of their intrusion detection software," notes IDC analyst Brian Burke.

Kevin Trosian, vice president of equity research for Banc of America Securities, agrees with IDC's evaluation of the security market. "IT managers today are looking to better utilize current assets, as opposed to purchasing new assets. And the best way to do that is to utilize technologies that can offer more control over the networks."

The decision is one of brains over brawn, Trosian says. "There's a big move--not only among IT manager but among big technology providers out there--to provide more intelligent solutions, as opposed to more powerful solutions," he says. "The networks are big--we've got a lot of power; we've got a lot of throughput through the core of the network. I think the key now is to control the traffic as it comes through. Essentially it's the same as adding a carpool lane or HOV lane to the highway."

Cisco Flow Logs and Intrusion Detection at the Ohio State University by Steve Romig, Mark Fullmer, and Suresh Ramachandran

Invisible Intruders: Rootkits in Practice by David Brumley

Indicators of UNIX Host Compromise by Paul C. Brutch, Tasneem G. Brutch, and Udo Pooch

A Hacker's Approach to ID by Mudge

A Glimpse Into the Future of ID by Tim Bass and Dave Gruber

On Reliability by John Sellens

Defending Yourself: The Role of Intrusion Detection Systems by John McHugh, Alan Christie, and Julia Allen IEEE Software:

What is the role of intrusion detection systems in an organization's overall defensive posture? This article provides guidelines for IDS deployment, operation, and maintenance.

[Jul 27, 2000] Network Intrusion Detection Using Snort By Dave Wreski & Christopher Pallack

[Jul 27, 2000] Snort Portscan Preprocessor

[Jul 27, 2000] WIN32 port of snort

[Jul 27, 2000] Snort Tools and Info

ZDNet eWEEK The software that cried wolf

Chances are, your company's intrusion detection software stopped suspicious-looking traffic today. Chances are, it was a false alarm, too.

Network attacks, including distributed denial-of-service and buffer overflow incursions, have put intrusion detection software on the front line in the battle against hackers. But the wider the deployment of intrusion detection, the more administrators are realizing the technology's limits and frustrations.

The reason: Too often, the software puts out false-positive alerts, which warn administrators about traffic that turns out to be innocuous but still send IT managers scurrying to plug security holes.

"It got to an absurd point, where every other day we were literally just blowing away our log file," said Robert Boyle, CEO of Tellurian Networks Inc., a managed-service provider in Newton, N.J.

Technically, false-positive intrusions are a hard problem for software companies to solve. The technology is a slave to a statistical phenomenon called the base rate fallacy. Attacks are rare relative to the amount of traffic coming into a network. The rarer the event, the more accurate the test must be to be useful. Right now, intrusion detection is not accurate enough and returns more false positives than true positives.

Root Prompt -Intrusion Detection by Lance E. Spitzner -- a simple tcpwrapper based approach.

Your network is being scanned for vulnerabilities. This may happen only once a month or twice a day, regardless, there are people out there probing your network and systems for weaknesses. I can say this with confidence because I have yet to work on a network that has not been probed. My personal network of six systems at home is on a dedicated ISDN line. This network has no valuable data, nor represents any organization, yet I get probed two to four times a week. If you have a system or network connected to the Internet, you become a target. This article will discuss how you can protect yourself by detecting these intrusion attempts. I will then cover what you can do when you discover these attempts.

Setting up Intrusion Detection

The methods we will be discussing are simple in use and implementation. For larger or more security conscientious organizations, you may want to consider third party Intrusion Detection Systems, such as Network Flight Recorder (http://www.nfr.net/nfr). These more advanced IDS systems use traffic analysis and advance algorithms to determine if a probe has been conducted. Our approach will be somewhat simpler.

There are a variety of different probes hackers will attempt. The first type we will prepare for is one of the most common, port scans. Port scans are where an inidvidual attempts to connect to a variety of different ports. The scans can be used on a specific target, or used to scan entire IP ranges, often chosen at random This is one of the most popular information gathering methods used by hackers today as it identifies what ports and services are open.

To detect these scans, we will build a system that emails us alerts whenever someone connects to a predetermined port. First, we identify three to five of the most commonly scanned ports. Then we select two to three systems to listen on these ports. When an intruder scans our network, he will most likely hit our systems listening on these ports. When these ports are scanned, the systems log the attempt, execute various predetermined actions, then email an alert to a point of contact.

[Jun 19, 2000]SECURITY: LinuxSecurity.com: Network Intrusion Detection Using Snort

(Jun 19, 2000, 05:12 UTC) (991 reads) (0 talkbacks) (Posted by mhall) "This document takes you through the basics of intrusion detection, the steps necessary to configure a host to run the snort network intrusion detection system, testing its operation, and alerting you to possible intrusion events."

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Open Directory - Computers Security Intrusion Detection Systems
• Neohapsis Archives SF-IDS
• Firewall, VPN, Intrusion Detection, and Router Tips pretty large site with good links.
• Intrusion Detection Tools -- good up-to collection of links by "Talisker" with a classification and annotations of several products (still uncompleted). He distinguishes the following types of IDS:
  • Host Based IDS / Event Log Viewers
  • Hybrid IDS: Non-Promiscuous with Event Log Viewer
  • Honey Pots
  • Network Based IDS
  • File Integrity Checkers
  • Identifying Ports
• Intrusion Detection System collection of documents
• NSS Group White Papers -- collection of whitepapers from www.nss.co.uk
  • Web Caching - CacheFlow 100
  • NDS Management Utilities
  • Internet Security
• *** COAST Hotlist - Intrusion Detection - Outdated list compiled by Katherine Price Last modified: Sat Jul 18 10:23:49 EST 1998
• Intrusion Detection Primer -- weak, but some links might be useful.
• SANS Institute Online - Home Page
• Intrusion Detection a useful collection of links
• Original list compiled by Mark Crosbie and Katherine Price, COAST Laboratory, Purdue University. Additions from a list and bibliography compiled by Michael Sobirey, Brandenburg University of Technology at Cottbus, Germany. Updated by David A. Curry, IBM Emergency Response Service
• http://www.nswc.navy.mil/ISSEC/CID/ Northcutt's SHADOW project stuff (now free)
• See also NSA Intrusion Detection Tools Inventory
• IDS archives for Intrusion Detection Systems (IDS) Re Audit trails -- useful post
• Re wtmpx utility for solaris
• Unix Network Monitoring Tools -- A simple suite of free security tools that might help to detect and analyze network intrusion. It includes:
  • Argus
  • Courtney
  • Gabriel
  • Netlog
  • NOCOL

FAQs

*** FAQ Network Intrusion Detection Systems somewhat outdated but useful

SANS Intrusion Detection FAQ

Network IDS FAQ by Robert Graham ([email protected].)

firewall-seen FAQ This document answers the age old question "I'm seeing XXXX on my firewall, what does it mean?". It also applies to intrusion detection system, it describes today's most common attacks, why the attacker is doing them, and which ones may be false-positives.

Sniffing/wiretap FAQ Describes how "sniffing/wiretap/eavesdropping" works, which is the technology that IDS is base upon. Also describes how to analyze packets in detail, because when you get attacked, you NEED to be able to pull out a protocol analyzer and look at the attack.

Newsgroups

firewall-wizards Info Page

Comparisons

Network Computing Feature Security Dragon Claws its Way to the Top Page 2 August 20, 2001

The idea behind Dragon is quite simple: It's made by the hard-core, for the hard-core. Veteran security administrators and Unix jockeys will dig it, and most Microsoft Windows administrators will choke on it. Dragon's strengths lie in its deep signature set, its robust engine, and its ability to log and display a dizzying amount of data. Its weaknesses? The Web-based console is difficult to navigate and frustrating to use.

Enterasys is one of the few vendors that can realistically talk about watching over ISP links and other carrier-class networks. The engine is rock-solid, and once you have the sensor set up and talking to the console, it hums along. We ran into a few instances where the communications died, and we needed to log into the sensor to troubleshoot, but compared with the other IDS platforms, Dragon was pretty painless.

Another issue users should consider is the number of signatures they choose to enable. Dragon has an open-signature format that lets users create their own signatures. In fact, it's so well-defined (and similar enough to the Snort signature format) that the Whitehats arachNIDS site exports all its signatures to Dragon format as well. The result is a massive signature set. At one point, we pushed out a very aggressive configuration. The Dragon infrastructure was able to keep up, but we were processing more than 2 GB of data per day! At this rate, we could hold only four days of data before we needed to start clearing out old info.

Enterasys Networks Dragon 4

On the management side, Dragon's Web-based user interface leaves much to be desired. It can be confusing, though using it gets easier after a few days. Another problem is that there are too many different Web-based tools, including Dragon Fire, Dragon Console and Dragon Rider. The consoles are bolted onto the CLI (command-line interface) tools, which are still available by SSHing into either the sensor or the console. Most of the pull-down menus and filterable options are simply flags and arguments that are passed to the back-end CLI commands. The conceptual link to this impressive and powerful array of CLI tools is presented at the top of the queries that are created through the Dragon Fire tool. The display limits on the Web pages and the frequently inefficient methods of finding the right box to supply the desired filter will quickly encourage you to use the CLI. It's raw, but it works.

IDS Test Summary

Summary - Performance Testing

In the performance tests we noticed a range of results from the excellent to the "not so good". We suspect that the Cisco Secure IDS 4210 may well have been suffering from pre-production problems, and it will hopefully be re-evaluated in our labs at some point in the future when the problems have been ironed out. In the meantime, you should evaluate this product carefully under load in your own environment if you are considering purchase.

RealSecure, SecureNet Pro, Snort and Dragon (under Red Hat Linux) all demonstrated some problems with handling detection on a network saturated with 64 byte packets, causing them to miss attacks under load. Both Snort and SecureNet Pro, however, proved themselves to be more than a match for our "real world" tests and would, we believe, perform well on any "normal" corporate network.

Unfortunately, we were unable to re-test Dragon and RealSecure in time for this report. Given that in Edition 1 BlackICE Sentry provided the best overall performance coupled with a small footprint and very low CPU utilisation, we are looking forward to testing RealSecure 7 (which will incorporate the BlackICE technology) for the next Edition.

With the removal of BlackICE as a stand-alone product this year (because of its acquisition by ISS), only Symantec NetProwler and Cisco Secure IDS Model 4230 achieved a 100 per cent detection rate across the board, although NFR's NID-200 gave them a run for their money. The latter two products also represent the only turnkey appliances in our test (although Intrusion Inc. also produces appliances), which may be important to some. When partnered with the netForensics product, Cisco offered some of the best reporting capabilities of all the products on test (although this makes it a very expensive combination). The value for money offered by the excellent NFR product, however, is hard to ignore.

Unfortunately, although it performed well under load, Symantec's NetProwler tended to misrepresent many of the attacks detected and was the only one of the group that was outwitted by our IDS evasion techniques. This product is in need of updating, and we look forward to evaluating it again next year once that has happened.

Of course, performance is not everything. In terms of management and monitoring, and in terms of signature database updates, all of the Network IDS products we have examined leave something to be desired in one way or another.

Ideally, we would be looking for clear and intelligible alerting, and detailed reporting that can be printed directly or exported to a range of output options. An intuitive, easy-to-use interface that makes it simple to manage one or more remote sensors is very important, as is the ability to acquire signature updates automatically and distribute them throughout the organisation at the click of a mouse. The ability to schedule and automate signature distribution may also be useful to many organisations.

Unfortunately, not one product quite manages to combine every one of our requirements – at least not yet. RealSecure continues to be one of the easiest to deploy and configure, and provides excellent real-time alerting and reporting capabilities. Computer Associates' new centralised administration console for eTrust is also impressive, although reporting is limited.

Symantec and nSecure both offer good centralised management capabilities, but are let down slightly by the fact that their interfaces are not always the most intuitive.

Unfortunately, both NFR and Intrusion provide only a one-to-one management console out of the box. At least NFR does offer its Central Management Server as an option, but such a capability has yet to be developed for SecureNet Pro. The latter does have an optional centralised reporting and data mining capability, but no equivalent option for centralised policy distribution and signature update (although automatic signature update via RPMs is available on the SecureNet appliances). This would currently make it the least scalable of the products tested, and we are told that this will be addressed in a future release.

The host-based IDS' were slightly more straightforward, since all performed their allotted tasks well. It is not easy to do a side-by-side comparison, however, since they do not all perform the same set of tasks.

With the current uncertainty as to the ongoing availability of last year's favourite "traditional" Host IDS system – CyberSafe Centrax – it is left to Symantec's Intruder Alert to carry the flag in this area. Although the interface can be a little daunting at first, it is a very powerful tool once it has been mastered.

For those who feel constantly bewildered by the abundance of cryptic information in their Windows Event Logs, LANguard S.E.L.M. is an essential purchase, since it provides a minimal-impact means of consolidating all Event Log information from multiple servers into a central database. It also does an excellent job of explaining the meaning of the log entries.

Tripwire continues to lead the way in File Integrity Assessment, and the product has continued to evolve and improve upon the version we examined last year. Tripwire should always be considered as complimentary to any other host-based IDS you may purchase.

Finally, Entercept is the one product that we would unequivocally recommend to everyone, but especially to those who are forced to run Microsoft Web servers on a public-facing network. Entercept is the only intrusion prevention product we have evaluated, and the ability not only to detect and log attacks, but actually prevent them from happening helps to make systems that much more secure.

Kernel-level agent software helps protect the host against both known and unknown attacks, and the provision of Web Server Agents secures Web server software within an almost impregnable vault where virtually all attacks will be prevented before hitting the server. Whatever other IDS software you buy, try to make room in your budget for Entercept.

Review Intrusion-detection products grow up, 10-08-01

The IDS products from Cisco, Enterasys and Intrusion.com are appliances, while CA and ISS provided software-based systems to test. ISS also offers an IDS appliance through a partnership with Nokia, but we did not test that.

The network-based IDS products consisted of separate "sensoit management and reporting, was included on a separate console.

A variety of sensor platforms are employed, including Windows, Unix, Red Hat Linux and Solaris. With the exception of Enterasys, which uses Web browser access for management, the other products employmanagement server and/or client software. In addition to its Secure Policy Manager application, Cisco Secure IDS is also supported by Cisco Secure Director, which we did not test. This alternative management software runs on Hewlett-Packard's OpenView.

Performance

Several tests were conducted to measure performance. First, we measured how well the product could detect a random sample of commonly recognized intrusion attacks, such as ping floods, Jolt2 attacks, SYN floods, finger bombs and others. These were tested initially under no background traffic load. To achieve a passing score, the IDS had to correctly identify the attack within 5 minutes of the attack's launch. We tallied whether the intrusion was recorded, if it was correctly identified and the approximate time it took to recognize the attack.

Next, we ran stress tests to see how the products would work as background traffic load increased from 40M to 60M bit/sec, then up to 90M bit/sec. If we determined that an IDS could not detect an attack under the "no load" condition, we eliminated that attack from the stress tests. A third test determined whether the products could detect attacks specifically designed to avoid traditional IDS systems.

Performance was scored on three things: number of attacks detected, ability to detect attacks under load (the stress tests) and fault tolerance.

Enterasys' IDS Dragon took the gold in performance. In addition to its excellent showing in the first two performance tests, Dragon also beat the competition by detecting attacks that are specifically designed to avoid traditional IDS systems. IDS Dragon also performed with near bulletproof reliability - demonstrating minimal performance degradation under traffic load and solid system stability all during the tests.

The IDS Dragon missed only three out of 27 random attacks and detected 24 out of the resulting 24 attacks sent to it under the 40M and 60M bit/sec traffic load. With the 90M bit/sec traffic, IDS Dragon correctly detected 21 out of 24 attacks - very good under maximum load.

No other product performed as well with the basic intrusion-detection and stress tests, although Cisco Secure IDS performed well under load, detecting 19 out of 21 attacks sent to it under 40M-, 60M- and 90-M bit/sec loads. The ISS RealSecure performed well under 40M and 60M bit/sec loads, detecting 22 out of 24 attacks, but fell down to 17 attacks out of 24 when the traffic load went to 90M bit/sec.

Intrusion.com's SecureNet Pro had the hardest time under heavy background traffic loads. After a strong start - detecting 24 out of 27 attacks with no load - performance steadily declined as load subsequently increased. The SecureNet detected only four out of 27 attacks under the 90M-bit/sec load. Curiously, SecureNet detected the highest number of attacks (25) under no load, but supported the smallest database of known attack signatures of the products tested.

All the products tested did well in detecting certain attacks - including Whisker (various types), Targa3 and Bind - that are specifically designed to evade network-based IDS products. Cisco, CA, Enterasys and Intrusion.com detected 16 out of 17 attacks, while ISS got them all.

While CA's eTrust IDS performed adequately in our stress tests, it did not perform consistently under high (90M bit/sec) loads. It appeared that the longer we let the background traffic stream run (up to 10 minutes or more) the less consistently the eTrust could detect the attacks. It was for this reason that we rated eTrust's performance a 3 out of 5.

With few exceptions, the products tested were otherwise stable. While the ISS RealSecure was generally stable, its performance was affected in one instance. When we sent 90M bit/sec of traffic over 10 minutes, then launched an extended ping flood for several minutes, RealSecure could not detect any of the Internet Information Server exploits we tried. We also noticed that running a Jolt2 attack seemed to easily blind Intrusion.com's SecureNet for a brief time after the attack subsided.

Managing all this

All the vendors tested made huge strides in their management applications. They all performed well in generating reports, and they all exhibited their ability to adequately manage events and large deployments of IDS sensors.

Managing a large network of sensors is typically achieved through a three-tiered architecture: a central management console, sensors and an event collector that off-loads processing from the management console, but reports back to it. Under this arrangement, one event collector manages, for example, up to 50 sensors, but each management console supports multiple event collectors, thus facilitating scalability. All the vendors except CA have embraced this model. CA doesn't use the event collector, just the sensor and management console.

Cisco and ISS tied for top honors in this category. Cisco's Secure Policy Manager, which runs on Windows NT/98/2000, supports the best event management along with a highly intuitive, logically designed interface that was a breeze to use. Items were color-coded and easily sorted, and we could configure which fields we wanted displayed, easily viewing more (or less) detail, as we specified. The Secure Policy Manager also has excellent reporting and statistics, featuring easy-to-use templates for generating reports. Functions were well integrated into Secure Policy Manager, which is slated to eventually become the single manager platform for all of Cisco's security devices, including its PIX firewall.

In addition to Secure Policy Manager, Cisco supports Unix-based management and an HP OpenView-based platform, running the Cisco Secure Director plug-in, which was not tested for this review. Our only issue was its management of multiple sensors. While powerful, it was a bit cumbersome for us to set up and maintain.

The ISS RealSecure Manager, which resides on Win 2000/NT or Solaris platforms, is on par with Secure Policy Manager, supporting excellent event management, good reporting and the best integration of applications. One of the earlier IDS vendors, ISS has had more time to better integrate functions. Incorporation of a three-tired architecture facilitates management of multiple devices, and sensors are easily deployed.

CA, Enterasys and Intrusion.com were a step below, but were still good in this category. CA's eTrust Intrusion Detection Management, which runs on Win 98/NT/

2000 and Millennium Edition platforms, delivered the best statistics reporting of all five products tested. They were comprehensive and complete. But eTrust's was limited by the use of several different applications that should be integrated. For example, there were separate applications for real-time statistics and detailed monitoring. They would have been more useful if combined. With that, eTrust's management would be on par with Cisco and ISS.

While Enterasys' Web-browser based Dragon Policy Manager had good reports (we especially liked one that let us pick the most common attack and observe it closely) and statistics, its event management wasn't as robust as the other products. Events were displayed but couldn't be sorted, and we couldn't designate which fields to display. We could filter events, but we found this a tedious process. We also found the Dragon Policy Manager difficult to navigate.

However, it included a good forensics tool that let us drill down into the precise details of attacks and analyze them. While all the other products supported a similar feature, Enterasys did it best. Those familiar with Unix will like IDS Dragon's Unix-based command-line interface, which is traditional and familiar. But like CA, Enterasys needs to better integrate its varied application tools to make its management more effective and efficient.

Intrusion.com offers two management applications: the SecureNet Pro, an X-windows management application for Linux-based platforms, and the SecureNet Provider Win 2000-based application, which was developed for better management of larger deployments of sensors. The Windows application is well suited for

larger environments because it employs a three-tired architecture while the Linux application does not. While both are good, they offer distinctly different feature sets, which we found problematic.

Installation and ease of use

All products tested were easier to install and configure than in our previous tests. Overall, the appliances were easier to install than the software-based products because the software-based products also require "hardening" of the platform's operating systems, which turns off unnecessary servers (such as telnet or FTP) that could affect security or performance.

Intrusion.com's SecureNet PDS appliance was the easiest to install. Within 15 minutes, we were up and running with minimal tweaks. The Cisco Secure IDS, an appliance, was also easy to install, but because the product supports so many advanced settings and configurations, it was easy to get lost trying to find things. Also, Cisco doesn't always make good use of screen space. For example, on Secure Policy Manager's General Signatures screen, there's a small window for scrolling through signatures that the user can't expand, although there was lots of available and unused gray space around the window.

Installing CA's eTrust was intuitive and logical, but, as noted, it had too many separate applications, which limited its ease of use. CA says it is addressing this issue for future releases.

Enterasys' initial screen gives the user five options, such as policy configurations and real-time monitoring, but once you drill down into any one area, it's not easy to get back out to another. And because we were working with a Web browser, we had to repeatedly hit the "back" key to return to the main home page and then go forward to another. While it was possible to open multiple windows and switch between them, we found that cumbersome. Unix users will find that setting up the IDS Dragon Sensor through the Unix-based command-line interface fairly straightforward, although Windows users might get frustrated.

ISS's RealSecure software installation took the longest, but still took less than 30 minutes (minus hardening the server). RealSecure had the most logical and intuitive graphical user interface - almost everything we needed to see to install the system was visible on one screen so it was possible to manage devices and events without navigating through different screens. However, we found the RealSecure's "wizards" the least intuitive feature. Instead of stepping us through a process from beginning to end, the wizard presented a list of options for further selection. The wizards would have been more helpful if they were more focused.

Features

All the products supported a full complement of IDS features. With few exceptions, the products supported nearly all the specific features we looked for during our analysis.

Cisco Secure ID supported the largest database of known attack signatures, while Intrusion.com's was the smallest (which didn't prevent the SecureNet from recognizing the highest number of attacks in our random attack tests). Enterasys supported the most granular attack database, providing more details about attacks than the other products. However, some end users just want to know they've been attacked, so it's up to the individual to decide how much detail is a good thing.

Intrusion.com's SecureNet was the only product that did not support automatic update of attack signatures. It requires a manual download and installation of signatures, which forces the administrator to update each remote sensor individually - a tedious process and the main reason SecureNet scored a 3 out of 5 for features.

All the products supported a detailed explanation of attacks, including the Common Vulnerability and Exposures database of known vulnerabilities, and Bugtraq IDs, a Web site on which most security professionals release an exploit once it is discovered (http://www.securityfocus.com/).

All the products also supported a stealth-mode monitoring interface, which lets a network interface card (NIC) see all the traffic so the IDS can analyze it. NICs typically look at media access control addresses and listen only to traffic that is directed to it; software on the IDS puts the NIC into stealth (or "promiscuous") mode so that it can see everything.

Vendors have based their features development on addressing previously known vulnerabilities, such as Unicode detection and TCP reset prevention mechanisms, into their products. Unicode is a uniform coding scheme that allows communication between diverse texts (the current version is Unicode 3.1.1; see http://www.unicode.org/ for specifics). Previously, IDSes could not read Unicode, and attackers took advantage of that vulnerability. A TCP reset lets the IDS send out a spoof packet that terminates a TCP connection instead of telling a firewall to stop all packets.

All the IDSes also now support shunning, or prevention, of attacks, but it is turned off by default, and it's up to the user whether to use it.

Configuration

The Cisco Secure IDS was the bulkiest of the appliances (it is a 4-U appliance; the others were 1-U appliances), and it reported power status and disk activity, but had no link-level LEDs. It was the only product that was not offered as a stand-alone software product (as well as a stand-alone hardware/software appliance).

CA's eTrust, one of the two software-based products tested, had low minimum-system requirements, which might not support enough horsepower for high-speed-link monitoring. CA was the only vendor that did not offer an appliance-based IDS product - software only.

Enterasys offers appliance and software-versions of IDS products. We tested the appliance version, which supports LEDs that were small, recessed, not clearly labeled and hard to read. The IDS Dragon is well architected, though, incorporating a multitiered architecture for improved scalability. However, the event collector runs on the management console rather than on a separate platform, which would better conserve management resources.

Intrusion.com had the most well-designed appliance, with LEDs that were especially useful and easy to read, although there was no power button on the front of the device, which would have been a plus.

The ISS RealSecure, which we tested in software, has the advantage in scalability. RealSecure has distinctly different event collectors, and management is run on a separate machine, leaving it free to use all its resources for management.

Wrapping it up

IDS products have undergone a metamorphosis during the past year, blossoming into sophisticated machines that are easier to install, and incorporate better management and performance. But they could still use improvements in event correlation and management, and their ability to support speeds beyond 100M bit/sec.

Related links

Yocom is senior editor, Brown is lab test engineer and Van Derveer is lab technician at Miercom, a network test lab and consultancy in Princeton Junction, N.J. They can be reached at [email protected], kbrown @mier.com and [email protected].

Intrusion battleground evolves The future of intrusion detection is hybrids of network- and server-based products, faster speeds and improved event correlation and analysis. But prices won't fall.

How we did it Our testing methods explained.

Interactive Buyer's Guide Use our buyer's guide to find the intrusion-detection tool that's right for you. We've got specs on 42 hardware and software-based tools.

Scorecard and NetResults

Network World on Security Sign up for our free e-mail newsletter.

Breaking intrusion-detection news

Big net names push security wares 05/13/02 Cisco, Enterasys Networks and Nortel last week used NetWorld+Interop 2002 Las Vegas to push new intrusion-detection and VPN products, recognizing that network security might be among the few things on which customers currently are willing to spend money.

Air Force goes on net security offensive 05/06/02 The U.S. Air Force is adding firepower to its network defenses by increasing intrusion-detection measures at dozens of bases around the country as the threat of cyberattacks escalates in the post-Sept. 11 age of terrorism.

Network Associates, ISS to gang up on net intruders 05/06/02 Network Associates and Internet Security Systems last week announced an alliance under which they will use each other's technologies and marketing power - an effort spurred by a rise in network security incidents known as 'blended threats.'

N+I - Cisco expands intrusion-detection lineup 05/06/02 Aiming to address the flood of network-borne threats to security from both inside and outside enterprises, Cisco Systems on Monday expanded its lineup of intrusion detection system hardware and software with new devices and management capabilities.

Network Associates, ISS forge alliance 05/02/02 Network Associates and Internet Security Systems have forged an alliance to use each other's technologies and marketing power in what top executives from the two firms say is a three-year agreement with many details still being hammered out.

Portsentry

LinuxNewbie.org: Setting up Portsentry(May 27, 2000) Cork LUG: Security for the dial-up user [Portsentry review](Apr 02, 2000)

BSD Today Deploying Portsentry By Clifford Smith

You can obtain Portsentry from http://www.psionic.com/. Or, if you happen to be doing this on FreeBSD, just go to the security section of your ports subdirectory and cd into portsentry. (Portsentry is also available as a NetBSD package.)

For those of you who download the version from Psionic, after you get it, you'll can type:

gzip -dc portsentry-1.0.tar.gz | tar -xfv -

Then cd into the created portsentry-1.0 directory and type: "make (OS type)". Where the OS type is, (TA DA!), your OS. The types supported are:

• Linux 1.x/2.x
• BSDI 2.x/3.x
• OpenBSD 2.x
• FreeBSD 3.x
• HPUX 10.20
• Solaris 2.6+
• AIX
• SCO
• Digital Unix
• NetBSD

Simply add your OS type -- you don't need the version-- after the make command. Then you install it and get down to business

Configuration

The portsentry.conf file is easily customized, the explanations preceding each of the configuration sections are very clear. There is a README.install file that gives an excellent explanation of what you are doing and why.

Port Configurations

This is the list of ports that you want Portsentry to monitor. The default setting is very good, but I like to set the most paranoid setting I can -- so I simply comment out the defaults and use the "really anal" section just above it.

Note: These are truncated to save space.

# Un-comment these if you are really anal:
#TCP_PORTS="1,7,9,11,15,70,79,80,109,........32771,32772,32773,32774,31337,
40421,40425,49724,54320"
#UDP_PORTS="1,7,9,66,67,68,69.......32774,31337,54321"
#
# Use these if you just want to be aware:
TCP_PORTS="1,11,15,79,111,119,143.......40421,49724,54320"
UDP_PORTS="1,7,9,69,161.......32771,32772,32773,32774,31337,54321"
#
# Use these for just bare-bones
#TCP_PORTS="1,11,15......32771,32772,32773,32774,49724,54320"
#UDP_PORTS="1,7,9,69,161,162,513,........32774,31337,54321"

The list of ports can be any that you'd like, as long as they are inside a quoted, comma-delimited line with no spaces. Be careful. If you happen to add port 80 to the list (as is already the case in the "really anal" ports list), anyone who tries to get to your brilliant ecommerce site will be locked out altogether -- not so good for the sale of goods 'n services. All you'd have to do in this particular case is remove port 80 and its comma from the list and check for additional ports that you'd like to not have tracked.

Advanced Stealth options Note: The advanced stealth options are available in Linux systems only. This is here for your information.

This is actually more paranoid than the settings above; it ignores the port lists and simply blocks all traffic below port 1023 that aren't bound already. You can increase the value, but this is of dubious utility as the number of false alarms will probably increase.

Advanced_exclude

A list of ports that you know you are going to need to have unprotected if you are going the advanced stealth route. There are a couple of examples in the file and I would imagine that the astute observer can add a couple more. I would be wary of adding ports like port 23 (telnet) to this list just so your boss can log in, though.

Configuration files

These paths are where the default installation will place the following three files.

• Ignore_file -- The file where you might list IP numbers of machines you allow in, unmolested. This, for me, is a very short list.
• History_file -- This is a running history of banned addresses that have been tied to knob-rattling in your piece of the network.
• Blocked_file -- This file is a list of addresses that have been banned just since portsentry was activated, this time around.

Response Options

You can Ignore (allow all) by TCP or the UDP protocol -- or block them both, the default behavior. There are reasons you might want to have portsentry ignore the UDP protocol. One of them being that it is possible for the script kiddie to forge a bunch of UDP addresses to send your way; and if they forge enough of them, you block legitimate traffic. Use of a packet filter, like IPFilter, can allow the creation of rules concerning UDP that removes the need for UDP blocking. If you do turn off UDP blocking, the ports are still listened to and logged.

The TCP block is fired up when a full connection is made and so it is harder for a single malcontent to forge addresses en masse like UDP.

You can also automagically drop offending ip addresses into your local filter table -- or route them to the routing equivalent of /dev/null. Honestly, I have never been motivated to the point that I ever tried this option. The default blocking file setup seems to work exceptionally well.

External Commands

This is the path to the potential retaliation script -- the least recommended option here. If someone has cracked a sporting goods' website and is probing you from there with Nmap, for instance, and you retaliate by hammering the offending site, you just let the script kiddie know that they can have a fun time at your address. Better to use the default I-just-disappeared, black-hole-automated banning of an address. At least until they develop a way to traceroute directly to the kiddie and deliver a small nuclear payload.

At this point you should be ready to go. Fire up "portsentry -tcp" and then look at your /var/log/messages. What you should see is something like this:

portsentry[14604]: adminalert: Psionic PortSentry 1.0 is starting.
portsentry[14605]: adminalert: Going into listen mode on TCP port: 1
portsentry[14605]: adminalert: Going into listen mode on TCP port: 11
portsentry[14605]: adminalert: Going into listen mode on TCP port: 15
portsentry[14605]: adminalert: Going into listen mode on TCP port:79

Ending with:

portsentry[14605]: adminalert: PortSentry is now active and listening.

You're good to go. Now go to another machine and have some real fun with your logs -- run Nmap against the machine and watch the "Attackalert" messages get logged:

Jul 16 19:06:34 mail portsentry[14605]: attackalert: Connect from host:
 bauhause.com/2xx.644.39.146 to TCP port: 15
Jul 16 19:06:34 bubba portsentry[14605]: attackalert: Host 2xx.644.39.146 has been
 blocked via wrappers with string: "ALL:2xx.644.39.146"

See for yourself that the offending host is dropped into the /etc/hosts.deny file. Actually you can do the same just by attempting to telnet into a protected port -- 15 is the one I used in the example above.

Next time I'll discuss Logcheck -- the companion program to Portsentry and a pretty good reporting tool as a standalone, too. And as I said earlier: use a good IPF-based firewall coupled with Portsentry and Logcheck and you might not spend as much time biting your lip over the security of your computers

FOCUS on Linux Intrusion Detection on Linux

The first layer of protection behind the firewall is a software package that will monitor incoming attempts to connect to the machine. The PortSentry package (http://www.psionic.com/abacus/portsentry/) provides a simple and effective method of doing this.

PortSentry is a program that monitors activity on specific TCP/IP ports. Activity on the ports that are monitored by PortSentry is reported, and one of several options can be taken, including denying further attempts to access to your system from the source of the activity. This is an important defense mechanism, because a hacker will typically probe your system for weaknesses ("port scanning") before attempting an intrusion. Detecting the probe or port scan, and completely denying further access to your system by a potential hacker, robs that hacker of the ability to follow up on any port scans with a real intrusion attempt.

For users of Red Hat Linux, PortSentry is available in RPM format on the Red Hat contrib FTP site...For other Linux systems, installing PortSentry from the source code is relatively simple.

PortSentry runs in a number of modes, including various TCP and UDP stealth modes. The mechanism that I prefer to use for running PortSentry is to bind it to a TCP port that (a) is not in use, and (b) is known in some systems to have potential for intrusion attempts. For example, port 143 (imap2), port 111 (portmap) and port 23 (telnet) are TCP ports that I do not use on my internet systems, and my web server was scanned on both of those ports in the last 24 hours.

To start PortSentry in basic TCP mode, ensure that your system start-up scripts run this command somewhere:

portsentry -tcp

Also, ensure that the PortSentry config file (portsentry.conf) contains a TCP_PORTS line enabling scanning on the ports that you require.

Response Options

The "Response Options" section of the portsentry.conf file allows you to specify what response that PortSentry will take on detecting unwanted activity. The mechanism that I normally choose is to use ipchains to block further access from the source of the activity. This is done by uncommenting the following line in the portsentry.conf file:

KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"

On systems that receive a high level of port scanning activity, removing the "-l" at the end of the above line will prevent logging of further incoming connections, which might be useful to save space in the log files.

Monitoring System Logs

Firewalling systems, and software like PortSentry perform one useful function, in that they monitor and prevent connections coming in to unwanted ports on the system. This can prevent access to a system via a standard scan-and-intrude method.

Where a system is required to run a particular service (eg: Apache on a web server, or BIND on a DNS server), and a hacker has uncovered a particular loophole in the service, these programs will unfortunately not achieve the result of keeping all intruders out of the system. A system acting as a DNS server that has a vulnerable copy of BIND running on it will eventually be discovered by a hacker that scans a wide range of machines for a single port (the DNS port) on each machine, and attempts intrusion against that port only. The firewall and PortSentry will unfortunately see this intrusion attempt as a legitimate access to the system.

Welcome to Linuxnewbie.org Wanna learn linux NHF's Intel Based Security

Cork LUG- Security for the dial-up user [Portsentry review]

LinuxPR- Progressive Systems Announces Free Givaway Of Linux Firewall

Shadow

SANS puts Shadow in the public domain

Commercial

AXENT Products : NetProwler -- Dynamic network intrusion detection.

With NetProwler you can:

• Continuously monitor user actions
• Monitor security in real-time
• Manage network-wide response

USENIX ;login - intrusion-detection systems

CyberCop, originally produced by Network General, is an IDS recently released by Network Associates <www.nai.com>, an organization that is constantly at work acquiring technologies in the field of security. After their acquisition of Network General's product, Nai made some changes to CyberCop. (It must be remembered that the auditing/scanning software now called CyberCop Scanner -- also known as Ballista -- is different from the totally software-based product we are discussing here.)

Installing CyberCop does not require the network to be reconfigured or plug-ins to be added. Like other IDSs, CyberCop builds a layer of additional software which works by monitoring the ports and services enabled by the firewall.

The first version of CyberCop, announced in 1997, consists of two elements, the management server and the sensors. The latter are positioned at strategic points on the network and communicate any suspicious events to the management server. These events are classed according to a set of 170 different attacks.

If an attempt is made to access the network, the product, currently called CyberCop Server, informs the security administrator in real time, providing a detailed report of the event. The designers feel that within a few minutes CyberCop can give the input the security manager needs to take the necessary steps to resolve the problem. Management of the configuration of CyberCop, as well as the receiving and transmitting of the intrusion detection reports, can take place from a remote location using an encrypted link, which is activated only after recognition of the parties.

Of course, all the traffic monitored is stored in log files which can be consulted at any time by the security manager, both in order to trace the attacks and in order to take subsequent legal action. Configuration and positioning of the sensors are simplified by a preconfigured installation set, which makes operation easier and enables leaks to be limited.

Bro

Bro is a realtime IDS devised and developed by Vern Paxson and other experts at the Network Research Group of the Lawrence Berkeley National Laboratory. The source code of Bro is freely available, and the principle on which it is based is decidedly in an academic mold. With its spartan interface, indicating that greater attention has been paid to substance than to appearance, Bro bases its operational capacity on its scanning speed, realtime notification of violations, and a clear separation between the engine, the policy implemented, and the extensibility options.

Bro is partitioned into two components: the "event engine," which translates the traffic intercepted at kernel level into high-level events, and the "policy script interpreter," which defines the policy implemented, always by means of specific instructions written in a proprietary language. In this way, administrators can use the granularity of this IDS to adapt the system to their own requirements. The services monitored on a priority basis by Bro are Finger, FTP, and Telnet. In addition, the Portmapper function of this solution makes it possible to check the activity of the single ports as well.

So far we could say that there is nothing new. All network analyzers (or net sniffers, if you prefer), and therefore all IDSs (which can be considered extensions of them) are normally equipped with these features. The designers of Bro, however, state that during the analysis period they studied in depth the typology of both standard attacks and those that can be brought to bear on the screen in the narrowest sense, and that they were able to identify and describe attacks not referred to in the literature. Again, during the prebuilding phase the designers acquired substantial experience with systems based on offline analysis of tcpdump attempts. All this has given rise to a melting pot of reference information for subsequent implementation of the modules of this IDS.

One of the main objectives of Bro is to ensure traffic speed. In order to do this, Bro monitors DMZ links. These are usually FDDI, so that the monitor must be able to inspect the traffic, which is very bulky in itself, at speeds in excess of 100 Mbps.

Bro's separation of the engine from the rest of the modules, including the script policy interpreter, is essential to streamline the monitoring operations as much as possible (which means no degradation of network performance) and to distinguish the data on the basis of the services to which they belong. All this has been implemented in order to give Bro maximum flexibility. (Flexibility is more or less the reason why the manufacturers of virus-detection programs are revolutionizing the way they are developed. Attacks are becoming increasingly numerous and diversified, and they depend more than ever before on flaws in individual operating systems and their layouts, so they are increasingly well-targeted and unforeseeable. In this context, modularity and extensibility are strategic and can only be achieved if the architecture used is as open as possible.)

More information about Bro may be found at <http://nrg.ee.lbl.gov/nrg/papers.html>.

ISS RealSecure

ISS RealSecure for Windows NT by Internet Security Systems <www.iss.net> is one of the best known and best-selling IDSs on the market. (Indeed, ISS and CheckPoint have joined in partnership to bundle Firewall-1 and RealSecure together.) The basic operating principle is common to the other IDSs: The traffic passing through is monitored, and the activities are compared with the pattern with which it is outfitted. In the event that they match up, an alert is activated and possible automatic countermeasures are implemented.

Suspicious activities, documented with information concerning the chronology of the attack, its source, and destination -- plus other data to be selected -- can be managed extremely dynamically. Monitoring of the traffic consists above all of packet filtering. It is possible to configure RealSecure to check traffic in all its meanings: TCP, UDP, ICMP, source and destination ports, etc. It is also possible to check the traffic on the basis of the services used because the pattern of the attacks follows this schematic distribution.

The designers of ISS used this philosophy: Starting from the assumption that most attacks come from inside, the administrator needs a product able to check all the traffic (not only the traffic permitted by the perimeter security system). In addition, a check of the activity permitted by the firewall is also indispensable, since even an authorized user can "penetrate" a system.

The security policy set up by RealSecure therefore has the objective of checking and identifying beforehand:

• who can access the system and who cannot
• which protocols and/or services are permitted
• which new hosts are added to the network and what rights they have to "dialogue" with the rest of the infrastructure.

Starting from these assumptions, a series of features in Real Secure are aimed at making the work of the administrator as easy as possible and the system as flexible as possible.

NID

NID 2.x is an intrusion-detection suite available freely on the Web <http://ciac.llnl.gov/ctsc/nid/> for various operating systems, including LINUX, but its use is limited, for the moment, to government organizations.

NID works in a manner similar to Bro. It can monitor speeds and layouts, including FDDI and, of course, all IP traffic. NID has these features:

• The software is installed on a dedicated machine.
• A security domain is formed from the management console. In turn, this includes a series of hosts at the discretion of the operator.
• NID starts to audit the network traffic using three fundamental methods.
• Attack-signature recognition
• Vulnerability risk model, i.e., general safety parameters to be observed
• Anomaly detection, i.e., recognition of abnormal behavior inside the network and immediate notification of the system administrator

In NID, too, the analysis model and its operational expression are of the mainly "passive" type; traffic is audited and a consequent comparison with the attack pattern at disposal is made. If a match is found, an alarm is sent to the security administrator.

The software permits sessions of specific UNIX tasks, such as cron, to be run.

Port Scan Detectors

Shadow Scan Home pages contain ShadowPortGuard detects connects to ports

Autobuse

http://www.picante.com/~gtaylor/autobuse/ Grant Taylor - January 11th 1999, 19:04 EST

Autobuse is Perl daemon which identifies probes and the like in logfiles and automatically reports them via email. This is, in a way, the opposite of logcheck in that autobuse identifies known badness and deals with it automatically, while logcheck identifies known goodness and leaves you with the rest.

---

PortSentry

Download:	http://www.psionic.com/tools/portsentry-0.90.tar.gz
Homepage:	http://www.psionic.com/abacus/portsentry/
Changelog:	http://www.psionic.com/tools/portsentry.CHANGES

Detects and responds to port scans against a target host inreal-time. Jun 26th 1998, 19:36 stable: 0.90 - devel: none

PortSentry is part of the Abacus Project suite of security tools. It is a program designed to detect and respond to port scans against a target host in real-time. It runs on TCP and UDP sockets and works on most UNIX systems. Advanced stealth detection modes are available under Linux only and detect SYN, FIN, NULL, XMAS, and Oddball packet scans. All modes support real-time blocking and reporting of violations.

FakeBO

Download:	http://cvs.linux.hr/fakebo/fakebodl.html
Alternate Download:	ftp://ftp.linux.hr/pub/fakebo/
Homepage:	http://cvs.linux.hr/fakebo/
Changelog:	http://ftp.linux.hr/pub/fakebo/changelog.txt

FakeBO fakes trojan server responses (Back Orifice, NetBus, etc.) and logs every attempt to a logfile, stdout/stderr or syslog. It is able to send fake pings and replies back to the client which is trying to access your system.

Abacus Sentry

Detects the use of a port scanner in real-time. Availability and Additional Info: Abacus Sentry

Courtney

A program that tries identifies the use of SATAN on a subnet. The program tcpdump will also be needed in order to run Courtney. See below for information about tcpdump. Additional Info: CIAC Notes 08

Klaxon

A daemon that is used to identify the use of port scanners like ISS and SATAN.

Scan-Detector

Determines when an automated scan of UDP/TCP ports is being done on a host running this program. Logs to either syslog or strerr. Additional Info: COAST Projects' Tools

sentry-0.61-1

A security tool designed to detect and stop port scanner programs in real-time. Linux/i386 sentry-0.61-1 Stop port scanners like sniffit

sockscan

Sockscan runs in the background of your Linux system looking for ICMP Floods, TCP/IP Port scans, Back Orifice pings, DoS attacks, and more. It can log to file, system log, or even connect to your mIRC client on a remote machine. Sockscan requires root privileges to open the Ethernet device in raw mode.

ftp://dustball.com/pub/sockscan/sockscan-1.0.tar.gz

Related Tools

Argus

A powerful tool for monitoring IP networks. It provides tools for sophisticated analysis of network activity that can be used to verify the enfforcement of network security policies, network performance analysis, and more.

Arpwatch

An ethernet monitor program that keeps track of ethernet/IP address pairings.

Icmpinfo

Displays unusual ICMP messages received by a host. This can be used to detect suspicious network activity. Additional Info: icmpinfo man page

Netlog

Network logging and monitoring of all TCP and UDP connections on a subnet. Netlog also includes tools to analyzing the output.

Rscan

A extensible network scanner that checks for common network problems and SGI specific vulnerabilities. Additional Info: Rscan: Heterogeneous Network Interrogation

iplog 1.4 -freahsmeat Maruchanda Vishitu - March 01st 1999, 13:35 EST

http://www.ojnk.org/~eric/ -- iplog is a collection of daemons that log tcp, udp, and icmp traffic. It has features not available in other traffic logging programs, including detecting 'stealth' scans used by port scanners such as nmap, protection against SYN floods, and logging of remote userinformation. Changes: Fixed strange byte ordering problems, added some things to avoid a port scan DoS, now logfile can be specified. Consider this the final version.

Commercial Tools

NFR

NFR Security

NFR eases intrusion detection

ESTABLISHING a secure perimeter around an enterprise in today's lightning-fast business environment is formidable. The challenge of maintaining security is further exacerbated by the need to defend a network against intruders and malicious employees. You can't rely solely on a firewall for perimeter security and internal compartmentalization: You need to shore up your defenses with additional advanced security technologies, including intrusion detection (ID). Because a denial-of-service attack can render your servers and routers useless, you can measure the value of an ID system in lost revenue and the cost of downtime. Subtle attacks that would go undetected without ID could result in the loss, disclosure, or destruction of sensitive corporate data. Network Flight Recorder (NFR) Intrusion Detection Appliance (IDA) 4.0 is a powerful network monitor. This ID system operates similar to a misuse-detection system in that it looks for traffic patterns that match a known attack and can be configured to look for policy breaches. You can write a filter to set off an alarm when NFR IDA detects an unusual number of Telnet log-in failures. It also performs anomaly detection and will issue alert messages if any unusual network traffic is encountered.

Several ID products are on the market, including Internet Security System's RealSecure, Network Associates' CyberCop Monitor, and Network ICE's BlackICE Pro and Sentry editions. Similar to virus-detection software, all good ID systems offer upgrades as capabilities of detecting attacks are developed. NFR IDA is as capable and extensible a network-monitoring product as any available. Most ID systems run on Unix or Windows NT, but the NFR IDA software (boot code and program logic) is booted directly to an Intel PC-based monitoring appliance from the distribution CD-ROM, and the hard drive is used to store ID databases. I liked the rack-mounted system's tamper-proof features, including removable drives and power and reset buttons protected by a lock and key. And the appliance offers some very desirable software security characteristics: There is no OS or file system for hackers to breach, and they can't install Unix, NT toolkits, or Trojan horses. Also, you won't have to harden the host on which the ID software runs. I deployed a stand-alone configuration of NFR IDA on a LAN containing a proxy firewall, a Linux Web server, and PCs running Windows 95 and NT.

Installing and configuring the NFR IDA software on the monitoring appliance and the administrative console on an NT workstation took 12 minutes. To select administration and configuration, alert viewing, and package subwindows, there is a task bar on the GUI console. "Package" describes sets of back ends or event-monitoring and -recording engines, at which each back end's behavior is directed by filters. A pop-up window reports alerts in real time. From the package's subwindow, you can query the extensive data logged and recorded by individual back ends. Like all good monitoring systems, NFR IDA has many knobs to control the kinds of events to monitor. I ran a series of scans and attacks using Network Associates' CyberCop Scanner and penetration testing tools, downloaded from www.securityfocus.com. Using only default settings, NFR IDA alerted me to all but two of the intrusions: a subtle BackOrifice PING and an SNMP-walk issued to my broadcast IP address using the PUBLIC community string. You can write additional filters to detect these attacks and more in N-Code, the vendor's proprietary event-driven language. NFR also incorporates N-Code filters developed by L0pht Heavy Industries into packages and back ends.

Eventually, NFR plans to offer more than 1,000 L0pht filters for upgrade and download. I tinkered with some early versions, including one that alerted me when a legitimate FTP user attempted to access restricted directories, files, and commands. Filters demonstrate ways to incorporate security policies into ID monitoring. If I could ask for one improvement to NFR IDA 4.0, I would like the alert messages to provide more granularity through a combination of discerning message types and explanatory descriptions. Isolating the nature of some of the attacks may take some time. For instance, NFR IDA detected all of CyberCop Scanner's test scripts directed at port 80 of my system under siege but lumped them into a single Possible Attack URL alert message. NFR IDA is simple to install, competitively priced, highly customizable, and offers a broad range of ID monitoring and reporting capabilities. If you're feeling underfortified and outgunned, NFR IDA is definitely worth a look.

David Piscitello is a principal consultant at Core Competence, in South Carolina.

NFR Intrusion Detection Appliance 4.0

SUMMARY Network Flight Recorder (NFR) introduces advanced intrusion detection (ID) in a security appliance. It has a clean, intuitive GUI, and NFR's scripting language lets you develop custom ID filters.

BUSINESS CASE NFR adds ID to an enterprise security arsenal, with minimal overhead. This appliance is much easier to install, configure, and maintain than competing ID software for Unix or Windows NT host systems.

PROS

+ Easy to administer

+ Encrypted channel between console and PCs

+ Very good logging, reporting features

+ Scripting language for custom-filter development

CONS

- Cumbersome package installation

- Alert message not sufficiently granular

Subject: Re: NFR vs. RealSecure Recommendation From: Bob Davidovich ([email protected]) Date: Thu Sep 14 2000 - 00:55:10 CDT

• Next message: Marcus J.Ranum: "Re: NFR vs. RealSecure Recommendation"
• Previous message: Hervé Debar: "Re: NFR vs. RealSecure Recommendation"
• In reply to: Igor Gashinsky: "Re: NFR vs. RealSecure Recommendation"
• Next in thread: Mordechai Ovits: "Re: NFR vs. RealSecure Recommendation"
• Reply: Bob Davidovich: "Re: NFR vs. RealSecure Recommendation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

Peter,

It's because of this very *same* reason that I do not and will not use NFRor ISS. Not to mention that NFR has consistantly returned a *higer* level of false positives than Dragon at all traffic loads with the testing that I've seen done on it as well as testing that I've done myself in my lab. ISS is much better than NFR for false positives but still not as good as Dragon. Security Wizards are also able to get their updates out for Dragon ALOT faster than the updates for NFR are released and their updates are more comprehensive. Security Wizards *DOES* listen to its customer input. Another plus of Dragon is that it was designed from the beginning to have a high level of I/O in the sensor/analyzing engine, based on the performance that I've seen by using it. Bottom line is that their code is better, period. Not to mention that Dragon will do GigE :) What turned me on to Dragon was a discussion with a *well known and well respected* leader in the IDS field at a security conference last year, who I will not name because I don't want to subject him to the press*, who told me that if he was to go into battle tomorrow he would choose Dragon.

My opinion of NFR as a viable NIDS has further been lowered recently by suggestions(accusations), made by Marcus Ranum at his keynote speech at this years' Blackhat briefings. That the the people in the security community that develop network auditing/testing tools are *directly* responsible for the massive increase in the amount of security violations that have been occuring over the past year. I'm sure that he had certain developers of NMAP and Hping in mind when he attempted to flame. The full extent of my personal opinions of his comments I will keep off this list, it's not the place for it. Peter I would suggest that you look to another NIDS for your needs. Technically, NFR will do nothing but disappoint you.

Bob Davidovich

At 02:57 PM 9/13/00 -0400, you wrote:
> Peter,
> We have done some heavy testing of the NFR IDS here, and had it in a
> bakeoff with Dragon. NFR would drop packets at 22Mbps, and would
> essentially die when the traffic got to 30Mbps sustained for over 30
> mins. We were using their appliances (the fastest they had at the time
> with the 733Mhz chip), and every day at around noon (peak traffic) the
> NFR appliance would go into 66% packet loss, and generate alarms like
> crazy, because it could not see 2/3 of the traffic. NFR suggested a
> TopLayer switch, but why would I want to spend next to $150,000 per
> 100Mbps link, when I could get a
> $15,000 Dragon that would do the job
> just as well.
> Additionally, NFR's interface was not targeted at somebody who "knew
> IDS", but instead was aimed at somebody who did not know the difference
> between portscan, and a hostscan, and did not support "drill-down"
> capability that many people concider vital (ie click on the alert to
> pull up raw packet data about it). Also, in order to collect raw packet
> data, you had to enable one of the plugins that they had us disable for
> "performance reasons". I would really not suggest either NFR or ISS if
> you are going to maintain a constant 30+Mbps traffic flow, but perhaps
> you should looks into either Dragon Sensor (www.securitywizards.com), or
> BlackICE Sentry (www.networkice.com).
> >-Igor
> >"Stephenson, Peter" wrote:
> >
> > Some months ago NFR came out with (I believe) a side by side with
> > RealSecure. One of the points they made (I have not had time to verify
> > this) was that RealSecure would drop packets on a 100Mbps switched segemnt
> > while NFR would not... I believe I recall that NFR claimed that the packet
> > dropping for their product began about 140Mbps....
> >
> > Does anyone recall this (a reference to a doc would be nice) and does > anyone
> > (including reps of both companies) want to comment?
> >
> > --P
> >
> > ____________________________________________
> > Peter Stephenson, CPE, PCE
> > Director of Technology, Global Security
> > Netigy Corporation
> > Phone: +1-248-760-1152 - Fax: +1-248-373-9130
> > PGP Public Key Available At:
> >
> > http://certserver.pgp.com:11371/pks/lookup?op=get&search=peter.stephenso
> > n%40netigy.com
> > If you keep heading in the direction you've always headed, you'll end up
> > where you've always been.
> > http://www.netigy.com Driving eBusiness PerformanceSM
> >
> > > -----Original Message-----
> > > From: Mordechai Ovits [mailto:[email protected]]
> > > Sent: Tuesday, September 12, 2000 9:53 PM
> > > To: [email protected]
> > > Subject: Re: NFR vs. RealSecure Recommendation
> >
> >
> >
> > > On Tue, Sep 12, 2000 at 03:24:18PM -0500, Brent Stackhouse wrote:
> >
> > Hello,
> >
> >
> >
> > I've used ISS RealSecure in various
> >
> > environments since 1x and I'm seriously
> >
> > considering NFR as a replacement. My
> > > > problems with RealSecure include it's
> >
> > lack of packet reassembly,
> >
> >
> > Packet reassembly is in version 5, which has been out for
> > > little while.
> >
> >
> > > high rate of false positives,
> >
> >
> > Yeah, the default engine policies are a bit too "chicken
> > > little". But with
> > > some scrubbing, false positives are less of an issue. It
> > > never goes away
> > > fully though. >
> >
> >
> > lack of customizability,
> >
> >
> > RS 5 has some regexp code to allow for greater flexibility.
> > > Still, it's
> > > nowhere near as flexible as I'd like.
> >
> >
> > You'll be glad to know that customizability is a major part
> > > of the next
> > > revision. I've seen what we're working on and it's nifty.
> > > Of course if I
> > > so much as *hinted* at what it was... :-)
> >
> >
> > > and the necessity to harden the
> >
> > machine on which the engine resides.
> >
> >
> > This is true. Not really avoidable, given that it installs
> > > on winnt and
> > > solaris. However, there is a nokia hardware RS engine. I don't know
> > > enought about it to comment on it. Call one of our sales guys. :-)
> >
> >
> > > Being able to intelligently cull through
> >
> > and report on the gobs of data that IDS's
> >
> > tend to generate is critical and I'm
> >
> > concerned that I'll be stuck trying to
> >
> > create my own data warehouse and reports.
> >
> >
> > RS, by default, stores its data in an MS Access database.
> > > You can shift it
> > > to SQL Server if you'd like. This give a LOT of flexibilty
> > > in reporting,
> > > even if the flexibility this provides is mostly of the
> > > do-it-yourself variety.
> >
> >
> > Also, there is a tool to grab the data off the engines into a comma
> > > seperated values text file.
> >
> >
> > I hope that was helpful,
> >
> > > > Mordy Ovits
> > > --
> > > Security Consultant
> > > Internet Security Systems, Inc.
> >
> > >-- >Igor Gashinsky >Sr. Network Engineer >HotJobs.com, Ltd.

****** Do not meddle in the affairs of network admins, for they are subtle and quick to anger......

Subject: Re: NFR vs. RealSecure Recommendation From: Marcus J.Ranum ([email protected]) Date: Thu Sep 14 2000 - 10:38:20 CDT

• Next message: Marcus J.Ranum: "Re: NFR vs. RealSecure Recommendation"
• Previous message: Bob Davidovich: "Re: NFR vs. RealSecure Recommendation"
• Maybe in reply to: Brent Stackhouse: "NFR vs. RealSecure Recommendation"
• Next in thread: Elliot Turner: "Re: NFR vs. RealSecure Recommendation"
• Next in thread: Marcus J.Ranum: "Re: NFR vs. RealSecure Recommendation"
• Maybe reply: Marcus J.Ranum: "Re: NFR vs. RealSecure Recommendation"
• Reply: Elliot Turner: "Re: NFR vs. RealSecure Recommendation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

> product info) is that it's cheaper than > RS, supports decode customization and > packet reassembly, is available on an > applicance with a hardened OS

A few clarifications - it's not a "hardened" OS in the sense that many people talk about. Usually they mean "we took the compilers and a few things off." The OS in the NFR appliance is basically a bootstrap loader, filesystem and a mini-kernel; all the code running in user space is ours. So there's no password files, no shells, no cron, no named, one of that stuff. It also boots directly from the CDROM and and uses the hard disk only to store data and configuration information. This helps a lot with security as well as installation and management. Want to upgrade the software in your NFR? Pop the CD out and put a new one in, then cycle the power. Having a tamper-proof boot medium is also a nice feature.

Install time is basically nil; you plug it in, turn it on, it asks you if it's OK to zap the disk, then installs and is running. You have to enter a crypto key for remote administration and an IP address and that's it. No installing NT. No installing Solaris. No getting hacked with the next NT security hole. My mom's a professional musician (not a network admin) and it took her under 15 minutes when we benchmarked our install process. NFR can be installed and managed by a secretary instead of someone who makes $80,000/year.

We call it the Intrusion Detection Appliance(tm) or IDA, so I'll use that abbreviation from here on.

> but > doesn't have a centralized manager/ > reporting module to bring the sensor > data together.

Actually, it always has had a central/remote topology built into it. Back when we used to make the "research version" of NFR, all that stuff was not part of the distribution, so perhaps that's where you're confused.

NFR IDAs can report (automatically) to an NFR central. They can also download new filters automatically, etc. All communications are encrypted and bidirectionally authenticated. Our remote user interface (a Win-32 app) can be used to (encrypted) query either IDAs directly or to query the NFR central and browse data from all IDAs that report to it. All alerts can be automatically forwarded to the central for dispatch.

In version 5.0, which is at the CD duplication shop right now, you can ha eway process running on the central which automatically feeds data into an ODBC database, and we also have a Windows App that can run on a Windows system that periodically queries an IDA (or NFR central) and feeds ODBC through the Windows layer. Then you can do all the fancy reporting you could possibly desire. There's also a PERL interface, if you prefer that route.

> Being able to intelligently cull through > and report on the gobs of data that IDS's > tend to generate is critical and I'm > concerned that I'll be stuck trying to > create my own data warehouse and reports.

I'm with you on that! :)

mjr.

[email protected] writes:

> Of course, since signatures are a big vendor secret, investigating these false alarms is more
>difficult for the operator.

They don't have to be. NFR doesn't hide our signatures; the N-code is included with the IDA. If you can read PERL you can pretty quickly understand N-code. We've had lots of customers tweak our filters to do what they want and/or to monitor things specific to their networks.

Personally, I can't understand why anyone would want an IDS that they couldn't program. Then you're at the mercy of a vendor's filter release cycle and there's no way to localize anything.

mjr.

Bob Davidovich writes:

> Not to mention that NFR has consistantly returned a *higer* level of false positives than Dragon at all

One of the bummers about intrusion detection is that if you try to detect more "marginal" events you're more likely to get false positives. We've tended to be pretty aggressive about looking for attacks with our filter-sets - consequently we might have more false positives than an IDS that doesn't look as carefully at what's going past.

> Security Wizards are also able to get their updates out for Dragon ALOT faster than the updates for NFR are released

Thanks for the lob. ;)

We're releasing 5.0 in a very short time. It has completely re-tuned N-code filters, which reduce a lot of false positives while improving performance considerably. 5.0 also has a feature for real-time filter streaming, so your NFR will check our web site for new filters at specified intervals and let you choose which ones you want to download. We've got a whole team of N-code analysts working real-time on filters, and should be able to shorten our response time on attacks into the next-day range.

We're completely psyched about this capability; I know you will be, too.

> My opinion of NFR as a viable NIDS has further been lowered recently by suggestions accusations),
> made by Marcus Ranum at his keynote speech at this years' Blackhat briefings.

Gee, getting a bit personal, there, aren't you?

You can disagree with my opinions all you like, but whether or not you agree with me about issues of ethics in computer security, it's got nothing to do with whether we know how to build a butt-kicking IDS!!!!

By the way, for anyone who cares about what I said and how I feel, there are a few articles on: http://pubweb.nfr.net/~mjr/usenix/index.shtml including an MP3 of my Black Hat keynote on: http://pubweb.nfr.net/~mjr/usenix/blackhat-2000- keynote.mp3

> Technically, NFR will do nothing but disappoint you.

I'm sorry I hurt your feelings, Bob. Please stick to the technology, though, and keep personalities out of it.

mjr.

Etc

End of Life Announcement: RealSecure Guard (All Versions) - 04/30/04 discontinuation notice

Network Magazine ISS' Proventia Enterprise Security Platform January 1, 2005 ISS bets the farm on virtual patches and tighter integration with network operations tools. By Andrew Conry-Murray

Claim: ISS is moving from detection to prevention, emphasizing virtual patches that protect against complete vulnerabilities rather than individual exploits. The company is also touting the integration of security and network management tools.

Context: The growing threat from worms and malware is spurring every major security vendor to add prevention technologies to its portfolio. At the same time, it's now essential for security products to integrate with network management and trouble ticketing tools.

Credibility: ISS' X-Force team gives the company an advantage in vulnerability discovery and analysis, as well as in creating virtual patches. On the downside, it isn't clear how ISS will integrate its security products into an enterprise network and systems management architecture.

---

These days, networks are under increasing pressure from automated worms and other malware. Defense systems that can detect and block these attacks are now essential. At the same time, security and network management functions are beginning to spill over traditional organizational and operational boundaries, forcing network architects to find ways to fit security tools into a network operations framework.

Internet Security Systems (ISS) believes it can relieve these pressures with the Proventia Enterprise Security Platform (ESP). Part blueprint and part manifesto, Proventia ESP outlines how the ISS product portfolio provides virtual patching to protect against known and unknown attacks. It also acknowledges the need to better integrate with overall network and business processes, though the company hasn't described how it plans to meet that need just yet.

The problem for ISS is that every one of its major competitors offers similar relief. Symantec, McAfee, Check Point, and Cisco Systems all offer intrusion prevention products. They also recognize that their own products have to work within either a pre-existing network management framework or one they've built themselves.

To stand out from the pack, ISS relies on a prevention technology known as virtual patching, in which a single "signature" can prevent a vulnerability from being attacked even before an exploit appears.

The company also plans to improve existing Intrusion Prevention Systems (IPSs) and release new technologies throughout 2005, including a passive scanner that can detect when new computers join the network, as well as when unexpected applications are launched on known machines. Such events are often indicators of attacks or intrusions that have slipped past other security systems (see "The ISS Crystal Ball" on page 60).

But while ISS' IPS strategy is well-defined, the company's goal to integrate its security portfolio with network management tools is still vague. On this front, it appears that ISS' evolution is still a work in progress.

EVOLUTIONARY PRESSURE

Once synonymous with Intrusion Detection Systems (IDSs), ISS is staking its future on intrusion prevention. This evolution was driven by the onset of fast-moving, automated worms. While an IDS can spot an attack and sound the alarm, a worm's exploit code often reaches its target and does damage before a human operator can respond. IPSs fight fire with fire by putting response options in the hands of automated guardians that detect and block attacks faster than humans could.

ISS' IPS product line, known as Proventia, includes network, server, and desktop options. The Proventia network appliances sit inline and monitor network traffic to detect and block attacks on the wire. Proventia Server and Proventia Desktop are IPS software that sit on individual hosts to stop network and Application-layer attacks.

As mentioned, however, ISS isn't the only one growing a prevention feature. All its major competitors, as well as numerous upstarts, offer intrusion prevention products. For instance, McAfee has both host and network IPS products in its portfolio (see "McAfee's Entercept and IntruShield," Product Roadmap, October 2004, page 63, or search for Doc ID# 1910prod2 at www.networkmagazine.com). Cisco has the Cisco Security Agent, a host-based IPS acquired from Okena. The networking giant also has plans to include attack signatures in routers and switches. Symantec has several network IPS appliances, and Check Point's FireWall-1 can use signatures to block worms and other attacks.

VIRTUAL PATCHES

To stand out from the pack, ISS takes a different approach to intrusion prevention. The most common way to block an attack is to create a signature of a particular exploit. A signature usually matches bits of code that would only be found in the exploit. However, exploit-specific signatures can't be created until an exploit emerges. While IPS vendors can usually create signatures within hours of a brand-new attack, that delay leaves a critical window of vulnerability open. In addition, exploit variants that attack existing vulnerabilities using new code can bypass signature-based IPSs.

To close that window, ISS relies on virtual patches, also known as vulnerability signatures. As the name implies, vulnerability signatures address the underlying software flaws rather than a specific exploit. Well-written vulnerability signatures can protect against both known exploits and unknown variants of those exploits.

Vulnerabilities are usually discovered by vendors or security researchers before exploit code is created, which means that vulnerability signatures can be put in place before an attack emerges. Thus, vulnerability signatures are a pre-emptive, rather than reactive, protection mechanism. They give operations staff time to test and deploy the actual vendor patches, and they protect against variants without the need to wait for new, exploit-specific signatures to be created.

Abe Mounce, director of X-Force, the company's vulnerability research arm, says the secret to virtual patches is the protocol analysis and protocol decodes that the Proventia products perform. The Proventia products dig deep into network traffic to detect elements that match the necessary conditions to take advantage of a vulnerability.

As an example, he cites a vulnerability in the Local Security Authority Subsystem Service (LSASS), a service under the RPC DCOM protocol that's part of the authentication mechanism within Windows. A buffer overflow in LSASS was discovered that lets attackers execute arbitrary code and gain privileges on a vulnerable system.

"When we see an LSASS request, our protocol analysis module checks for an overlong buffer. If it detects one, it can take some action, such as dropping the attack traffic while letting good traffic through."

Two worms, Sasser and Korgo, used the LSASS vulnerability to attack target machines. Mounce says ISS caught both worms with just one virtual patch.

However, ISS isn't alone in the use of virtual patches. Pure-play IPS vendor TippingPoint Technologies uses vulnerability filters that operate on the same general principles as ISS' virtual patches. Symantec is also touting generic exploit blocking that follows along similar lines.

What's the difference? ISS says the ace up its sleeve is X-Force. According to the company, its X-Force team is responsible for uncovering 55 percent of security vulnerabilities discovered between 1998 and 2003. ISS says this vulnerability research gives it an edge in developing and distributing virtual patches before exploits emerge.

INTEGRATION

ISS is behind when it comes to integrating with network management tools. Vulnerability detection and remediation straddle both the security and the network operations disciplines. Security operators tend to conduct the vulnerability scans, but network or systems operators test and deploy patches. Thus, it behooves security vendors to work closely with network management systems such as HP OpenView or IBM Tivoli, as well as with systems operation tools such as trouble ticketing and workflow tracking products.

ISS acknowledges this, but the company doesn't expect more significant integration with management and trouble ticketing systems until late in 2005. Details about just what integration means and which vendors it has in mind remain sketchy.

"We can talk SNMP, so we integrate on that level with network management apps," says Clarence Morey, senior manager of product strategy at ISS. "We are looking at tighter integration, but those details still have to be defined."

Andrew Conry-Murray, technology editor, can be reached at [email protected].

Network Computing Feature Security Dragon Claws its Way to the Top Page 2 August 20, 2001

The idea behind Dragon is quite simple: It's made by the hard-core, for the hard-core. Veteran security administrators and Unix jockeys will dig it, and most Microsoft Windows administrators will choke on it. Dragon's strengths lie in its deep signature set, its robust engine, and its ability to log and display a dizzying amount of data. Its weaknesses? The Web-based console is difficult to navigate and frustrating to use.

Enterasys is one of the few vendors that can realistically talk about watching over ISP links and other carrier-class networks. The engine is rock-solid, and once you have the sensor set up and talking to the console, it hums along. We ran into a few instances where the communications died, and we needed to log into the sensor to troubleshoot, but compared with the other IDS platforms, Dragon was pretty painless.

Another issue users should consider is the number of signatures they choose to enable. Dragon has an open-signature format that lets users create their own signatures. In fact, it's so well-defined (and similar enough to the Snort signature format) that the Whitehats arachNIDS site exports all its signatures to Dragon format as well. The result is a massive signature set. At one point, we pushed out a very aggressive configuration. The Dragon infrastructure was able to keep up, but we were processing more than 2 GB of data per day! At this rate, we could hold only four days of data before we needed to start clearing out old info.

Enterasys Networks Dragon 4

On the management side, Dragon's Web-based user interface leaves much to be desired. It can be confusing, though using it gets easier after a few days. Another problem is that there are too many different Web-based tools, including Dragon Fire, Dragon Console and Dragon Rider. The consoles are bolted onto the CLI (command-line interface) tools, which are still available by SSHing into either the sensor or the console. Most of the pull-down menus and filterable options are simply flags and arguments that are passed to the back-end CLI commands. The conceptual link to this impressive and powerful array of CLI tools is presented at the top of the queries that are created through the Dragon Fire tool. The display limits on the Web pages and the frequently inefficient methods of finding the right box to supply the desired filter will quickly encourage you to use the CLI. It's raw, but it works.

Intrusion Detection Solutions Dragon Sensor - Open Signatures

Over 1300 Signatures As of mid July, 2001, Enterasys Networks provides over 1300 signatures for Dragon Sensor. These signatures are written and tested by a staff of intrusion detection experts who keep a constant watch over the many threats on the Internet and also conduct independent security research.

Correlation with CVE, Nessus and other resources All of the signature descriptions include links to the CVE (Common Vulnerabilities and Exposure) archive which is maintained by Mitre. Please visit http://cve.mitre.org for more information about CVE. All Dragon signatures include relevant CVE links which is extremely useful for conducting additional research once attacks are detected. Dragon descriptions also include links to relative Nessus security checks. Nessus is an extremely popular vulnerability scanner. Each signature has the correlating Nessus vulnerability identification number. The Dragon Vulnerability Correlation Tool (VCT) uses the output of a Nessus vulnerability scan to correlate IDS events which occur against systems with known vulnerabilities. Dragon signature descriptions also include links to relative CERT advisories, vendor security bulletins, white papers and many other resources.

Write your own signatures! Dragon Sensor has a very powerful signature language which can be used to find simple attacks as well as very sophisticated ones. It includes support to search for a wide variety of traffic in both packets and sessions. Traffic can be identified as simple pattern matches, complex orders of selected patterns and patterns which may indicate potential attacks such as buffer overflows. The signature language includes support for case insensitivity, many robust wildcards, searching for binary data, searching for strings followed by a second string, searching for strings not followed by a second string and many others. No API is required to write signatures for Dragon, only a sense of protocol analysis and a text editor.

Diverse Signature Libraries Dragon Sensor's signature are divided up into several libraries. These separate libraries allow many of the analysis, reporting and alerting tools an extra variable to sort on. The following libraries are included with Dragon Sensor:

• Suspicious - non-threatening network events which may have a security impact
• Probes - network activity designed to return the status of a given network
• Attacks - deliberate network activity which attempts to alert data or execute commands illegally
• Compromises - evidence of a successful attack
• Failure - evidence that an attack has failed
• Virus - evidence of network-based virus activity
• Trojan - evidence of network-based Trojan Horse activity

Dragon Sensor takes care of complex application decoding Network IDS algorithms are vulnerable to many forms of deception and confusion. Many commercial and free NIDS products use simple decoding of network traffic and apply signatures expecting that the collected traffic will be 'normal'. Unfortunately, many network attackers have begun to attack how NIDS decode application traffic. Rather than write a signature for each of these NIDS evasion techniques, Dragon Sensor has several built in decoding engines which are applied to the collected data before signature detection occurs. Here is an example of the many application protocol decodes which are accounted for in Dragon Sensor 5.0:

• Telnet and FTP white-space and backspace removal
• SNMP null-byte encoding
• self referencing directories in web URLs
• UNICODE in web traffic
• DNS encoding
• RPC null-byte encoding
• long URL wrapping
• per signature case insensitivity
• complex web URL decoding
• many more ...

Weekly Updates and Live Downloads Enterasys provides weekly updates to the Dragon Sensor archives and will issue intermediate signatures for quick-response threats to the Dragon Support Mailing list. Dragon customers can also configure their Dragon Policy Managers (see the Dragon Server scalable architecture link for more information) to download new signature updates from the Dragon support site once a day

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: February, 01, 2019