Tuesday, May 30, 2006

Q: I have uploaded a bad rule to the local rules on the DC. How do I delete it?

A:
There is no way to delete a rule, once uploaded. You'll have to live with it forever! Bwaa ha ha!

Q: What is the overall process for setting up sensors, interfaces, interface sets, detection engines, and IDS policies?

A:
I'll refer to each appliance as a "sensor".
  1. Figure out how many detection engines each sensor supports. My IS1000 supports one, and the IS2100 supports two. It took me some recursion to figure this out; the only indicator is the pulldown in the "detection engine" screen. We're going to end up assigning interfaces to a detection engine, and then applying policy to groups of detection engines.
  2. Bring up your interfaces. One at a time, attach a live cable to the interface, and use ifconfig -a from the command line to figure out which one you just connected to. Leave the interfaces at autodetect to avoid problems. If you get a stuck interface, reboot the sensor.
  3. Navigate to Operations//Configuration//Detection Engines. We'll be working from here.
  4. "Network interface" screen. Edit each interface. Give it a description according to what it is monitoring. Leave "auto-negotiate" on but set the Link Mode to your favorite setting.
  5. "Interface sets" screen.

    First delete any default interface sets; these glom onto all of your interfaces when you first start, and prevent you from assigning the interfaces anywhere else.

    Think backwards from how many detection engines the sensor has, and the names of the policies you are going to (later) apply to them. For each D.E. (which you'll set up later), create an interface set. Make its description 'idsname-policyname'. For instance, I have an interface set on ids3 which has the policy 'domain controllers'; the interface set name is therefore ids3-domain-controllers.

  6. "Detection engines" screen. Create a D.E. called 'policyname idsname'. For instance, domain-controllers-ids3. Description is unnecessary. Type is IDS. Select the interface set which it corresponds to (this should be easy, because of the way you named it). Now here's the tricky part: under the "Detection resources" pulldown choose "1". This pulldown shows you the number of remaining Detection Engines on your sensor. (Remember the first step above? This step confirms for you that you correctly guessed the number of D.E. supported by the sensor). Note: the number in the pulldown is not the cardinal number of the engine. It is the number of engines remaining to be used on the sensor. Repeat for all D.E.s that you have available.
  7. If you have more than one D.E. which will have the same IDS policy, create a group for them.
  8. Now you can go over and create you IDS policies (Policy & Response//Intrusion Sensor//Detection & Prevention); when you with to apply them, you can apply them to the individual engines or groups. Keeping the names consistent, as we have done, will help you avoid making mistakes when applying policies. What you end up with is policies which apply to interfaces like this: policy (applies to) detection engine(s) (applies to) interface group (applies to) interface(s).

    For instance, my policy "IDS domain controllers" applies to D.E. group "domain controllers" which contains the D.E. "dom-ctrl-ids3" and "dom-ctrl-ids4". "dom-ctrl-ids3" is assigned to interface set "ids3-dom-ctrl" which contains the interfaces on ids3 which are listening to domain controller ports.

Q: How do I set up the DC to automatically get the Sourcefire VRT rules updates? Bleeding snort?

A:
I don't know the sure answer to this yet. Operations//Update seems to deal with only patching the system, not rules updates. Policy & Response//Intrusion Sensor//Rules has an "import rules" link. This leads to a screen where you can either being in any textfile containing rules, or "Download new SEU" from the support site. I bought a VRT subscription, so perhaps when I download SEU I am automatically getting teh latest ruleset. There's no practical way to tell from the console. There are some options under Operations//Tools//Scheduling which say "download latest SEU" and "install latest SEU" but it's unclear how this works and how the workflow needs to progress (after install latest, do you need to then apply policy?) I'm going to RTFM before asking for support.

Tuesday, May 23, 2006

Q: Why can't I enter my correct FQDN when setting up the unit?

A:
On the networking info screen, which is the first screen you see after you initialize a new unit, you are asked to enter your FQDN. All of the IS and DC share the same flaw: the GUI makes assumptions as to what is a proper FQDN. In my case, they rejected my FQDN, I assume because it does not end with an ICANN-listed gTLD or IANA-listed ccTLD. The workaround is to enter either nothing, or anything that the unit will accept (such as example.com.) Once the unit is up, you will be able to SSH in as root and vi /etc/resolv.conf to put in the correct FQDN. This seems to take care of it.

Monday, May 22, 2006

Q: How do I upgrade the system software on the DC and IS?

A:
To see what version you are running, log onto the DC console and go to operations//system settings to see the DC version and operations//sensors to see the sensor versions. All the managed IS can be upgraded from the DC (although if you need to downgrade them later you'll have to log in at the sensor to do that). If you have a new version to install, first you download it from the Sourcefire support website to your local disk, then you upload it to the DC using the web interface. The DC will know whether you have uploaded DC software or IS software. Upgrade the DC first, then each IS. From Operations//Patch Update Management, click on 'upload update' to upload each image to the DC. Then, from the same screen, you first 'push' the new image to the target box. Once it is there, you 'install' it.

Q: On the IS, the NIC interfaces are not labeled. Which interfaces are which? How do you tell if an interface is seeing traffic?

A:
You'll have to physically label the interfaces yourself; there is no documentation. In the www console, Operations//Configuration//Detection Engines//Network Interface, you'll see the list on interface names. Make sure all interfaces are set to autonegotiate. Connect a spewing span cable to one of the physical interfaces. Log on as root in an SSH session, and use ifconfig -a to figure out which interface is seeing traffic based on the counters. Then label the physical port with ptouch and move the cable to the next port. Repeat until all ports are labeled. Then inform Sourcefire so they can update their documentation. If you find, as I did, that no ports are showing traffic even with a cable connected, you may need to reboot your system. I suspect that this is sometimes necessary after you change the speed or autoneg settings of a port (I don't know which).

Q: Where is the documentation for the systems?

A:
Sourcefire does not give anyone access to the documentation until they have registered on the Sourcefire web site and also have a current support contract. Once you are registered, the docs are in https://support.sourcefire.com/ It also should be on the CD that comes with each system.