> > Well, first of all a lot of antisp00f stuff are missing. > > Also egress filtering could be wanted. > > You said that other things will be added, so I'll do not add > > any rules, however I think these rules are good for a filter > > not for a firewall. I mean they filter, but don't use all the > > power of THE Packet Filter. > > > > The antispoofing stuff will come later. I'm not sure what you mean about > egress filtering. Due to the nature of the bridge, I am filtering inbound > and outbound (ingress and egress) to accommodate stateful traffic flow.
Yes, I read somewhere: egress filtering = filtering outgoing packets this means - block packets to unwanted/no-route IPs - block packets from unwanted/no-route IPs (external interface) - block packets from IPs different from those active (internal interface) (I mean 10.0.0.1-255 maybe you have only 10 active/assigned IP, well, let pass only those) >From ---> http://www.sans.org/dosstep/ The following is a list of source addresses that should be filtered. 0.0.0.0/8 - Historical Broadcast 10.0.0.0/8 - RFC 1918 Private Network 127.0.0.0/8 - Loopback 169.254.0.0/16 - Link Local Networks 172.16.0.0/12 - RFC 1918 Private Network 192.0.2.0/24 - TEST-NET 192.168.0.0/16 - RFC 1918 Private Network 224.0.0.0/4 - Class D Multicast 240.0.0.0/5 - Class E Reserved 248.0.0.0/5 - Unallocated 255.255.255.255/32 - Broadcast Also if you don't have access to your router, because it's controlled (remotely) by your ISP you could block its IPs from/to on external interface. And so on... > I'm also interested in hearing more on what you mean by the rules > being good for a filter not a firewall - I would say that any packet filter is a > firewall. It was something like a joke to say that those rules you sent were missing all those things related to a "firewall" like antispoof and so... However I could find this logical division: filter: something that filters; most providers filter bo2k port or other port. And we cannot call it a firewall... firewall: a device that make ALL what it can; if it's a packet filter it *must* let pass only what you granted access for. A firewall should be something with a predictable behaviour: after you wrote the ruleset you must be able to tell if a packet will pass or not. "Maybe" isn't allowed. You could think at this logical division also like: filter: you choose what to block (filter) firewall: you choose what to let pass Obviously these are only words... > > Remember the general idea for anyone implementing a transparent bridge is > usually to hide the presence of any packet filtering device. > Well, it is for > me anycase. To this end, such things are return-icmp-as-destination type > rules are not ideal - if that is what you are referring to when talking > about the power of the packet filter.. > PF has *NOT* return-icmp-as-dest. If you sniff ICMP packets sent by PF you'll see the IP of the firewall itself. I talked with Daniel and jason@ about this ;-) Maybe... Bye. Ed
