Printable View
Hello,
Yes, I am the author :)
BullDog isn't for every user as with most software. Thats one of the nice things of linux as each user can choose according to their needs. I know of one ISP I'll lay odds you would never use. They go out of their way to block the content you would be interested in. Some I even have to question what they are keeping (or in).
As muert0 in an above message put it (more eloquently though), kinda hard to market free.
As I think I implied before, and not withstanding what was said about documentation, the first couple of times I installed it I set it up with a private IP address, connected it to my LAN, ran some scans ( using SuperScan v4.0 ) . The box became sluggish ( its an older box, but faster then what I sometimes use for firewalls PIII class). The scan ( both UDP and TCP ) found no open ports ( I did not have any web servers etc. attached, and did not customize it for the LAN it was on. But note here, although I did not check the DNS files as they were large and did not think of it, the scans did not show up in the Bulldog logs! I also ran the scans LOUD. )
And, it added to the DNS files the addresses of every computer on the LAN and all of the computers they communicated with, as far as I could tell. ( Note here, some of the computers on the LAN are on IRC, etc. and some are NATed directly by the firewall box. Everyone of these connections was listed and blocked ).
Again, none of them were sending packets to the test box. They were simply on the same subnet connected by a hub ( for this test because of the promiscuous mode, another reason I mentioned the DShield reports. Imagine weather.com being sent a FightBack notice because the neighbor is on the same subnet and has a java applet that updates the whether every so-many-seconds ).
Some other things I did not like:
Chain INPUT (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)
This is against everything I have learned, and against everything I preach ( sorry Father Peter, not trying to muscle in here, but I preach A LOT about things, especially computer security to anyone who will listen, even those who don’t want to ). Deny EVERYTHING and only allow what you need!
O.K., I am only on vacation for another two days, ( the rest of this one is no good, I have to go to bed now before I pass out ) and I don’t have the time to do what is really needed.
What is needed ( run on a private LAN first, unless someone has several boxes and a public IP address they can sacrifice for the cause ):
1) To see if it configures anything differently for eth1, or would one have to do that manually without intervention from Bulldog? ( My initial examination revealed no rules for additional Nic. cards, that is what prompted the previous questions . I understand one can do that manually, but then why use Bulldog? I can already do that manually. )
2) This time use nmap http://www.insecure.org/nmap/ for the scanning and adjust scans as a hacker would.
3) See what leaves the box under a stock install of an OS.
4) See what enters the box from the LAN.
*** 5) If those tests are successful, reinstall Bulldog and connect it to the net, and see how it fares against a proven firewall
Bulldog attempts to implement an IDS ( which it can not accurately do in promiscuous mode, IMHO ) to control the firewall.
Here is where I get flamed:
FWIW, IMHO:
A firewall must not only protect the LAN it serves, but must protect itself, and the NET from the LAN it serves.
An IDS is nice, has its purpose, but is reactive instead of proactive. The firewall should only allow what is necessary and prudent for operations to succeed. Where an IDS becomes necessary at this stage in computer connectivity and development, beyond analytical studies, is in networks where the Admin is incompetent or is circumvented by the incompetent for either monetary or political reasons.
Whish I could pursue this more.
Hello,
Did you tell BullDog to ignore the ip address you sent the scan from with the I command? ie:
I 127.0.0.1
Will ignore all traffic from localhost. Are you running a static or dynamic IP system?
DSHield only send FightBack reports if you log into their website and explicitly request it from the log pages.
As to the other connections being blocked, try running etheral, snort or tcpdump of the system you are testing BullDog on. You'll be amazed at way is actually going through your lan even when you are not doing anything.
For the ETH1 interface, you'll need:
E eth1
in your bulldog.conf
The IPTables listing is indeed backwards to traditional thinking. But unfortunately, when running public services as a server, appropriate to the situation. The point to remember is that BullDog blocks unless there is an explicit rule to allow. If you wish, send me information about your system in a private email and I will write a conf file for you:
Interface it'll run on
IP block on your net, ie 10.0.0.0/24, for example
A list of active services
Do you run static or dynamic (dhcp)
BullDog does require time to setup. Below is my partial config. Lan setting removed for security. If you wish I can send it to you in a private email.
# BullDog Configuration
#
# Ether Interfaces
#
E eth0
#
# Internal (local) addresses
#
# Local Addresses (to this machine)
I 127.0.0.1
I 63.230.33.209
# Rules Section
# visualroute.com
R .visualware.com any 63.230.33.209 any tu
R 63.230.33.209 any .visualware.com any tu
# Pool tournaments
R .playsite.com any 63.230.33.209 any tu
R 63.230.33.209 any .playsite.com any tu
# NIST time servers
R .nist.gov 123 63.230.33.209 any tu
R 63.230.33.209 any .nist.gov 123 tu
R .nist.gov 123 63.230.33.209 123 tu
R 63.230.33.209 123 .nist.gov 123 tu
# PGP Public KeyRing
R 195.113.19.82 11371 63.230.33.209 any t
R 63.230.33.209 any 195.113.19.82 11371 t
R 212.55.198.213 11371 63.230.33.209 any t
R 63.230.33.209 any 212.55.198.213 11371 t
R 64.71.163.210 11371 63.230.33.209 any t
R 63.230.33.209 any 64.71.163.210 11371 t
R 65.75.25.34 11371 63.230.33.209 any t
R 63.230.33.209 any 65.75.25.34 11371 t
R 69.36.241.130 11371 63.230.33.209 any t
R 63.230.33.209 any 69.36.241.130 11371 t
R 128.197.128.140 11371 63.230.33.209 any t
R 63.230.33.209 any 128.197.128.140 11371 t
R 129.128.11.77 11371 63.230.33.209 any t
R 63.230.33.209 any 129.128.11.77 11371 t
R 193.174.13.72 11371 63.230.33.209 any t
R 63.230.33.209 any 193.174.13.72 11371 t
R 194.171.167.2 11371 63.230.33.209 any t
R 63.230.33.209 any 194.171.167.2 11371 t
R 194.171.167.147 11371 63.230.33.209 any t
R 63.230.33.209 any 194.171.167.147 11371 t
# ftp.kernel.org
R 204.152.189.116 20-21 63.230.33.209 any tu
R 63.230.33.209 any 204.152.189.116 20-21 tu
R 204.152.189.116 any 63.230.33.209 any tu
R 63.230.33.209 any 204.152.189.116 any tu
# Standard Traffic - mail server
R any 25 63.230.33.209 any t
R 63.230.33.209 any any 25 t
R any any 63.230.33.209 25 t
R 63.230.33.209 25 any any t
# DNS Server
# Stealth Attack Defense
R any 53 63.230.33.209 53 tu
R 63.230.33.209 53 any 53 tu
# Standard Traffic
R any 53 63.230.33.209 any tu
R 63.230.33.209 any any 53 tu
R any any 63.230.33.209 53 tu
R 63.230.33.209 53 any any tu
# Web Server
# Standard Traffic
R any 80 63.230.33.209 any t
R 63.230.33.209 any any 80 t
R any any 63.230.33.209 80 t
R 63.230.33.209 80 any any t
# Live365.com
R 63.230.33.209 any .live365.com any tu
R .live365.com any 63.230.33.209 any tu
#
# Perminently Banned Sites (shorten list)
# Spammer, hackers, and the like
#
B products
B offers
B deals
#
# Exclusions (explicitly trusted sites only)
#
X 207.173.172.131 ftp.slackware.com
X 209.140.211.24 windowmaker.org
Please let me know if you have any questions.
I am not sure that I had bulldog.conf configured properly when I ran the scan, I don’t remember at which point I ran it. ( set it up several different times ) But no I did not block it.
As far as setting it up, once you understand it the setup is easy and quick, if one understands the network it is going to be on. As said before the lack of Documentation is probably the largest issue right now. Hopefully this exchange is helping you with areas to be covered when you write it.
And as I said it needs more testing and I will probably be playing with this for a while as time permits. For some reason I can not seem to let this go. ( maybe because I have had something like this in the back of my mind for a few years, never got a round-tuit )
Hello
Yes, this thread is helping a great deal. Including a cgi to aid in building the conf file.
Thank you to everyone for their comments. The documentation will definately be improving.
Please feel free to let me know if I can assist you in any way with BullDog.
Hello,
Here are some hard numbers to support the usage of the DNS Database. I used tcpdump to get these. Packet display omited. The test was run with a count of 1000 packets.
This first run is with inline (realtime) IP resolving.
$ time tcpdump -q -c 1000
15134 packets received by filter
11922 packets dropped by kernel
real 1m3.847s
user 0m0.050s
sys 0m0.030s
The second run is without inline (realtime) resolving. This is how BullDog currently runs, relying on IP resolution from the internal DNS database. IP resolution is handled by 12 (default setting) of its children seperately from the collector and processors.
$ time tcpdump -q -n -c 1000
1000 packets received by filter
0 packets dropped by kernel
real 0m5.434s
user 0m0.000s
sys 0m0.010s
You'll notice immediately that the time for realtime resolution is an unreasonable 1m+ vs 5s for the DNS database usage. Also notice the NO packets where lost when not resolving realtime. If the test where to be repeated for 10,000 packets, the difference would be unsufferable and intolerable. IMHO, the space for the DNS database is more then justified by the performance gain it yeilds.
I went ahead a ran a test on 10,000 packets. Here are the results:
Realtime IP resolution:
$ time tcpdump -q -c 10000
57480 packets received by filter
45915 packets dropped by kernel
real 4m45.428s
user 0m0.100s
sys 0m0.340s
Relying on the DNS Database (non-reltime):
$ time tcpdump -q -n -c 10000
10000 packets received by filter
0 packets dropped by kernel
real 0m55.193s
user 0m0.240s
sys 0m0.310s
IMHO, realtime resolution is inexcusable for a firewall, IDS, realtime sniffer, and/or firewall manager.
Yeah, but your AFAIU(nderstand), your dns database totally ignores dns TTLs which is just plain wrong. Also, how does it handle round robin DNS? How about DNS pools (this one is somewhat easier but still)?
Quite frankly, maybe I'm just not seeing it but I just can't see any advantage to BullDog... For one, configuration seems limited and obscure: what about protos other than tcp/udp/icmp (esp, ah, igmp.....) can you filter them? Is the "firewall" even statefull? If so, why the need to have rules for both ways as in the old stateless firewalls? There doesn't seem to be any interface specifications in the rules; can you have more than 2 interfaces? How do you deal with DMZs (3-legged firewall style) for example?
From what I've seen of sample config files, it only looks lika a bad and very limited imitation of the pf/ipf config formats. What does it do better? In the mean time, I'll stick with OpenBSD's pf thank you.
Ammo
Hello,
The time to live depends on how big it is and how many resources you give it. One company that uses BullDog has an update rate of every couple of hours.
AH and IGMP are protocols I'm still investtigating and working out the packet headers to... I hope to have them soom along with STCP. At this point (until I can get better understanding), unreconized protocols are blocked.
Your security needs may not need the advantages that BullDog does offer. The DNS database is most used un domain based rulles. If you use only IP based rules, the entire section could easily be disabled (making note for compile option).
You can have any number of interfaces, ie:
E eth0
E eth1
E eth2
and so on... There is no limit as long as your system has the resources to process the packet stream. BullDog will dedicate a collector to each interface you have. If you have 20 interfaces (ISP), BullDog will launch 20 collectors.
The 2-sided rule set is mainly a holdover for older systems which BullDog can run on. It also serves for situations in high security where a given connection may be only one way (part of the military specs).
The config developed completely independent if pf. I have considered augmenting it to use a full language set rathe then single letters. Though the single letters do offer simpliticity. This one is still in the air as I gather more input from BullDog users.
As to round robin DNS systems, the resolver BullDog uses performs the same actions as a reverse dig rather then a simple getnamebyaddr().
Stateful as in tracking connections, yes and no. If a system has access to port 11138, that same system may not be allowed access to other ports. This method is also define by military specs.
If I missed anything, please let me know.
I was not suggesting that a "realtime" "resolve on every IP" kind of approach, I simply asked why not simply farm off the DNS caching implementation to services that are already written for it? It seems like unneeded bloat in BullDog, and would be much better left to services that actually do the resolution. If you had a caching-only nameserver on your BullDog box, lookups would be almost equally fast, but it would guarantee that you're adhering to the DNS standard.Quote:
Originally posted here by frpeter
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'm confused, how did BullDog save you but Netfilter didn't, even though both were properly configured?Quote:
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.
They filter out traffic, and they do it on content and domain restrictions.Quote:
Originally posted here by frpeter
Proxy servers only guard in a limited context and not everyu service has a proxy server.
I'm not sure why. What circumstances have arisen that have prompted you to start blocking access to your DNS based on domain names?Quote:
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.
[QUOTE] Originally posted here by frpeter
[B]Here are some hard numbers to support the usage of the DNS Database. I used tcpdump to get these. Packet display omited. The test was run with a count of 1000 packets.
This first run is with inline (realtime) IP resolving.
Must be a busy box for the kernel to pick up and look at over 25 times the number of packets you told it to. Is there any way you could confirm the kernel was droping legitimate packets (as in destined for the host running TCPDump) there?Quote:
$ time tcpdump -q -c 1000
15134 packets received by filter
11922 packets dropped by kernel
real 1m3.847s
user 0m0.050s
sys 0m0.030s
There are two likely scenarios on the dropped packets front:
TCPDump sets the NIC into promiscuous mode, and I know the kernel will drop packets that are not destined for it -- perfectly normal behaviour. That large number of dropped packets may be coming across a hub to other computers on the rest of your network, depending on how you have it setup.
It could also be packet timeouts occurring while sitting in the queue because of how TCPDump handles its lookups (basically pauses the packet queue while doing the reverse lookup). Simply because one app is done that way, it doesn't mean a realtime system couldn't be done more efficiently.
On my firewall here at home (not as busy obviously):
Some of that was the time it took to generate the traffic as I'm the only one currently using our 'net access. :)Code:$ time tcpdump -q -c 1000 > /dev/null
tcpdump: listening on eth0
1032 packets received by filter
2 packets dropped by kernel
real 1m5.209s
user 0m0.017s
sys 0m0.025s
Again on my system:Quote:
The second run is without inline (realtime) resolving. This is how BullDog currently runs, relying on IP resolution from the internal DNS database. IP resolution is handled by 12 (default setting) of its children seperately from the collector and processors.
$ time tcpdump -q -n -c 1000
1000 packets received by filter
0 packets dropped by kernel
real 0m5.434s
user 0m0.000s
sys 0m0.010s
Code:$ time tcpdump -q -n -c 1000 > /dev/null
tcpdump: listening on eth0
1001 packets received by filter
0 packets dropped by kernel
real 0m32.997s
user 0m0.018s
sys 0m0.010s
All you've really shown here is that the manner in which TCPDump does "realtime resolution" is flawed. I fail to see how this means a caching nameserver couldn't do the job just as well while adhering to DNS spec.Quote:
You'll notice immediately that the time for realtime resolution is an unreasonable 1m+ vs 5s for the DNS database usage. Also notice the NO packets where lost when not resolving realtime. If the test where to be repeated for 10,000 packets, the difference would be unsufferable and intolerable. IMHO, the space for the DNS database is more then justified by the performance gain it yeilds.
What's ironic is that of all the things you are talking about BullDog doing, you and others seem to be focused on the DNS side of things. If that's really the primary advantage, then simply use NF and be done with it. You can do domain based rules inside NF; when it sees a rule with a destination of say "www.google.com" it will look up the IP addresses for that name, and apply the rules:
Yes, that creates a huge table if you are blocking gigantic domains, however it is probably a lot faster for NF to handle the large table than keep a huge DNS database file on a drive and search through it for every packet.Code:$ iptables -A INPUT -d www.google.com -j DROP
$ iptables --list -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere 64.233.187.99
DROP all -- anywhere 64.233.187.104
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
$ host www.google.com
www.google.com is an alias for www.google.akadns.net.
www.google.akadns.net has address 64.233.187.104
www.google.akadns.net has address 64.233.187.99