> This list is the most fun it's been in years now, it's worth > the pain! ;)
Questions on how to setup DMZ's etc are still allowed on the list though ;) > > Why tell the trojan it can't phone home that way? > > Because it may adversely impact the operation of the client (or worse > the network) in a way that whatever dropped it there doesn't. > > > Let it try calling, makes it easier to find out what hosts are > > infected with the trojan. > > You should find that by the rejection logging anyway though. Sure, good thing you can turn the responses on or off. I'd prefer them off, unless it starts impacting the operation. (lazy admins might miss the entries in the logs... ;) > > > Yep, but cutting down on the ammount of traffic you must > > > handle is like having more bandwidth. > > > > A learning bridge does not generate more traffic than would normally > > be on that segment anyway. > > But every bridge mode firewall doesn't operate that way. Not every bridge mode firewalls do, some do. The BRICK does. > > How many hosts do you have on a segment? /c /b /a? > > Depends on what you're firewalling and why- there is a school of thought > with bridge products for internal firewalling that could mean /16s or > bigger on each side of the bridge. Ugly network design. But possible, for that you will need multiple switches, on their trunk ports they need to be capable of handling that ammount of MAC's anyway. I would say that is a network design flaw. > > Most of the time you'll put the firewall as close to your gateway as > > possible. That gives the same amount of MAC's per interface as in > > a routed situation. > > If it's an external firewall, yes (though I think putting a router on > each side is a better solution, which gives the same number of things > in both directions, but negates some of your advantages.) In that situation it would be more wise to use a routed mode firewall. Or when splitting off a DMZ bridge the internal and DMZ, while routing all communicatio with the external. (bridged/proxy-arped and routed in one.) > > How many hosts do you see on average in the same segment? Thousands? > > Don't think so... maybe a couple of hundred max. > > Depends on if it's an internal firewall with VLANs all > sharing the same toothbrush... :) A VLAN capable bridged based firewall creates quite a different environment than a just bridged mode firewall capable of bridging VLAN tagged packets... > > How many MAC's can a Catalyst handle at the moment, more than 32K. > > (thank god they fixed that.) > > Cisco isn't the only switch vendor on the planet- and for some reason > I've got the idea that some low-end vendor might treat anything with > more than 5 MACs as a monitor port for performance reasons (No idea > where I got that impression or if it's true though.) Scary stuff. Cheap Fast Secure/Redundant pick 2. Guess that leaves only cheap for switches like that... > Yep, and I've seen a few "dumb bridge" firewall setups. :) > > Which Vendor's switches are you using? 50 MAC's per port is nothing. > > How about swicth stacking, trunk ports, how do you think they handle > > that? > > a) I'm not confident that all switch vendors behave the same way. Definitly not... neither do all firewalls :) > b) trunk ports get all packets, or all packets not matching a > specific MAC, which is different. Hmmm... indeed, sorry. > > For the proxy-ARPing firewall you are right, in routed mode I > > would say your are right too in a normal situation. > > But as a hacker I would realy not care about the ICMP host > > unreachable/destination unavailable whatever. I'll just keep > > sending packets if it helps me achieve what I try to do. > > The point however was that in low-latency failover scenerios, it may be > advantageous to have level of control if the gateway needs to ARP more > than one address if it doesn't get an answer imeediately due to load, a > downed system, etc. Sorry, I can't follow you. What setup are you thinking of? > Ok, for the generic class, such failures may potentially happen with > bridge mode products, where they won't happen through other firewall > architectures. > > The underlying message is that people need to understand the failure modes > of what they deploy, and how the deployment specifics and architecture > should help shape the selection of the class of product as well as how the > failure modes should assist with the selection of specific products, and > more importantly how much understanding of other componenets (such as > switches) is dictated by an architectural choice (I may have Cat 5500 > today- can I be sure that swapping it out will keep my security level the > same?) On that we can't agree more! _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
