Firewall Testing

Quote:

---

Originally posted here by frpeter
That is true... Here is the perfect example of why I need more diversity... Unfortunately, I have no why to research other distrobutions and have had to pick common references. Can you provide the complete path to your IPTables/ I'll add an aditional comment to the scripts.

---

Correct me if I'm wrong but

Code:

---


`which iptables`

---

should provide the location of iptables on the machine... alternatively used in a boolean statement to see whether iptables or ipchains are available... or something along those lines. Like that you wouldn't need to hardcode possible locations. [however I think you need to have the install script ran as root]

Yes hypronix, nice. I believe you are correct.

But just so you know, for RH and Fedora it is /sbin/iptables. I don't know about others.

I wish I had more time to spend on this ...

a couple of questions did come to mind though.

1) Have you done any research on system resources? Compared the numbers at different times of the day ( ie. light and heavy network traffic ? )

Might also be interesting to do the same with promiscuous mode off.

2) What if an internal server ( say web server ) has a flaw and gets rooted ( or, dare I say, you have an employee working from the inside ). What does a port scan of the firewall box look like from inside the network? ( I know EVERYBODY turns off unnecessary things like rlogin and X-windows on firewall boxes! )

Hello,

I run Slackware as a base, but heavily modified ru run RH. for me, the command is:

whereis iptables

The alternate is a nice thought... just haven't figured out how to tell which to use if both are installed. My system has both so I can test. My kernel programming isn't that great yet...

Yes, extensive reearch here.. I started under 64M of ram of 2.2. I have since built up to 2G of ram. the defines in bulldog.h can be taylored to limit the amount of children spawned. See references to the DYNAMIC define where I do just that for dynamic IP systems. The use considerably less resources.

Promiscuous mode (on or off) in my testing doesn't seem to effect resources. I would certainly agree that more testing is needed with some hard number to back the results on a larger scale.

The overall design is not impacted by volume of traffic as long as there are enough processors to keep up with the incoming stream.

Eariler designed based on pthreads had a hugh impact in this area though. More traffic meant significant increase on resources. Less traffic meant starving threads.

The approach now doesn't allow starvation at all, no matter how low the traffic is. Every processor is guarenteed to get a packet if one is available. See bulldog-collector.c on how I acheive this. The goal here is to be able to predict how much resources will be needed no matter what load the machine may be under. I have confirmed this with testing internet, lan, and localhost traffic simultaneously. With my lan and localhost tests, I have launch massive ping floods to diliberately overwhelm the system. The resultd where the firewall resources were as I estimated. The load did increase as expected under the "Black Rose" attack.

If the BullDog is told to ignore the internal machine, nothing happens at all and the port scan runs normally. If the internal machine is not ignored, ie: there are explicit rules for it, it too will be blocked if a wrong port is hit. I routinely use nmap to test things for new holes. I also use DSLTools, SyGate, and GRC. Yes I knwow GRC can be beaten with a sneeze, but it is a good traffic (noise) generator when I need to hammer the firewall.

Internal security can never rely on a firewall if others have access to the firewall machine unless the machine has only one operator and only he has root access. Any other combination on any machine is a security risk.

If I missed anything, please let me know.

Quote:

---

Originally posted here by frpeter
Promiscuous mode (on or off) in my testing doesn't seem to effect resources. I would certainly agree that more testing is needed with some hard number to back the results on a larger scale.

---

This about sums up why promiscuous mode is bad:
http://lists.freebsd.org/pipermail/f...st/055517.html
Many/Most network stacks were not designed to offer optimal throughput while still dealing with EVERYTHING being put onto the wire.

Quote:

---

I routinely use nmap to test things for new holes. I also use DSLTools, SyGate, and GRC. Yes I knwow GRC can be beaten with a sneeze, but it is a good traffic (noise) generator when I need to hammer the firewall.

---

Hammer the firewall?? GRC's scan does nothing of the sort...

I haven't had a chance to examine this on an actual Linux box, but I wonder what the purpose of this 'firewall' is? It seems to draw solely on netfilter/ipchains for its firewalling capabilities, and fails to really provide any reason as to why a 20GB DNS database is necessary. How often are people going to update a 20GB database when DNS entries change quite often? DNS is meant to be a dynamic system, IMO it is foolish to try and circumnavigate it by developing a static table.

Additionally, while syntactically some may find it easier to use, it does create much more work in the rule creation department IMO. Netfilter rules are of varying complexity, however a simple ruleset still offers web surfing without a pair of rules for allowing such traffic through.

Hello,

Thank you for the link.

Thats why I stated noise in the parens... It does give tcpdump a good set of garbage to test with. I definately don't qualify GRC as a reliable test.

The DNS database is self updating. BullDog maintains it internally. If you choose note to download the existing version, BullDog will build one based upon the traffic and its internal domain spider. The DNS database is optional for that reason. If you would like to see its contents, you can goto http://tanaya.net/dns/

I have been building the database for 5 years. Many of BullDog's users choose to disable the dns spider and start with no dns database thus allowing it only to build solely on their traffic.

For me, it has elievated a lot of unnecessary traffic by looking up an IP address hundreds of times. Plus I've use it in several other applications to reduce network load.

The purpose of BullDog is to:
1. simplify rule management,
2. work around an issue in V2.2 and 2.4 (18-22 I know for certain) where large lists in IPTables degrade system useability.

There is some overhead in setting it up. But once the basic framwork is established, its easier to maintain as a whole without having to block 256 ip addresses for one bad user. I have spent a large amount of time reading where large companies end up blocking chucks rather then single IPs to keep performance high. There are several threads on DShield of this issue.

