Securing Web Server - Security

This is a discussion on Securing Web Server - Security ; Hello all, I recently put together a web server, running FC3. I'm looking to hear some tips for what are the best security practices for the box. I'm not looking for the box to be put into lock-down, but it ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Securing Web Server

  1. Securing Web Server

    Hello all,

    I recently put together a web server, running FC3. I'm looking to hear
    some tips for what are the best security practices for the box. I'm
    not looking for the box to be put into lock-down, but it is for a small
    web hosting buisness, with several dozen virtual hosts.

    Some specific questions I have:

    -Updates: Is it wise to do nightly yum updates? I don't think that I
    want to always install new kernels... but I tried doing a manual update
    with kernel* excluded and now HAL is failing due to a dependancy. Is
    there a way to do auto-updates and to skip any packages failing
    dependancies? What about a notification to myself about the packages
    that failed that I should look at manually?

    -Log Files: The log file scheme used by default in FC3 seems to lump
    everything together. I've been reading some about how to keep
    different services logging to different file to ease reading. Does
    anyone have any suggestions? What about apache logs? Right now, each
    virtual host has it's own log. Is it advisable to keep a separate copy
    elsewhere in case of a hack attempt?


    Any other tips that you can offer would be appreciated. Thanks in
    advance!

    ~Jeff


  2. Re: Securing Web Server

    > I recently put together a web server, running FC3. I'm looking to hear
    > some tips for what are the best security practices for the box. I'm
    > not looking for the box to be put into lock-down, but it is for a small
    > web hosting buisness, with several dozen virtual hosts.


    There are lots of guides on this, but my main tips would be:

    Run only a web server on that host. Disable all other unnecessary services.
    For instance, if you have DNS servers or email servers put them on separate
    physical hosts. Computers are cheap these days.

    Keep the software up to date. I'm not a fan of automatic updates, I like to
    verify everything myself.

    Unless you absolutely have to, I recommend avoiding extras like the
    database or PHP functions. A web server with cgi, perl, php, mysql is much
    more likely to encounter security problems than a plain web server. If you
    need these extras perhaps put them on a separate physical host. This way if
    there is a security problem, you can disconnect and wipe that scripting
    host while keeping your main web server clean.

    Also how you might configure everything and your network depends to a large
    degree how much you 'trust' your customers, if they will be logging in. For
    example what is their level of technical expertise. Are they likely to make
    mistakes such as installing insecure cgi/php scripts.

    --
    Jem Berkes
    Software design for Windows and Linux/Unix-like systems
    http://www.sysdesign.ca/

  3. Re: Securing Web Server

    In article <1143045497.355728.323650@g10g2000cwb.googlegroups. com>, Jeff Plotzke wrote:
    > Hello all,
    >
    > I recently put together a web server, running FC3. I'm looking to hear
    > some tips for what are the best security practices for the box. I'm
    > not looking for the box to be put into lock-down, but it is for a small
    > web hosting buisness, with several dozen virtual hosts.


    If you can get away with removing PHP, do it.
    Most crackers don't seem to want your box these days,
    they just want to spam through it, and lusers with
    downrev PHPnuke/phpBB/Joomla type junk will let them do it.
    This crap is especially popular with phish spammers.

    If you have to support user-supplied PHP programs,
    rename /usr/lib/sendmail and /usr/sbin/sendmail.
    Then link those names to /bin/true. (Or link it to
    your burglar alarm...) Let PHP's broken-
    by-design mail() function fail. Anybody who wants
    to send mail from PHP can just popen() your real sendmail
    after you tell them where it is.
    Anybody who can't make that change to their PHP
    programs shouldn't be installing PHP programs on your
    machine.

    Next, make a file system you can mount -o noexec.
    Use it for /tmp, /var/tmp, Squirrel Mail's data directory,
    /var/log/apache, anywhere the Web server can write.
    Apache has no business creating its own executables.
    Don't forget to remount it -o exec during the few seconds
    yum is running. Update scripts run in those directories.



    > Some specific questions I have:
    >
    > -Updates: Is it wise to do nightly yum updates? I don't think that I
    >
    > -Log Files: Is it advisable to keep a separate copy
    > elsewhere in case of a hack attempt?


    Methinks you're triple-locking the upstairs window while
    leaving the barn door ajar.
    Crackers have hundreds of thousands of easily exploited
    Linux-Apache-MySQL-PHP boxes these days. (And that's
    just at Theplanet.com...) They're looking for low-
    hanging fruit, in wholesale lots. Remove PHP (or at least
    obscure sendmail) and move sshd somewhere besides port 22
    and they'll pick on someone else's box.

    Cameron


    --
    NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

  4. Re: Securing Web Server

    Cameron L. Spitzer wrote:
    > In article <1143045497.355728.323650@g10g2000cwb.googlegroups. com>, Jeff Plotzke wrote:
    > Remove PHP (or at least obscure sendmail) and


    Is this "real" sendmail, or does postfix's sendmail replacement count
    too?

    > move sshd somewhere besides port 22 and they'll pick on someone
    > else's box.


    I've heard that comment before. It seems that some people are fans of
    moving away from 22 and others are fans of securing sshd's config
    tighter than the defaults. Certainly the latter is a must.

    Cheers...

    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

  5. Re: Securing Web Server

    In article , Kevin the Drummer wrote:
    > Cameron L. Spitzer wrote:
    >> In article <1143045497.355728.323650@g10g2000cwb.googlegroups. com>, Jeff Plotzke wrote:
    >> Remove PHP (or at least obscure sendmail) and

    >
    > Is this "real" sendmail, or does postfix's sendmail replacement count
    > too?


    Any "sendmail." The cracker/spammer wants to put his
    mailing script on a thousand compromised servers.
    His script expects PHP mail() to work. Or maybe it
    expects /usr/{lib,sbin}/sendmail to accept a message on
    STDIN and a thousand addresses in @ARGV.
    That's because it works on 99 out of a hundred LAMP
    boxes. If it doesn't work on your box, is he going
    to spend a lot of time troubleshooting?


    >
    >> move sshd somewhere besides port 22 and they'll pick on someone
    >> else's box.

    >
    > I've heard that comment before. It seems that some people are fans of
    > moving away from 22 and others are fans of securing sshd's config
    > tighter than the defaults.


    The two are not mutually exclusive. Do both if you like.
    Perhaps you have so few users you can find out where
    all the authorized clients are and block the rest of
    the world in iptables. Perhaps your users are smart enough
    to create key pairs.

    The cracker needs to compromise hundreds of boxes for his
    spam run. So he needs to run his dictionary attack against
    thousands or tens of thousands of targets. So he needs to scan
    a hundred thousand IPAs in some hosting range to find sshds
    to beat on. Is he going to scan 65 thousand ports on each of
    the hundred thousand IPAs, or just the port where sshd usually is?
    Try an experiment. Open sshd on port 22 and another sshd on
    some random port between 12 thousand and 42 thousand.
    See which one experiences dictionary attacks.

    There's not *much* security in obscurity. But when you and
    some other guy are running from a bear, you don't
    need to be faster than the bear, just faster than
    the other guy. Why be low-hanging fruit?


    Cameron



    --
    NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

  6. Re: Securing Web Server

    of course, if you were running OpenVMS, you
    could run PHP or Perl or whatever you want
    and not worry about hacks or viruses because
    vms cannot get viruses or hacked ... your web
    server and apps running under it would run with
    NO priviledges except mail and vms mail cannot
    and never has had or passed viruses ...


  7. Re: Securing Web Server

    In article <1143641757.110497.33550@z34g2000cwc.googlegroups.c om>, bob@instantwhip.com wrote:
    > of course, if you were running OpenVMS, you
    > could run PHP or Perl or whatever you want
    > and not worry about hacks or viruses because
    > vms cannot get viruses or hacked ... your web
    > server and apps running under it would run with
    > NO priviledges except mail and vms mail cannot
    > and never has had or passed viruses ...


    The PHP and Perl-CGI exploits I've been talking about
    occur at the application level, not the operating
    system level. If you installed last June's
    phpBB or PHP Nuke on Apache on OpenVMS,
    and got it working as designed, it would have the
    XML-PHP vulnerability. In order to work as designed
    it's got to have a directory under DocumentRoot
    that the Apache process UID can create and execute
    files in. If it's immune to that exploit,
    it won't run the way it's supposed to either.
    The exploit is used to send spam. It uses the
    mail() function in PHP. If the mail() function isn't
    working, PHP Nuke isn't working.

    I couldn't find a price for OpenVMS on HP's Web site.
    Must be really expensive.


    Cameron



    --
    NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

+ Reply to Thread