> > Certainly it is true that packets must "pass through the director",
>
> Not all packets -> is important for the statefull packetfiltering.
I'm talking about an architectural view of LVS-NAT, let's not get too
nitpicky.
>
> > 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?
>
> > You have to ask yourself, what am I actually securing? Is
> it static html
> > that has very little chance of a security breach through
> the webserver? Is
> > it an ecommerce site with credit card #'s being protected? Choose
> > appropriately.. and don't take the path less traveled. :>
>
> IMO, it doesn't matter, if you're running an e-gov site or
> you mom's homepage.
> You have to secure it anyway, because the webserver is not
> the only machine
> on a net. A breach of the webserver mostly leads to a breach
> of the other
> systems too. You don't want that.
>
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.
> > This is not even counting the vast performance hit that NAT
> breeds upon an
> > LVS setup instead of a DR type setup. We're talking a huge
> difference here.
> > If performance and scalability is in your bag then I'd
> highly recommend
> > going with LVS-DR.
>
> How true!
>
> > We're talking about a firewall, right? #1 rule of
> firewalls is.. it's a
> > firewall!!!!
>
> :) rule #1 of fightclub: we do not talk about fightclub!
> Sorry pal, what should this statement tell him? Most of the
> time people
> say firewall and mean packetfilter. I rather speak of
> firewall components,
> such as proxy firewall, packetfilter and IDS. A firewall is
> everything and
> nothing.
>
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
front line of defense and should be as simple as possible. Some people even
do things like removing most of the commands they don't need on the box,
removing compilers, et cetera.
> > Don't do anything like mail or load-balancing if you want a
> > firewall.
>
> Why??? If I take a raptor smtp proxy, I have a pretty much
> secured email
> for example. Why does load-balancing and firewalling not
> belong together?
>
See above.
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.
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.
> > Treat it like it's protecting your business and saving your ass,
> > because it is.
>
> If firewalls were to protect my ass, I'd been shot in five minutes by
> myself!
>
ok..
> > That having been said, I have heard that the main
> stipulation with LVS-DR
> > setup is that you can't have it be both the director and a
> real server.
> > This would seem to indicate that you could pop a few extra
> network cards
> > (dual or quad card would be good) into the box and have it
> be a firewall.
>
> Or you do a proper network design and safe the troubles by
> separating the
> packetfilter from the LVS box. Just my 2 cents ...
agreed.
>
> > There's a huge market for firewalls. I would be amazingly
> surprised if this
> > were actually the case, even in the < $5000 bracket. There
> is lots of
> > specialized hardware that could make your firewall scream out there.
>
> All crap, I've been doing firewall penetration tests since 4
> years. From the
> newest iptables child over Cisco and Checkpoint to full blown
> Raptor firewall.
> I tell you something: The commercial firewalls just suck for
> what they should
> be worth their money. You can crash every checkpoint by
> adding multiple SNAT
> rules with ipmasqadm on the same box, you can crash every
> Raptor in 20 minutes
> with enough SYN-requests if you set up more then 1 external
> interface definition
> and send the packets with SIP == EXT_IF_1. The backlog queue
> of Solaris fills
> up and doesn't get removed because raptor thinks that the
> packet got delivered
> locally. After the memory is exhausted ... BOOM!! Full
> freeze, a STOP-A && sync
> after the 4th time crashed my disk completely. Welcome to the world of
> firewalls!
>
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
feeling that you're trying to nitpick me instead of help this guy (which is
all that I was trying to do).
> > Back to "NAT versus DR": with a NAT architecture, one of
> the main drawbacks
> > and reasons for it being so much of a performance
> bottleneck is the address
> > translation. If you could setup DR architecture with a
> firewall guarding
> > everything with no NAT functionality (read : routable IPs),
> I definitely see
> > a better architecture there.
>
> I agree comopletely :)
>
> > How many hits are we talking about? If this is a busy
> site, then you should
> > very seriously consider going with a custom firewall
> solution (maybe IP
> > tables? Ip chains isn't superb) and DR.
>
> What consideration is this? Security doesn't depend on the
> amount of hits or
> I misread your statement here. "maybe IPtables? Ip chains
> isn't superb"
> Have you actually had a look at the code or why do you think
> it isn't superb
> for filtering traffic to a webserver cluster with LVS_DR running?
>
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).
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 :).
> Best regards,
> Roberto Nibali, ratz
cheers,
Peter
|