I am new to the list so please forgive me if I am asking a question that has already been asked in a previous thread. I am a user of the management center for ids version 1.0 for cw2000 and would like to find out if there is anyone in the list that can answer a few questions:
1. It is difficult from the GUI, to see quickly which signatures have log enabled and which dont. Is there a quick (CLI) method of enabling a signature to log to a iplog file and then once you have finished logging or have the information you require, to return the signature back to log off?
2. What tools are being used by the group to read back the binary log files once they have been captured at /usr/nr/var/iplog/new. I am aware that there are tools like tethereal: "/usr/nr/var/iplog/iplog.192.168.252.154.199602060001"
Is this a chosen Cisco method for reading the binaries or are there other methods?
3. Are these tools (tethereal) generally installed at a different machine or on the NIDS sensor?
1. No quick way that I know of. The normal process of changing a signature to logging, saving the policy , generating the policy and then pushing it out is by no means quick but what you have to do.
If you wanted the sensor to log, my recommendation is to edit the /usr/nr/etc/packetd.conf directly on the sensor.
There is a line, say for the Net Sweep-Echo signature:
SigOfGeneral 2100 0 0 0 0 # Net Sweep-Echo
That first 0 corresponds to the following table:
0 Do Nothing
3 Shun & Log
etc (about 8 things I think)
Log is what you're interested in. When you configure the signature the 'correct' way through the IDS MC, take a look at the above signature line after you have configured it to log. It will look like this
SigOfGeneral 2100 2 0 0 0 # Net Sweep-Echo
That '2' means the sensor will now log every time this signature is triggered. Of course in this case the signature is diabled. If the signature were set to low, it would look like this:
SigOfGeneral 2100 2 1 1 1 # Net Sweep-Echo
SigOfGeneral 2100 2 3 3 3 # Net Sweep-Echo for medium
SigOfGeneral 2100 2 5 5 5 # Net Sweep-Echo for high (eek)
So my suggestion is that you get used to this file, and when you want to make a quick change, directly edit the file, for the signature you're interested in and start/stop the sensor (using nrstop and nrstart)
Now there's a problem with this. The Signature may have already triggered, and you missed the event. If 'it' never happens again, you will never log any traffic. Changing this signature only tells the sensor to start logging traffic the next time the signature is triggered.
You're best solution is to run snoop on the sensor and start capturing traffic from the source/destination IP address as it is happening.
One gripe I've always had with Cisco IDS is that logging is great except that it never logs the actual packet that triggered the signature. FOr most of these signatures, those 'triggering' packets are crucial!
It has been said in the past that running Snoop on the sensor might impact performance, but I've not noticed it. Besides you're not running snoop on a continual basis, only when you want to capture traffic you're interested in.
2. Ethereal is my reommendation for viewing these capture logs. Cisco recommends Ethereal also.
3. Ethereal is installed on a different machine. I let my sensor sense, and just ftp the logs from the sensor whenever I need to view them.
If you want to configure IP Logging for a specific signature then you can do the following:
NOTE: For IDS MC users, this will change the sensor's configuration but that configuration will be overwritten next time IDS MC pushes down a configuration. This will be OK if you are looking for a temporary configuraiton. For permanent configuration you need to go through IDS MC.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...