Debian Planet








Welcome to Debian Planet

Search

Apt-get into it.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers’ Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You’re not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International

  • DebianForum.de

    (Deutsch)

  • EsDebian

    (español)

  • DebianWorld

    (français)

  • MaximumDebian

    (Italiano)

  • DebianUsers

    (Korean)

  • Debian-BR

    (Português)

  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on irc.debian.org.

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you’ve written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.

    Sponsorship

    DP is sponsored by Xinit Systems and kieser.net.

    Domains paid for and hosted by uklinux.net.

    Buy your Debian merchandise at DebianShop.com.

    Who’s Online

    There are currently, 68 guest(s) and 6 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.

      

    Re: Corporate Web Server (Score: 1)
    by gloryhack on Friday, November 09 @ 08:59:50 GMT

    First things first: If it’s a web server, it needs very few user accounts on it. The ultimate reality (though impractical in most cases) is just two users: root (you) and webmaster.

    Give the user(s) access via FTP only (something like ProFTP that can be chrooted) with no shell at all (/bin/false). This limits the harm that can be done — if you can, you should firewall port 21 so that the wild and woolly internet cannot reach your FTP server’s control port, to keep things nicely under control. Better yet, firewall all except port 80, and 443 if you need SSL. Install SSH, then yank telnetd out by its roots. Make sure that no shell account has any reason to send a password in plaintext across the network.

    If you have to allow for multiple users, so that, say, different departments get their own place in the sun, just take advantage of ProFTP’s chrooting to keep them from clobbering one another’s stuff. If you need to provide mail, I recommend installing qmail but only allowing for delivery by forwarding to the users’ primary accounts, and not allowing for relaying.

    As for Apache, make sure you have a plan for keeping users’ stuff segregated, without making them jump through hoops. Only allow overrides on a case-by-case basis — instead of allowing every user on the box to install formmail, instead install cgiemail for them.

    If you have to provide email, use qmail. It’s weird until you get used to it, but it’s easy and apparently very secure. If you must provide DNS, use djbdns — BIND has a lousy security track record, is hard to get along with, and is best left to those who enjoy that kind of pain. The best bet, though, is to avoid providing any services that can be shoved off on, I mean, provided by, someone else.

    The more services you offer, the more time you will have to spend adminning the thing. Of course, install tripwire and logcheck (or whatever other, similar things you’re comfy with) so the machine can tell you if it’s unhappy, and it should be a set it and forget it installation.

    Provide documentation for every service the machine provides to the clueless, er, uh, web authors. Write it yourself if it doesn’t exist.

    When it comes to updates, my advice is to, whenever possible, wait a few days before implementing them, and search for references to the affected packages in the mailing list archives before installing. I use one criterion to determine if the update goes in before other users have had time to discover brokenness: Is the bug or hole this update fixes so outrageous that I’d think it wise to shut the machine down if there were no fix available? If the answer is yes (leaking company secrets, exposing the LAN to attack, those kinds of things) then cross your fingers and apt-get. If the answer is no, then let the other users out in the world find the new bugs.

    Remember to smile a lot and speak very little when listening to users… it makes ignorance look a lot like wisdom 🙂


    Your Name: Anonymous [ New User ]

    Subject

    Comment

    Allowed HTML:
    <p> <b> <i> <a> <em> <br> <strong> <blockquote> <tt> <li> <ol> <ul>