On Tue, 16 Apr 2002, Schouten, Diederik (Diederik) wrote: > Ouch...
This list is the most fun it's been in years now, it's worth the pain! ;) > > > 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? 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. > Misconfigured systems will show up in the firewall log and network > surveys... Assuming you're doing everything right- but that's a large leap of faith. > > 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. > > > 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? 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. > 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.) > 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. Depends on if it's an internal firewall with VLANs all sharing the same toothbrush... > 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.) > > > 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. 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. b) trunk ports get all packets, or all packets not matching a specific MAC, which is different. > > 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. 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. > > > 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. 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?) Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
