On 6/2/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
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
No, but what's wrong with tying that to an interface to add to the
security of the rule? Why must we have interfaceless rules and have
to reverse engineer how shit is connected just to figure out what the
real impact a given rule might have?
> 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
If office net contains your entire internal IP space, your DMZ is
going to be allowed to get somewhere it's not supposed to.
> 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?"
Ahahahaha, yeah, that's going to happen. You can ask, but I can
guarantee you won't get an answer.
As far as I can see, that would lead to better security too -
something you'd definitely want in a hospital.
You have yet to prove how this is any better. What leads to better
security, trusting that an automated device is going to generate rules
that understand your network, or a human generating rules based on
their understanding of your network and how traffic flows through it?
I'll take the human thank you.
I'd also rather look at 5 screens with 100 rules each than one screen
with 500 - it makes my head hurt having to understand that many rules
at once. It's also easier to comply with audits when I can easily
show the _one_ screen that handles the rules for a client, rather than
having to black out the stuff that doesn't pertain to them.
--Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
