Re: Dedicated vs. shared hosting?
From: Tony Lawrence (foo_at_pcunix.com)
Date: 03/30/05
- Previous message: klund.spam_at_gmail.com: "Norton Internet Security Download Manager"
- In reply to: Joachim Schipper: "Re: Dedicated vs. shared hosting?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 30 Mar 2005 15:34:23 -0500
Joachim Schipper wrote:
> pcunix <pcunix@gmail.com> wrote:
> <edited for brevity>
>
>>I want as much security as I can reasonably afford and
>>that makes sense.
>>
>>Does the system I contemplated (explained again in the next
>>paragraphs) really increase my security or am I fooling myself?
>>
>>To recap: I visualize server X, a dedicated Linux or BSD system hosted
>>somewhere outside of my office at an appx cost of $70.00 month. It
>>listens on two ports only, 80 and 22. Let's assume that I keep the
>>http side of things as current as possible and we don't take that
>>security into account (for the purposes of this question only, of
>>course). SShd is running, but only accepting connections specifically
>>from host Y, and only allowing pk authentication for one specific
>>non-root account. No password logins, of course.
>>
>>Host Y is another dedicated host, and is only an sshd machine, or maybe
>>its sshd and (anon) ftp. I hate running ftp at all and may drop it
>>entirely, but if I do still run it, does it make sense to run it on Y
>>rather than X? I'm considering X as the most important resource,
>>needing the most security. One account on host Y has put its public
>>key on X.
>>
>>Host Z is my home office box. Public keys for one account will be on
>>host Y only. To get to X, I have to go through Y. I leave no bash
>>history or logs there so if Y is compromized there's no direct
>>knowledge that it can be used to get to X.
>>
>>Does this really increase ssh security at X or am I kidding myself? If
>>it does make sense, does putting anonymous ftp on Y rather than X make
>>sense?
>>
>>I'm just looking for opinions, of course.
>
>
> I'm no expert by any means, but this seems unnecessarily difficult to
> me.
>
> If you pick vsftpd, the most likely route of attack is either ssh or
> the http server - I'll assume you're using Apache httpd. (Note that the
> openssl library is not free of bugs; be careful if you want to compile
> this into vsftpd.)
>
> Your setup sort-of discounts the fact that there are very likely to be
> less secure machines in the datacenter, and that it is quite possible
> that they may be used to sniff your connections. This would make the
> above point pretty much moot.
>
> If you want to protect your sshd from script kiddies, figure out some
> weird entry mechanism - for instance, port knocking (there's at least
> one 'portknockd' out there, though it's not called that - see Google or
> freshmeat), or something (tunneling over HTTP is also possible, as is
> CONNECT over https - though the latter can turn into a big problem if
> not configured very carefully to only allow access to
> www.myhost.com:22). Of course, all this only adds security by obscurity
> - but that's as good as your proposal was, anyway.
>
> Since you cannot get a firewall in this setup, you'll have to harden the
> box as much as possible. The above makes sshd less easily accessible;
> vsftpd isn't likely to give you trouble, so the biggest problem will be
> Apache and her CGI's.
>
> Securing Apache takes the form of compiling your own; you can remove as
> many features as you like, and be sure to pick up mod_security (though
> it's a major pain in the behind, it's also very, very useful, also for
> chroot). Chroot is quite doable, but more fancyful stuff like
> GrSecurity/PaX (kernel patch; the latter part requires you to recompile
> your httpd), ProPolice (partly redundant with the former, but only
> partly; gcc patch, requires recompilation as well), and some form of
> mandatory access control (GrSecurity provides this, as well as SELinux
> and a couple of other things) are troublesome, though worth the effort.
> Alternatively, take something that is paranoid out of the box - OpenBSD
> or Adamantix, for instance. You need to consider Linux' wide deployment
> and great features (PaX rocks, GrSecurity rocks) against the host of
> kernel vulnerabilities discovered lately. (Note: I've never used any
> *NIX but Linux in my life, and will probably continue to use Linux for
> the foreseeable future. This does not mean it does not have it's
> faults.)
>
> If you do use Linux, at least roll your own kernel and use older,
> well-tested parts of code where possible - this will vastly reduce the
> amount of potentially vulnerable code. You may also want to stick with
> 2.4; though 2.6 has nice features, not all those features are
> intentional and documented. ;-)
>
> This leaves CGIs as the most likely entry vector (which they, frankly,
> were to begin with). They are very difficult to secure; at least chroot
> will make it a little harder to wreck the rest of your system, and
> GrSecurity makes it harder to escape from the jail, but this still
> leaves plenty of problems. Try to mount your httpd data disk with the
> noexec option; this will help yet another bit.
>
> People often recommend running PHP as a CGI with suexec; the same goes
> for Perl, and so on. This might be worth considering; an alternative is
> mod_fastcgi. I'll not comment on either, for lack of experience.
>
> If you distrust PHP itself - which is quite a good idea - you might want
> to check out hardened-php as well. However, hardened-php will not aid
> you against the common mistakes in scripts - SQL injection, writing
> arbitrary stuff to disk, that sort of nasty thing. Ultimately, you'll
> have to stick to paranoia and using well-audited code here.
>
> Just some random thoughts...
>
> Joachim
Thanks.. good points. Actually, the hosting company I'm considering
(1and1) just added external firewalls to their dedicated servers, so
that helps a bit. As to PHP, I don't use it at all, being too set in my
Perlish ways to change now..
I've been reading a bit
(http://aplawrence.com/Books/intrusionpreventionsystems.html and
http://www.aplawrence.com/Books/hardeninglinux.html ) and those have
been getting some good ideas from those. My feeling is that the more I
can do, the better off I am, and duplicating effort doesn't hurt - so if
I block whatever at the external firewall, I also have a rule for it on
the machine's firewall, and I make sure the service isn't running and if
applicable has PAM rules too.. I'm probably a little nuts :-)
Probably my biggest fear is stupid mistakes in my own Perl code - I
sanitize output even if it was really not input to begin with, I set
boundaries on everything, I check and double check.. but I know that no
matter what, somewhere I'm going to screw up.. I've been lucky; have
had my site up many years without problems, but as it gets more popular
I know someday somehow someone is going to break it.. either through my
fault or some stupid apache/ssh/whatever bug.
I wish it were a nicer world.. I can understand that people might want
to take me over for some other nasty thing they are after, but I do NOT
understand the mentality of people who just destroy things for the heck
of it.
Thanks for your ideas, they add to my pile..
-- Tony Lawrence Unix/Linux/Mac OS X resources: http://aplawrence.com
- Previous message: klund.spam_at_gmail.com: "Norton Internet Security Download Manager"
- In reply to: Joachim Schipper: "Re: Dedicated vs. shared hosting?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
