I am using FWB 4.01 and am trying out the single interface (not counting lo) host template. I added a few rules which work OK but would like to drop incoming broadcast UDP without logging it. If I don't my kern.log quickly becomes huge. I can add a rule to that effect, right before the final "drop everything" rule, but all broadcast UDP gets through to the last logging rule, whether it is 255.255.255.255 or Class C local broadcast.
I have tried different Destinations including network objects and Addresses, the iptables compile and I can see the rules in there, but it stubbornly continues to log broadcasts.
I don't want to quietly drop all UDP, obviously…
What am I missing here?
how does the rule you are trying to add look like ? The object in destination can be just an Address with address 255.255.255.255 or local broadcast address. Service object should match protocol you are trying to drop without logging.
if you use local broadcast, such as 192.168.1.255, it should match ip address and netmask configured with the inetrface of your firewall. Interface should have the address on the same network and netmask should be correct.
you can use feature of fwbuilder 4.0 that lets you compile single rule to see what firewall configuration is generated. It is explained here: http://www.fwbuilder.org/4.0/docs/users_guide/compile-single-rule.html
If you use iptables, the rule to match and drop broadcasts should appear in the INPUT chain, otherwise it won't work.
Thanks for getting back to me. Your answer gets to the heart of the issue - which is still a problem.
By Listing a network or broadcast address as "Destination" I always end up in some variation of a FORWARD rule.
I had to put the Broadcast IP address (Networks object) as the Source and the firewall name as the destination to get the rule to produce an INPUT rule just on the 172.16.255.255 address.
However, this rule drops by the source, not the destination. I know the iptables output I want, I just can't get fwbuilder to generate it.
This is what I am getting now, which doesn't work:
firewall0 / Policy / rule 6
# Block incoming broadcasts.
$IPTABLES -A INPUT -i eth0 -s 172.16.255.255 -j DROP
Question: What kind of objects do I need do get it to drop this address as the destination?
Let me rephrase that, what SOURCE object will generate an INPUT rule and not a FORWARD?
source does not matter at all, fwbuilder decides on the chain looking at the destination. What is the ip address and netmask of the interface of the firewall in fwbuilder GUI ?
Ah, maybe that is the issue. The IP of eth0 is dynamic. The netmask should be 172.16.255.255, but without a hard IP address I can't enter a netmask. I did insert the mac.
I can get FWBuilder to generate the syntax I want except for the INPUT. It insists on putting FORWARD. Here is the closest I have gotten for this single interface, DHCP based system:
Source: Objects/Networks/LocalLAN Address:172.16.0.0 Netmask:255.255.0.0
Destination: Objects/Networks/LocalLANBC Address:172.16.255.255 Netmask:172.16.255.255
Interface: outside eth0 "Address is assigned dynamically"
Comment: Block incoming broadcasts
$IPTABLES -A FORWARD -i eth0 -s 172.16.0.0/16 -d 172.16.255.255 -j DROP
Desired rule (I think):
$IPTABLES -A INPUT -i eth0 -s 172.16.0.0/16 -d 172.16.255.255 -j DROP
vkurland, thanks again for your help.
I verified that if I (temporarily) add a fixed IP to eth0, FWBuilder will generate an INPUT rule, which does what I want.
However this causes several rules to be built with that fixed IP address, even though this INPUT rule uses only addresses and ranges. This will cause problems, I think, if & when my DHCP assignment changes.
if the interface is configured as dynamic, fwbuilder has no way to know that address 172.16.255.255 (or whatever the netmask really is) is a broadcast. You probably need to filter by protocol. You do not need to drop all udp though, just drop particular protocol that you dont need. For example you could use objects from the standard library to match dhcp packets.
Note that the program should recognize address 255.255.255.255 as broadcast regardless of the configuration of interface. If packets that fill your logs have this address in destination, you can build the rule to match them. This may not be a good idea though because many protocols legitimately use broadcast and if you just block it wholesale, something may break.
That's what I figured. I guess this would be an enhancement request? Iptables can handle this, but FWBuilder cannot, so there is some asymmetry of functionality here.
Filtering by protocol is problematic. In a University setting, there are many custom applications floating around out there. Some use random user-space UDP port numbers. When one side fails, the other side defaults to broadcast and floods the network. The final "drop everything" catches these but logging them fills my /var partition. I'm catching the broadcast (255.255.255.255) ones but local netmasked broadcasts elude me.
I guess the ultimate solution is some kind of installation-time or run-time configurability of interface IP and netmask addresses. Otherwise, FWBuilder will remain limited to infrastructure type appliances.
distinction between INPUT and FORWARD chains is internal business of iptables. I argue that rule designer should not need to know how packet is routed inside the kernel to express security policy.
That said, there is a way to implement this rule in fwbuilder and match only local broadcast as destination address. You need two rules for this:
rule #1 in the main policy:
then create second policy rule set and give it some name, say, "block_local_bcast". Double click on the action in rule 1 and drag and drop this new policy rule set object into the well in the editor
in the rule set block_local_bcast add a new rule :
dst=172.16.255.255 (or other local broadcast address)
direction=both (or inbound)
this should be it
Basically in this setup you match chain in the first rule and match address in the second.
Thank you. This worked and does exactly what I want.
Now I can leave the firewall up and not fill up /var.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.