Ouch... > The difference is that you said bridged mode firewalls were not > detectable, nobody's claimed that of the other types.
True... I should have phrased that differently. No device is undetectable. > > But why are the internal device trying to connect to a > > service that is not supposed to be on the network anyway? > > I'm not talking about temporarily not available... > > Lots of reasons, policies that don't allow protocols that people are > trying to use, trojans trying to phone home, misconfigured systems... Why tell the trojan it can't phone home that way? Let it try calling, makes it easier to find out what hosts are infected with the trojan. Misconfigured systems will show up in the firewall log and network surveys... > 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. > > How to look at traffic you are not receiving? > > Or are all your switchports configured as monitporing ports? > > If the one to the firewall is not, then you'd better have a > limited number of devices on the far side of the bridge, or your > switch is going to start to have issues with the number of MAC > addresses it can track for that particular port. How many hosts do you have on a segment? /c /b /a? 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. We're network here, not trying to create an as BIG as possible broadcast domain. How many hosts do you see on average in the same segment? Thousands? Don't think so... maybe a couple of hundred max. How many MAC's can a Catalyst handle at the moment, more than 32K. (thank god they fixed that.) > > Nope you're not missing a thing. > > My point was just that a bridged firewall is not a stupid > > bridge, and should only bridge traffic that has to go through > > it, not everything. > > And in a switched environment this is exactly what happens anyway. > > Depends on setup. Exactly my point. > > No it doesn't have to be. The switch port will learn the > > MAC addresses of the devices behind the firewall. > > Are you confident that a switch will do that? For 1 device > behind the firewall, it's a no-brainer, but what if there are 50? 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? And yes, I'm confident, unless my firewalls admin has messed up the config. > Actually, it'll generally be several ARPs, which would have > to be tuned on every device, where with a proxy/proxy-ARP device > you could tune the number and timing of ARPs once at the gateway > and get whatever performance you want (may be important for > transactional systems using failover in some scenerios.) > > In either case, this is only true of the first packet ever, > or after an ARP cache timeout. 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. > But again, only after an ARP cache timeout is this not what > just happens anyway in both cases. For bridged and proxy-arped yes. > > That's a switch failure, not a firewall failure. > > Yes, but a bridged product allows such failures to happen through a > security boundary (depending on configuration)- others don't. Some bridged products allow such failures, others don't. > If we've gone to "pick the right type depending on what you > need to do," then I'm happy. That's how we started off, we were just discussing the specifics ;) _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
