Firewall Testing

Hello,

My apologies in my delayed reply. I spent some time doing a little research.

As stated previously, i use bind. As as cache server, bind defaults to holding entries for 7 days. See The BIND 9 Administrator Reference Manual, page 76, reference: max-cache ttl. Using this information BullDog's DNS Database has been modififed to force validate all traffic IPs after 3 days. Thus BullDog's default operations now sets the DNS Database as a disk based DNS Cache rather then a research database, similar to that of Analog. Bind defaults to using all memory a machine has for a cacheing server. The disk based cache avoids the issue of memory consumption, plus provides auditing. I spent the last 2 days building testing this and will continue testing it for the next release.

If the BullDog is configured to build a research database (as in my case), IP traffic is still for validated after 3 days. So both can reside at once and traffic based DNS entries are always up-to-date.

In my tests (full server operation), the DNS Database was approx. 2M for 2 days of traffic. Considerably smaller and supports my above statements that a non-research database would not require 20G.

On to the promiscuous issue. I did some research on this issue as well. Firewalling alone does not require promiscuous mode. However; it would appear the any IDS methodology does. The following software default to promiscuous (on my machine, also I verified taking the interface out of promiscuous mode *before* running each of these): tcpdump, snort (NIDS mode), snort+acid, netwatch, coutney, etheral, tetheral

From my readings of searching the internet, promiscuous mode is required to detect stealth scans (SYN, FIN, NULL, XMAS). Each of the above have a switch not to use promiscuous mode. As stated above that feature was planed and is now implemented. One resource I found that gives a crude overview is (other resources follow):

http://www.startcom.org/docs/en/Secu...1-ids-net.html

Another resource this is most interesting (pros and cons of promiscuous mode discussed):

http://cerberus.sourcefire.com/~jeff...xter/dids.html

This resource is most enlightening in that some nics default to promiscuous mode enabled. The sub-links are also filled with interesting reading:

http://www.madge.com/_assets/downloa...c/Promisc2.htm

Other examples of promiscuous mode usage: example of Bandwidth monitors and snoop servers:

http://searchsecurity.techtarget.com...518283,00.html

HP is working on different levels of promiscuous mode:

http://docs.hp.com/en/B2355-90139/ch01s03.html

Long winded tech info on ATM-1/2 and promiscuous mode:

http://www.juniper.net/techpubs/soft...7.html#1034111

I thing I covered everything. Please let me know if I didn't.

Here is an interesting link with code example:

http://docs.hp.com/en/B2355-90139/ch01s03.html

Stealth Scan Detection:

http://www.die.net/doc/linux/man/man8/iplog.8.html

This one is Windows based, but still good reading:

http://www.ticm.com/kb/faq/idsfaq.html

Quote:

---

Originally posted here by frpeter
As stated previously, i use bind. As as cache server, bind defaults to holding entries for 7 days. See The BIND 9 Administrator Reference Manual, page 76, reference: max-cache ttl. Using this information BullDog's DNS Database has been modififed to force validate all traffic IPs after 3 days. Thus BullDog's default operations now sets the DNS Database as a disk based DNS Cache rather then a research database, similar to that of Analog. Bind defaults to using all memory a machine has for a cacheing server. The disk based cache avoids the issue of memory consumption, plus provides auditing. I spent the last 2 days building testing this and will continue testing it for the next release.

---

Using a memory based cache isn't a bad thing IMO. If you have a caching nameserver the entries most used will probably be kept in RAM, and the not so often used entries will be dumped into swap. This would improve speeds I would think.

Quote:

---

On to the promiscuous issue. I did some research on this issue as well. Firewalling alone does not require promiscuous mode. However; it would appear the any IDS methodology does. The following software default to promiscuous (on my machine, also I verified taking the interface out of promiscuous mode *before* running each of these): tcpdump, snort (NIDS mode), snort+acid, netwatch, coutney, etheral, tetheral

---

Of course. What IDS features does BullDog offer that requires this?

Quote:

---

From my readings of searching the internet, promiscuous mode is required to detect stealth scans (SYN, FIN, NULL, XMAS). Each of the above have a switch not to use promiscuous mode. As stated above that feature was planed and is now implemented. One resource I found that gives a crude overview is (other resources follow):

---

I don't see how promiscuous mode would be required to detect "stealth scans" considering it's just a certain combination of packet flags, and it would have to hit your machine before it gets discarded, which in turn means that Netfilter can be instructed on the action to be taken:

Code:

---

$iptables -A INPUT -p TCP -m state --state INVALID -j DROP

---

That doesn't require promiscuous mode. Hell, if you want to log it use the LOG target.

Hello,

Quite frankly, I'm still trying to figure out the exact mechanics of WHY snort needs promiscuous mode. The more I've read on this the more blurred and confused the issue seems to be. IDS in BullDog is a future plan... Hopefully with better footing on this issue.

At this point, the only thing I can think of that promiscuous mode would do is show springboarding (where the src and the dst are not the target machine). BullDog (promiscuous mode) does block spring boarding.

I'll be doing a little more reading on this....

I can get slightly better performance keeping certain types of data on disk. Swap latency can and has slowed my server down. I run UMDA 133 on my drives.

So my xfer path is:

program -> disk -> data

as opposed to

program -> memory -> swap -> disk -> data

If swaping can be avoided and memory shared, then memory is the best option. However, controling the swap isn't always guarenteed productive (due to a given machine's memory limits) and not all systems support shared memory.