Eric, thanks for providing use cases! Sadly, I think I can dismiss them as requiring per-interface rulebases. At the least, I'll try. You be the judge :-).
Eric W. Bates wrote:
A small IT company. Has a DMZ for their web/mail etc. Has a staff net for their own workstations. Has a test net where they hook up customer machines. Obviously the customer machines are untrusted. Riddled with viruses. Etc. So while you need to allow the port 80 out to the INet so they can update Norton, et al; you do not want to allow port 80 access to their DMZ. Etc. Don't think you can do that without per interface rulesets.
Since the customer machines all have IP addresses, presumably in the same IP subnet, it's as simple as setting up anti-spoofing correctly and creating one rule. Assuming that the firewall has an "external network" network definition: src dst service action customer-net external-net http allow * * * drop
2nd test case: Small local hospital. Lots of service vendors. One vendor has their own T1 and firewall directly into the Radiology department. The radiology department is in multiple spaces thru-out the building (old hospital -- no money); so they are on a VLAN to allow them to be "contiguous". The Radiology vendor needs to be blocked from the rest of the building.
Without information regarding what networks the vendor use, that's going to be hard. Since you say they have a fw, let's make a wild guess and say that it's hiding their internal addresses. How about: src dst service action vendor1-fw radiology-vlan * allow * * * drop
Accounting department. Yet another VLAN. HIPAA restrictions are such that the accounting department has no business on the radiology lan.
src dst service action * * * drop Heh.
Accounting uses a vendor who also has a T1 into the building. This T is bridged [sigh] for reasons I won't go into. They come in on their own interface.
Anything wrong with: src dst service action vendor2-net accounting-vlan * allow * * * drop
Individual physicians have discrete office space they rent from the hospital. They have INet access; but need to be restricted from most of the hospital's servers.
src dst service action office-net external-net http allow * * * drop
No way you could do that without per interface rules.
I can see that it's an advantage if you're clueless about the IP addresses behind those vendor networks. I'm not sure it's an issue though. You can just ask the vendors, "what's hiding behind that fat pipe? which of your boxes need access?" As far as I can see, that would lead to better security too - something you'd definitely want in a hospital. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
