LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Security of VS-NAT versus VS-DR ?

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Security of VS-NAT versus VS-DR ?
From: Roberto Nibali <ratz@xxxxxx>
Date: Fri, 04 May 2001 09:29:41 +0200
> > > indicating that good security on that(those) box(es) leads
> > to a better
> > > topology/architecture from that perspective.  However, keep
> > in mind that
> > > your LVS box(es) then also indicate a single point of
> > failure for your
> > > entire network (think DOS).  Additionally, my own
> > experiences with NAT leads
> > > me to believe that more than anything else it breeds a
> > false sense of
> > > security.
> >
> > Mhh, I couln't think of it, why?
> 
> couldn't think of what?

Oups, my bad English again, I meant: what was your own experience
with NAT the lead you to believe that more then anything else it
breeded a false sense of security?
 
> IMO, if you have thousands of credit cards in your database I think you look
> at security with a bit more of a paranoia viewpoint.  If I have static
> content with no cgi and zero bits of customer information in my database
> security tends to be more lax -- if for no other reason than your setup is
> simpler and easier to maintain.

That's how you see things and I'm happy. So I won't loose my job. I agree
that 99% of the time your example will cause no harm, but since I'm very
paranoid sometimes I have to argue like this. I hope you understand my point.
 
> What should this tell him?  If you're as experienced with firewalls and
> security as you say you are, then you are obviously well aware that you
> disable services that aren't needed.  Additionally, your firewall is your

I hope I didn't misunderstand the last sentence. You do _NOT_ disable 
services that aren't needed. That's the manager's and consultancy company's
approach. You _DO_ disable everything, policy DENY. And you enable what is
needed. Please tell me that you meant that.

> front line of defense and should be as simple as possible.  Some people even

I respect your statement but in my opinion the line of defense should be
as secure as possible. Security has nothing to do with simplicity. However
on the other side, there are a lot of people doing all kind of complex 
setups and gain nothing but "security through obscurity".

> do things like removing most of the commands they don't need on the box,
> removing compilers, et cetera.

:) You never actually hacked a box, did you? I don't relly care if there
is a compiler on the box or not. I don't even care if there is ls or not.
If I get to execute my stuff in the stack of the breached daemon, you're
simply dead! I modify your system you will never recognize it anymore :)
 
> See above.

In my opinion you see it too simple and maybe I'm too focused on high 
security.
 
> Securing email is a completely different story than running a load-balancer
> on your box.  Securing email is protecting your mail server by proxying the
> mail.  This is obviously reasonable, especially if your mail server is
> exchange or sendmail.

Yep, so let's agree that the LVS does load balancing and should not take
over the functionality of a packetfilter too.
 
> Running beta load-balancing software on the box that feeds us all internet
> services is NOT a good idea.  Why don't we run TFTP, NFS, FTP, and TELNET on
> the box while we're at it?  We can 'secure' them by putting them on our
> firewall box.

No comment here! I won't argue about such a stupid argument.
 
> very impressive.  you're amazing.  how does this help our friend who sent in
> an email  asking for help?  Reading your reply to my mail, I get this

I'm visiting him on saturday, I will help him :)

> feeling that you're trying to nitpick me instead of help this guy (which is
> all that I was trying to do).

No, you got it too personally, I just don't want people to push
others in making errors the security community is fighting against
since years. Security is not simple! And Alois, if you feel like
being rushed over by our little fight for glory, please do tell me
so and I shut up.
 
> I was thinking about the benefit of stateful inspection & the size of the
> site.  I don't think ip tables is production ready yet though.. (I'd
> personally wait until kernel 2.4.10).

This is a wise idea :) If you want to have real reliable and stable
stateful inspection, go with ipfw and BSD. It's working since years
already and works like a charm. If we reach 2.4.10 or higher I also
suppose that the code will be stable and tested! enough to be production
ready.
 
> And yes, security budgets (read : alloted resources) and considerations are
> vastly different depending on what you're protecting.  It's all well and
> great to say "secure everything", but we're talking about reality here.  You
> do the best you can as always :).

Yep, absolutely. 

[However I still rather spend more money on more securityand less CPU power 
for the realservers. If to a project manager manager is given 200'000$ to 
set up a e-commerce site he would maybe spend 50'000 for a feasability study 
made by Andersen Consulting, another 100'000 for the expensive SUN Hardware 
(with bad I/O) because Andersen has a special contract with SUN and IBM and 
all the big boys. 25'000 is his bonus, 5000 the loadbalancer, 20'000 for the
programmer, coders, freaks that develop a buggy jave e-commerce application
within 2 months because the customer wanted to go online yesterday. After
you've gone online you do the project launch party. Someone at the party
asks you about security ..., if you're a security engineer, your beer will
taste like shit!] 

Best regards,
Robeto Nibali, ratz
-- 
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`


<Prev in Thread] Current Thread [Next in Thread>