a lot of the features you list below are only useful or usable at the switching layer, and therefore not really fair when compared to what openbsd can do. eg, the dhcp snooping is done on the switches at the client access layer to prevent rouge dhcp servers on an l2 network. unless you put openbsd bridges between each of your client machines and the switch then you cant do that on openbsd.
the feature you do list that is worth comparing is the acl stuff. it is true that on cisco gear you can filter packets (emphasis on packets) in hardware, which is extremely fast, however, you can only filter on attributes of each individual packet. if you want to do stateful filtering though (ie, filter streams/flows of packets), then its a completely different story. personally the decision between openbsd and cisco for stateful filtering comes down to three factors: speed, cost, and the quality/usability of the implementation. i find it far easier to manage openbsd boxes, and i really love the features available to me in pf. i guess im biased since i have some code in there now. i havent had the opportunity to do a speed test between a cisco and my current openbsd firewalls, but i would be extremely surprised if the performance of the cisco scaled at the same rate as the price when compared to the openbsd boxes. so to me openbsd wins based on cost vs performance, and on usability and features. i can do 200 or 300k pps on openbsd systems we bought 2 or 3 years ago for about 5 grand. im not sure cisco sell a stateful firewall module for 5 grand. dlg On 18/02/2010, at 12:05 AM, Tomas Bodzar wrote: > I'm not an expert in this area, but it looks like OpenBSD can do some > parts too and for much more lower price. > > DHCP snooping > > From info on Cisco page it looks like simple combination of > lists/macros for blocking/allowing certain ports. Tables are possible > with OpenBSD too and you can limit flow rate of packets too > > Dynamic ARP Inspection > > If I'm not wrong then pf(4) don't operate on this layer, but then > good, secure and simple design come to game > > IP Source Guard > > sounds like antispoof quick for > > Unicast Reverse Path Forwarding (URPF) > > sounds like block in quick from urpf-failed to any # use with care > > Access Control Lists > > something like SELinux and similar? It's first thing which every good > sysadmin turn off because of unneeded complexity and often bugs too. > If I read this : > > More generally, security ACLs can be used to protect against source > address spoofing or to restrict network access to only legitimate > sources, networks, and applications. For example, ACLs should be used > to deny private address space at the ingress of the Internet and > perform some filtering in the campus such that packets can only > originate from customer-assigned addresses. ACLs should also be used > to deny unused multicast addresses, to prevent multicast DoS attacks. > Another interesting example is that of MAC ACLs which could be used to > deny packets with invalid IP versions. > > then I can say that all of this is possible with pf(4) without need for ACL > > > Quality of Service > > don't know much about this in OpenBSD, but sounds like at least > something similar is possible with this > http://www.openbsd.org/faq/pf/queueing.html > > Port security > > buy HW which is capable to avoid CAM overflow > > CONTROL PLANE AND MANAGEMENT PLANE PROTECTION > > some parts looks like possible with pf(4) some not, but as I said this > must be confirmed by someone who knows much more > > Built-In "Special-Case" CPU Rate Limiters > > read users' stories and try pf(4) you will see that it can handle DoS very well > > > > It's quite long reading, but for me it looks like it's not needed to > spend so much money in most cases. > > On Wed, Feb 17, 2010 at 2:21 PM, Pete Vickers <p...@systemnet.no> wrote: >> On 17. feb. 2010, at 08.47, Claudio Jeker wrote: >> >>> On Wed, Feb 17, 2010 at 03:35:24AM +0200, Kapetanakis Giannis wrote: >>>> On 17/02/10 03:16, FRLinux wrote: >>>> >>>>> Mmmh, you picked my interest here. You mentioned your cisco 6500 but I >>>>> guess you are going to use only gigabit NICs, so you have no need on >>>>> the 10gb range? Just asking, not trying to start a war :) >>>>> >>>>> Cheers, >>>>> Steph >>>> >>> >>>> ps. the cisco crawled when I enabled IOS firewall features (statefull). >>>> Firewall interface == $35K.... come one now... Too much money! >>>> >>> >>> The 6500 and 7600 cisco systems are not able to do stateful firewalling >>> in HW and have also issues with stuff like netflow exports. Unless you buy >>> the super expensive line cards. Even the big SUP boards come with a tiny >>> CPU running at the speed of a loongson -- those can be killed with a few >>> Mbps of multicast traffic. >>> >>> -- >>> :wq Claudio >>> >> >> Just to balance the anti-cisco viewpoint: >> >> If you want to do deep packet stuff in HW, then Cisco offer the FWSM & ACE & >> NAM modules for 6500/7600. >> >> The SUPs (meant for switching/routing, not FWing) support CoPP (control-plane >> policing) in HW, which should be configured to prevent abusive traffic hitting >> the CPU, this (amongst a large list of others) includes high PPS multicast. >> For example see: >> >> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_p >> aper0900aecd802ca5d6.html >> >> >> /Pete
