daemeonr @
Anthros .
Com@Anthros.Com wrote:
:
: Recently Dieter Dworkin Muller <dworkin @
village .
org> wrote:
:
: => I don't like depending on the CERN server for security-type things, so
: => I might just hack tcp-relay to do the actual proxy work, and have it
: => go to the CERN server to handle caching. Kind of convoluted, but less
: => ugly than trying to prove CERN code correct.
:
: I gather that there is a large user base at your installation to validate
: the quality of your code? Far larger no doubt than the user base that is
: constantly validating CERN? I believe that Bianca Troll might be able to
: direct you to a good recipe for humble pie (ask in the coffee shop).
In general, my approach in security-related areas is very similar to
that which is often espoused here: make it as simple as possible, but
no simpler. None of the HTTP servers available today qualifies as
simple. Adding in proxy support adds complexity. Therefore, I prefer
to separate the two functions -- run the big, full-featured server in
a context where it doesn't matter if it's vulnerable, and have the
small, easily-verified security-enhancing proxy servers running where
security does matter.
I have seen people with very solid credentials in paranoid coding make
mistakes. Nobody is immune to them. If I can't read and understand
the entire program in a reasonable amount of time (nebulously defined,
but certainly in less than eight hours), it's going to be very hard
for me to feel completely secure using it. Even if I *can* understand
the code, I probably still won't trust it completely. Features can
interact, either within a program, or between programs, in such a way
that a vulnerability is produced. There are many well-known instances
of such combinations happening.
For that matter, just because somebody says something is secure is no
reason for me to believe it. If there are a lot of people saying
something is secure, it might bias me towards a similar conclusion,
but I won't believe it without first checking it myself. I trust no
one, including myself. I especially don't trust people I don't know.
My original comments, and those above, apply equally well to any of
the other HTTP servers (actually, any other software in general) that
are out there. I mentioned the CERN server in particular, because
it's the one I'm running (chroot'd, as a non-privileged user, in a
directory tree where nothing is writable except by root).
: => One additional feature of what I'm planning, that became a requirement
: => once we thought of it, is that if someone *does* manage to break in,
: => any outgoing connection they make A) has to be preceeded by a DNS
: => lookup, and B) can/will be logged (I plan on logging all connections).
: => This should make tracking down crackers just a little bit easier.
: => Once we thought of this, the idea of blind automatic translation
: => became much less attractive.
:
: telnet 123.123.123.123 ... oops, no DNS lookup!
And no connection. You need to read my message in the context of the
entire discussion. The scenario is an rfc-1597 network, with
application-level proxies on a multi-homed bastion host. No packets
may go directly from internal systems to the outside world. Getting
out involves:
. the client does a DNS lookup for the outside host name
. the DNS server allocates an unused rfc-1597 address for that name
. configure a virtual interface on the bastion host to respond to
the newly-allocated address
. record the (name, address) pair in the in-addr.arpa domain
. return the false address to the client
. the client sends to the rfc-1597 address it was provided (UDP send,
TCP connect)
. the proxy application notes what address was used for its end of
the transmission
. the proxy does a reverse lookup on the address, which tells it what
name was originally requested
. the proxy then queries a DNS server that is not on the bastion (or
at least isn't the same one that responds to queries from the
rfc-1597 side) for the real address of the named host
. the proxy then sends/connects to the real host
. the proxy proceeds to relay data between the rfc-1597 host and the
external host
. after the virtual interface has been idle for a sufficient period of
time, the interface is turned off and the address returned to the
unused pool
So, a telnet 123.123.123.123 would not work, as packets from an
rfc-1597 host are blocked from leaving the local network (even if I
didn't do it in my packet filters, my ISP does it, and so do most of
the others). Since there's been no DNS lookup, there's no virtual
interface setup to proxy some internal rfc-1597 address for
transmissions to 123.123.123.123.
I'm quite willing to believe there's a loophole in the above design,
but it's not quite as trivial as what you imply.
Dworkin
|
|