IP based rules don't illustrate the advantage. However; domain name based rules clearly demonstrate the advantage BullDog offers to its user. Here are some pratical (to the site owner) examples:

Example 1: I use ircache as an additive to my lan. There are 10 different unrelated sites involved. 2 rules:
R .ircache.net any tanaya.net any tu
R tanaya.net any .ircache.net any tu

This allows traffic to any of the ircache systems irregardless of how many times they change IP addresses.

Example 2: I personally do not recomend this, but... One of BullDog users went on a rampage to stop spam from Korea. He blocked the entire country with:
B .co.kr

As I said, I do not recomend such a blanket ban. But each user has their reasons for such extreme measures. A few other examples:
B .microsoft.
B click

The last example will block DoubleClick, HumanClick, ValueClick and every other click on the internet. But rather then adding 1000's of IP addresses to the kernel's iptables list, BullDog intelligently blocks only what actually hits the system or in the ircache case, allows it through.

A third example is pogo.com. They have currently 2000+ IP addresses and are always adding. A few rules can handle any number of changes they make without my intervention.

I do not recomend using these examples until you are sure they will function as you need them to for your system and its requirements.

Domain name based rules are where BullDog seperates itself from just an IPTables manager in that it allows a larger degree of freedom.

The other emphasis is that BullDog does force the situation that you must know what traffic you explicitly want or do not want. I have made a few blunders along the way myself and locked myself out for not paying attention to what I needed to do. That is an advantage and a disadvantage.

The first year I had BullDog running, I had very little knowledge of bind and never heard of the LionWorm virus/rootkit. My system was infected through a vulnerability in bind. The hacker try to access my system. The IPTables layout I had (from netfilters soho examples) would have allowed the hacker in. BullDog blocked the hacker and saved my backside. Needless to say, I very quickly learned about BugTraq and CERT.

I by no means am advocating everyone run BullDog. That would be nice, but blindly stupid on my part a the ver least. Like all software, BullDog has an audience that it attracts, like snort or any other tool. Wheather or not a given user uses BullDogg is really irrevent to the point of that that users security must meet their needs to be effective.

I probably shot my self in the foot, but I'm not out to take over the world, merely fill one hole.

If I left anything out, please let me know.

Quote:

---

Originally posted here by frpeter
The DNS database is self updating. BullDog maintains it internally. If you choose note to download the existing version, BullDog will build one based upon the traffic and its internal domain spider. The DNS database is optional for that reason. If you would like to see its contents, you can goto http://tanaya.net/dns/

---

I looked at the contents. What I fail to grasp is why it is necessary to build and maintain the database at all.

Quote:

---

I have been building the database for 5 years. Many of BullDog's users choose to disable the dns spider and start with no dns database thus allowing it only to build solely on their traffic.

For me, it has elievated a lot of unnecessary traffic by looking up an IP address hundreds of times. Plus I've use it in several other applications to reduce network load.

---

My first thought when I saw the DNS filtering solution was that netfilter can already do it, though as you point out not quite as efficiently. However, for many of your examples, a border firewall shouldn't be making those decisions anyways. Those sorts of filters are better left for a proxy server, in other words there are already tools out there that accomplish that task
Even if you wanted to go the reverse lookups on the firewall route, why not simply encourage users to keep a small lightweight caching-only nameserver to handle the lookups with? Surely that is far simpler than attempting to maintain a similar database within the firewalling portion of the app. itself?

Quote:

---

The first year I had BullDog running, I had very little knowledge of bind and never heard of the LionWorm virus/rootkit. My system was infected through a vulnerability in bind. The hacker try to access my system. The IPTables layout I had (from netfilters soho examples) would have allowed the hacker in. BullDog blocked the hacker and saved my backside. Needless to say, I very quickly learned about BugTraq and CERT.

---

This doesn't really speak to a strength of BullDog so much as a weakness on the part of your configuration of netfilter IMO.

Hello,

My tests have shown that the DNS database reduces net traffic by already having a given IP address resolved. From my system performance, DoS attacks against the resolver become significantly less of an issue. This fact that its application has added to the stability of BullDog vs for example, tcpdump's realtime resolution. Tcpdump would stop and wait for the dns to answer. Even though it has a 10 second time out, that could easily result in lost packets or delaying packet processing. My goal in the processors is to evaluate the packets as fast as possible. That may mean humdreds or thousands of packets a second being processed. Realtime resolution simply is not practical. Even if its a cacheing nameserver. Realtime resolution would slow processing down to much to be a viable solution under an attack.

I confirmed that I had IPTables configured properly with the netfilter team. The issue was the vulnerability in bind and the attacker clearly knew how to exploit it.

If I missed covering anything, please let me know.

Miss an item...

Proxy servers only guard in a limited context and not everyu service has a proxy server. Bind is a good example of an unproxied service that must (for the most part) remain open when hosting domains. Its far more effecient to block a domain name base organization with name rather the several rules required where the IP addresses may cover several unrelated IP blocks.

I think I covered everything...

Something else that came to mind... My running copy is so large for research and demonstration purposes. Realistically, I doubt very many people would keep their copy as large unless they were involved in domain research of some type.

On the realistic scale, I would say most sites will have maybe somewhere around 20,000 ipaddresses in their list. That would make an interesting poll...

I thought most people would switch to djbdns over BIND...

So, you're the guy who made Bulldog? Or worked on it?


Uhhh, a 20 GB file..... Wouldn't it make more sense to just pop Open BSD or some form of *NIX on a 486 and save the 20 GBs for something useful? I mean man that's shitty marketing. If it comes down to MP3s and Porn or a front end to IPTables don't even bother trying to guess which I'll do.