|
Looked at it, but the jetty and OB were doodoo. I heard this morning was
good, but went to club vegas last night at brick by brick. Pretty sick,
actually. Tip off is 3pm - we gotta bar-b-q. I'll see whattup with br.
Maybe surf before then - tommorrow?
----- Original Message -----
From: "Roberto Nibali" <ratz@xxxxxx>
To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, May 04, 2001 12:29 AM
Subject: Re: Security of VS-NAT versus VS-DR ?
> > > > 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'`
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
