On 6/2/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
Bill Marquette wrote:
> > > 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?
It adds nothing to security. Since anti-spoofing is correctly
implemented in our example, filtering by interface is completely
superfluous.
> 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?
The way I see it, if anti-spoofing is correctly implemented, dropping
interfaces from the rule base actually _frees you_ from thinking of
that aspect of network security.
There's no need to figure anything out, you can relax and just think
about the IP layer when creating rules.
> > > 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.
Why would office-net contain the DMZ net?
I think that in our example, the network is appropriately segmented -
DMZ and office-net are two distinct subnets.
> > 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.
If you're managing the security of a hospital, I seriously hope that
hospital management has enough focus that they put some demands in
your direction and some authority in your hands. A primary demand
should be to keep it very secure. That hopefully translates to it
being OK for you to make demands for the hospital's vendors to adapt
to hospital security needs. In return, management would get your
promise that you're keeping it secure.
If a vendor cannot go as far as providing you with a couple of IP
addresses for the hosts that need access to parts of your internal
network, you've got a problem on your hands in that respect, I'd say?
> > 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.
Because of anti-spoofing, the interface limitation is implicit when
the network limitation has been established through the rulebase.
Furthermore, there would now be a source IP address limitation, so in
theory, there's your extra security.
However, the details surrounding how this further limitation actually
translate to better security is fuzzy, I admit. The source IP
limitation is only useful if your vendor does something active to
prevent abuse of those IP addresses.
How can they do that? It probably depends on their network setup, and
is probably a case-by-case thing. Maybe the hospital has guidelines
for it, maybe not.
As an example, maybe they use static IP addresses, lock up any rooms
where there's wall plugs for their internal network, and refrain from
hooking in any wireless equipment.
Or maybe they use DHCP, have their DHCP server assign addresses based
on MACs, and have their switches configured to kick off PCs that
doesn't acquire an IP through DHCP.
That's not important - what's important is that they can tell you
which IPs to consider secure, and you can allow those IPs access, and
if anything bad comes from those source IPs, you can point your finger
at the vendor and his network.
All of the above said, I think that letting a vendor in with constant
access is a security risk to consider in itself.
If the vendor only requires access now and then to service a system,
then a personal authentication scheme might be better suited than a
connection that's constantly open to viruses and hackers. Allowing
access only from employees at the particular vendor that authenticate
themselves first could be something to consider. They could login
through a VPN, for example, and you could log centrally who logs in
when, so you can point fingers at particular employees instead of
entire vendors when they break something.
Hmm.
Long story short: I think it depends.
Having an additional limitation might at best secure you from
accidents and not real security threats, sure. But if it was me, it
would make me feel better to have the extra limitation anyway.
> What leads to better security, trusting that an automated device is
> going to generate rules that understand your network, or a human
> generating rules
If the automation is simple enough to be proven mathematically
foolproof, then I trust that more than a human.
It's not artificial intelligence or anything, it doesn't have to
understand my network - it only has to correctly parse the "this
network's behind this interface" list that I hand to it, so it can
generate anti-spoofing rules.
> based on their understanding of your network and how traffic flows through it?
> I'll take the human thank you.
Humans have limited capacity, so making things simpler leads to better
security in my book. Of course, if the human in question has worked
with per-interface rulebases all his life, then I admit that he'll
probably do a better job with that scheme.
> 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.
Understandable.
I think there are better solutions than grouping them per interface, though.
> 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.
Good point.
Maybe the "only show rules pertaining to these IP networks"
functionality that I outlined earlier may do the job just as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
You know, while this entire dusussion has been raging (for no good
reason) you could have already implemented this behavior and been
happy.
Please, my inbox begs you guys to cut this out. I am tired of it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
