[unisog] Developing "Security Guidelines" email
paulfm at me.umn.edu
Fri Feb 25 23:34:58 GMT 2005
You forgot the Number ONE rule.
Do NOT connect any machine to the network until you have done ALL the below
(or as many as possible).
They may be getting hacked before they can update the machine.
Joshua Beeman wrote:
> On occasion we have receive an email from an IT group on campus that says:
> "Help! We have a machine that we've wiped & built from scratch 3 times,
> and it keeps getting hacked. What should we do?"
> The problem from our perspective in issuing general guidelines to this
> type of request is that every school or center tends to be set up
> slightly different from the next. That said however, we still hope to
> be able to provide a list of things to consider that will be helpful,
> stimulate new thought, etc.
> Towards this end we came up with the list below. Many of the items are
> biased towards the MS Windows OS. If you maintain a similar list
> and/or have any feedback or comments, they would be greatly appreciated.
> Thanks very much,
> 1. P2P - If possible, remove any installed P2P software. Emphasizing to
> the user that this is a common vector for spyware and unintended
> disclosure of information hopefully makes them think twice before
> reinstalling it right after you leave.
> 2. Strong Passwords / Common passwords - Make the user change their
> password and enforce strong passwords. If the user is using the same
> username/password combination they were the first time the machine was
> compromised, or if the user has a weak password, it may not matter
> whether the box was effectively rebuilt or patched. Additionally,
> consider if you are using the same username/password combination (e.g. -
> local administrator password, generic accounts) on multiple machines. A
> compromise on one machine may effect the integrity of multiple machines
> in your domain or on your network. Another reason to enforce strong
> passwords, or longer passphrases, and change them periodically.
> 3. Software firewall - Enable the integrated firewall or install a
> software firewall to block incoming connections. If it is a server, or
> simply a critical host, consider a hardware firewall of the appropriate
> 4. Anti-Virus - Make sure that the latest version of the anti-virus
> client is installed and that the definitions are up to date. If you are
> not already, consider running a managed solution that allows you to push
> AV definitions and upgrades from a central location
> 5. OS Patches/SUS service - Make sure that the operating system is up to
> date at all times. If you are not already, consider running a SUS or
> SMS server, or participating in the University's SUS program
> (http://www.upenn.edu/computing/sus/). Additionally, for Windows
> machines, consider using the Microsoft Baseline Security Analyzer to
> identify vulnerabilities in the OS as well as certain applications
> 6. IPSEC filtering - Consider deploying Microsoft's IPSEC as a Group
> Policy on your domain, or at the very least, on individual hosts. IPSEC
> has two functions:
> a) to protect the contents of IP packets (data integrity) and
> b) to provide a defense against network attacks through packet
> filtering and the enforcement of trusted communication (availability)
> With IPSEC filtering in place, you can restrict incoming & outgoing
> traffic with a granularity not typically associated with integrated
> software firewalls. You can significantly limit, in real-time, the
> potential for internal & external (Penn & non-Penn source) exploits with
> custom rule-sets that are specific to your environment, to a particular
> host, or even to a particular exploit that happens to be circulating.
> A quick search of the Microsoft website will turn up a number of
> documents relating to this topic. I this is one of the clearer MS IPSEC
> overviews (sorry for the long URL):
> 7. Create & Apply security templates - Using the Microsoft Management
> Console with the "Security Configuration and Analysis" and the "Security
> Templates" snap-ins, you can load default policy templates with varying
> degrees of strictness, such as "SECUREWS" (secure workstation) and
> "HISECUREWS" (highly secure workstation), and then compare your current
> configuration to these templates. After reviewing the differences, you
> can save your own template based on the default recommendations and your
> organizations needs and apply this template to computers that you
> support individually or through a Group Policy. Here is some sample
> documentation from MS:
> 9. Imaging - If you are using disk imaging (e.g. - Ghost) to repair
> infected machines and you see compromises quickly *after* re-imaging a
> host, you may need to consider checking the base image for
> vulnerabilities such as the ones listed above and possibly rebuild it.
> If you are unsure about the image and want to set up a test host for
> Security to do a full-blown vulnerability scan, just contact our office
> at security at isc.upenn.edu. Make sure if you request this that it is a
> test or unused system, as a full-scan of this nature can be destructive.
> 10. Restrict end-user privileges - If you are not already doing it, you
> may wish to restrict standard end-users with policies and profiles from
> having the ability to install applications or modify the PC
> configuration in any way. Obviously, this may not work for all
> Joshua Beeman
> Sr. Information Security Specialist
> University of Pennsylvania
> jbeeman at isc.upenn.edu
> (215) 573-6798
> What is the single most valuable piece of data on your computer? Is it
> backed up?
> unisog mailing list
> unisog at lists.sans.org
The views and opinions expressed above are strictly
those of the author(s). The content of this message has
not been reviewed nor approved by any entity whatsoever.
Paul F. Markfort Info/Web: http://www.menet.umn.edu/~paulfm
More information about the unisog