Re: [fw-wiz] Custom Unix server installations -- to harden extensively ?

From: Devdas Bhagat (dvb_at_users.sourceforge.net)
Date: 05/15/03

  • Next message: Keith A. Glass: "RE: [fw-wiz] FW: Interior DMZs (PIX + Firewall of Choice)" 
    To: firewall-wizards@honor.icsalabs.com
Date: Thu, 15 May 2003 03:30:00 +0530

    On 14/05/03 14:12 -0400, Carson Gaspar wrote:
    <snip>
    > An attacker is left with no method for privilege escalation. Removing
    > binaries only stops script kiddies - anyone who has access to run processes
    > on your box can install anything they want (assuming they can create
    > executable files).
    It isn't the script kiddie that this defends against, it is the clueless
    admin who should never have had that level of access in the first place.
    Lacking easy access to tools can mean the difference between said admin
    having to ask for help and not doing damage to a system with a libc
    upgrade without really understanding what it will break, and said admin
    damaging the system badly enough to have to run for backup tapes and
    upgrade disks.

    I personally have found that a centralized build system with proper
    distribution of binaries helps in /keeping/ boxes locked down and
    synchronized.

    The administrator does not have to worry about building software on
    multiple systems, just on one. The lesser the stuff installed, the fewer
    vulnerabilities to watch out for.
    If something is installed, it can easily be activated by another
    application/upgrade/newbie admin. What is not installed, will not be
    activatable, and the admin doesn't need to worry about having to patch a
    bunch of applications for a bug that should not be important but ends up
    being so.

    To sum up, not installing stuff is a precaution against accidents rather
    than a defense against malicious attackers, even though it does act as
    an additional step in filtering them out.

    Start small, and build up as needed is a much easier way of building
    servers, rather than start with everything and then strip out what is
    not needed. At least with Unix like systems, individual services can be
    turned off, with a system like Windows, it is hard for the average admin
    to know what to safely turn off.

    Devdas Bhagat
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Keith A. Glass: "RE: [fw-wiz] FW: Interior DMZs (PIX + Firewall of Choice)"

    Relevant Pages

    • Re: Deny Interactive Logon but Allow Runas
      ... users may also need to install a fix-pack, ... be an admin to install. ... if your secret app is really so bad ... As our users don't have local admin rights they usually have ...
      (microsoft.public.windowsxp.security_admin)
    • RE: Office tries to repair/reinstall
      ... Giving admin rights to everyone is not the solution. ... The file association issue should be also related to the Office 2007 installation. ... I will check the registry and install windows installer. ...
      (microsoft.public.office.setup)
    • RE: Administrator Rights?
      ... but the "run as" secondary logon is sufficient. ... Someone with Admin credentials does not have to be the primary logon for the ... updates to fire and install. ... Windows update will not install ANY update if the Admin is not logged on. ...
      (Security-Basics)
    • Re: Client Installation Issues: SMS 2.0 SP5
      ... Log on locally as LOCAL admin and install. ... Log on Locally as domain user who has LOCAL admin rights. ... The SMS Service account IS a domain admin ...
      (microsoft.public.sms.setup)
    • Re: Getting frustrated
      ... > after I had given her user name admin privileges. ... > between the user accounts. ... I'd like for her to be able to install and uninstall ... > I have another workstation to set up that is XP Pro. ...
      (microsoft.public.windowsxp.security_admin)