From: Strata Rose Chalup (strata@virtual.net)
Date: Tue Oct 03 2000 - 12:02:01 PDT
Jeff Bone wrote:
> [...]
> OTOH, you seem like a reasonable sort. :-) Would you poke an identd-size
> hole in your firewall if I were your user?
An identd-sized hole? Not sure what you mean by that-- there are safe
versions of identd, identd usually runs on port 113, and one can put
tcp_wrappers or something similar in charge of brokering port 113 if
desired so the exposure is teenimal (smaller than minimal :-) ).
Many folks extend the firewall metaphor a bit too far-- it's not a dam,
a firebreak, an airlock, etc. If I leave port 113 "open" but there's
nothing on my computer that listens to port 113, it's pretty much a
no-op. Unless of course my OS kernel and/or TCP/IP driver set is
subject to buffer overflows or DoS due to crafted-packet attacks. But
those could be set off on legit ports as well.
You'll hear many people say that the real question is about assumed
risk. That's only half the question-- the invisible second half is "vs.
business needs". The sysadmin can only try to communicate the risk
factor to the business folks, and they, not the sysadmin, need to
balance the systems risk of doing something against the business risk of
not doing it. That so rarely gets spelled out, and rarely do sysadmins
acknowledge that the business is the whole reason they get a paycheck,
and its needs should be paramount. That said, the education process
needs to happen so that the business people have a real idea of what
they are leveraging!
So yeah, I'd poke an identd-sized hole in the firewall if my CEO said we
had a business need for it and understood the risk. I'd also work with
the business and/or engineering folks to make sure that whatever was
listening on that port was written according to some security basics
(buffer overflows prevention, etc), included monitoring capability, and
so on. The responsibility goes both ways-- they have to step up to
their responsibility to help protect the company, just as the sysadmin
has to step up to a responsibility to help enable the company.
WRT your sysadmin friend of the screaming matches, neither of you have
taken the time to explain to the other the risks/rewards of what you're
asking for, including both the systems side AND the business side. Give
it a shot!
>[...] the "close all roads" method --- which is the only thing
> possible given the current blurring and shuffling of stack levels in our
> current Internet architecture
FWIW, there are ways to isolate anything if you are meticulous enough
about it, and it doesn't have to cost a fortune in capital though it can
take some time in manpower. Set your borders to clean your TCP/IP
traffic-- auto-protect against SYN floods, deny source-routed packets,
deny stuff that comes in on the external interface but claims to be
internal, etc etc. If you are doing elaborate spoofing games with your
own products, spend a little extra to put each logical dataflow on its
own subnet (not VPN, trust me) and then do your ACLs cleanly against
each dataflow class based on interface and originating subnet.
Once you have a clean TCP/IP flow at a packet level, do your
protocol-based proxying and filtering at the next logical hop. If you
are doing anything involving high-volume services, you are probably
running your own route cloud internal to your cluster anyway and routing
asymmetrically across your colo infrastructure to get maximally good
latency. Take advantage of that dataflow structure and scrub your
outflows if you are concerned about being a waypoint.
Remember that an additional routing hop across the router backbone is
not nearly so expensive (in millisecs) as a hop to a different router--
makes more sense to buy a big chassis and put extra blades in it, and do
your 1st and 2nd hop scrubbing on two different sets of filters via
separate interfaces. That way you can always split the traffic if you
need to by reassigning addresses and adding another chassis.
Remember also that internal backnets/peernets are your friend, in
traffic regulation, internal latency reduction, traffic isolation,
scaleability, and maintainability. I don't mean that everything has to
go through the router internally (shudder) but that you can isolate
certain kinds of traffic (DNS, LDAP, RDBMS lookups, etc) on certain
internal subnets and then just use sample-sniffing for wrong-type
traffic as a watchdog to see that your internal nets are clean. Much
cheaper and easier to lay out than dropping a few hundred K on an HP or
Sun noc monitoring cluster if you are just starting out, and you'll
probably get better info off it.
Cheers,
_Strata
-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Strata Rose Chalup [strata@knownow.com] | strata@virtual.net, KF6NBZ Director of Network Operations | VirtualNet Consulting KnowNow, Inc [http://www.knownow.com] | http://www.virtual.net/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This archive was generated by hypermail 2b29 : Tue Oct 03 2000 - 12:01:58 PDT