Security Best Practices: The Desktop.
Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: Security Best Practices: The Desktop.

  1. #1
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255

    Security Best Practices: The Desktop.

    As a result of another recent thread regarding security of default installs, I opted to spawn multiple threads focused on narrow topics, rather than have one thread with a broad topic. In the spirit of this, this is the first in what I hope to be a series of threads designed to generate debate/discussion amongst everyone.

    To start it off, I'd thought it would be more of a challenge to take the tack of putting the desktop before the servers -- mainly because desktops are by design less secure on a local basis than a server.

    For the purposes of this discussion, assume the following:
    Setup A: Small mixed network of 10 Windows 2000 Pro desktops + Linux box w/Samba as a dc/file/print server.
    - Desktops run Windows 2000 Professional SP4, with Norton AntiVirus Corporate Edition configured to update defs every wednesday night at 6 PM, and to scan for viruses every day at 6 AM. Standard software includes Office 2000. The mail client is Outlook Express.
    - Mail services are provided by their ISP.
    - The Linux box also serves out an Apache webserver for staffers situated at staff.domain.com. The webserver only handles Basic auth over HTTPS, and is there only so staff can retrieve documents in their personal folders remotely. It has only the httpd and mod_ssl installed, no extra packages. Apache is 1.3.29
    - A firewall exists between the network and the internet (which is piped in via Business DSL). This is configured so that it only forwards port 443 (HTTPS) to the web server, and everything incoming connection is blocked. Desktops are permitted to surf and FTP and so forth.
    - There are three printers on the network: A LexMark Optra S series with NIC installed, and two HP LaserJet IIIs hooked up to two of the desktops.
    - Never been targeted for attack by a cracker/hacker.

    Setup B: Mid-sized contract developer's network of mixed operating systems. 10 Desktop developer boxes, and 14 servers.
    - 5 of the Developer boxes run Slackware 9.1, the other 5 run Windows XP Pro SP1a.
    - 4 of the servers are linux boxes dedicated to tasks other than development:
    - - One box is running OpenBSD 3.3 serving DHCP, DNS (internal), and acting as the firewall.
    - - - Firewall is configured to allow external access only via the web to the Slackware box housing webmail, and the two Windows servers dedicated to client app. testing, both on TCP/80 and TCP/443. Surfing is allowed similarly to the network above.
    - - Another is running Slackware 8.1 serves mail services only for a webmail client on the same box via Apache and PHP. This is the mail server, as well as doubling as the unix based production test site, where clients having web development done can login to their accounts and see notes from the developers about progress, as well as test the latest copy of the application.
    - - The third box is running Windows 2003 Server, serving out all ASP.NET web applications for clients in similar fashion to the second box.
    - - The fourth box is a Windows 2000 Server box, serving out domain services and file/print sharing.
    - The other 10 servers are
    - - 2 Windows 2003 Servers
    - - 3 Windows 2000 SP3 Servers
    - - 2 Linux Slackware 8.1 Servers
    - - 1 Linux RedHat 6.2 Server
    - - 2 Linux Debian 3.0 Servers
    - All servers are running on a mix of Pentium III/Pentium 4 servers from Dell, with the exception of the 2 Debian servers, which are running on completely new PowerPC 970 servers from IBM.
    - CVS is handled by one of the debian servers, which is still also a nix dev box.
    - There are two printers on the network: an Epson EPL6200 connected directly to the lan and shared by the Windows 2000 print sharing server, and a Lexmark Z22 Inkjet printer, which is hooked up to the print sharing server via USB.
    - Has been the target of a hack once before.
    - Note: The client app testing logins are handled via custom-designed software, which for the purposes of this excercise is impenetrable.

    Now that the gritty details are out of the way, what changes would you encourage (if any) to the two above setups to protect the DESKTOPS. While it may seem redundant to protect desktops at all to some, keep in mind that recently a very high profile game development house got broken into from their desktops.
    This is designed to be an open discussion, so feel free to ask any questions you may have, or offer up suggestions. Please, when you do offer the advice, I want it well researched and looked into. If you like, provide an "at first glance" type post, and then follow up with a real assessment and evaluation of what needs to be done. Break it down step by step if you must. Be very clear and concise about which case you are talking about.

    Keep in mind, this is the DESKTOP we are trying to secure here. You will have an opportunity to comment on the same setups later on for the servers.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  2. #2
    Webius Designerous Indiginous
    Join Date
    Mar 2002
    Location
    South Florida
    Posts
    1,121
    Setup A:

    1) Switch out outlook express for Eudora.
    2) Update Apache to version: 2.0.48 There have been security risks in prvious versions.
    3) Disable FTP and web surfing on the workstations. (Unless absolutly needed, and then limit them by proxy)
    4) Turn off all unneeded shares. (C$, IPC$, etc etc)
    5) Install PC Anywhere for RAT.
    6) Run thru all the running services and streamline them all.
    7) Be sure to grant user privledges appropriately.


    Thats the "At first Glance" run thru of A. Look for a more complete detailed list and my bill in my next post.

    xmad

  3. #3
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    2) Update Apache to version: 2.0.48 There have been security risks in prvious versions.
    There's no need to switch to apache 2.x if 1.3.29, which is the latest release of 1.3.x, does the job...

    Turning off "unneeded shares" just makes things harder to administer and not much safer: as was said in a recent thread, administrative shares require can only be accessed by admin account, and if an admin account was hacked they can create shares by themselves....


    I think the most important part of securing your desktops is keeping them patched and up to date; using something like SUS (or other services alike) helps alot for this.

    Also make sure the anti-viruses don't get deactivated by "inconsiderate" users; developpers are particularly tempted to turn off AV beacause "they know better" or it steals them a few cpu cycles, etc. Symantec corporate as some nice features for this; it can either prevent non-admins from deactivating it or auto-reactivate the AV after X minutes, which can be a good compromise for developpers (who whine that the AV slows down compiles).


    Ammo

    PS: I know you want to concentrate on desktop security, but personnaly, I'd be more concerned by the lack (well at least you didn't mention one) of a DMZ for the Internet exposed services in setup B... Securing the desktops before these services is like barricading the windows without locking the front door...

  4. #4
    5) Install PC Anywhere for RAT.
    No, I'd suggest purchase GoToMyPC for RAT, more costley but doesn't require additional ports to be opened on the firewall and uses better encryption.

    Point in fact: PC anywhere's encryption on all but most recent version can be hacked with DOS basic program posted on many hacker boards. Likewise there most recent version still has many vulnerabilities associated with lack of encryption on some layers of the packets...

    Just to through in my couple cents,

    RRP

  5. #5
    AO BOFH: Luser Abuser BModeratorFH gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177

    Re: Security Best Practices: The Desktop.

    Dude, this is fun as hell.

    Originally posted here by chsh
    [B]Setup A: Small mixed network of 10 Windows 2000 Pro desktops + Linux box w/Samba as a dc/file/print server.
    - Desktops run Windows 2000 Professional SP4, with Norton AntiVirus Corporate Edition configured to update defs every wednesday night at 6 PM, and to scan for viruses every day at 6 AM. Standard software includes Office 2000. The mail client is Outlook Express.
    - Mail services are provided by their ISP.
    - The Linux box also serves out an Apache webserver for staffers situated at staff.domain.com. The webserver only handles Basic auth over HTTPS, and is there only so staff can retrieve documents in their personal folders remotely. It has only the httpd and mod_ssl installed, no extra packages. Apache is 1.3.29
    - A firewall exists between the network and the internet (which is piped in via Business DSL). This is configured so that it only forwards port 443 (HTTPS) to the web server, and everything incoming connection is blocked. Desktops are permitted to surf and FTP and so forth.
    - There are three printers on the network: A LexMark Optra S series with NIC installed, and two HP LaserJet IIIs hooked up to two of the desktops.
    - Never been targeted for attack by a cracker/hacker.
    First, this is awesome, you damn well better make more =)

    Ok, now to business. Firstly, I would change the anti virii to update every night instead of every week. Not long ago there were two viruses I believe that were released within a few days of each other. If these viruses were found out about Wednesday at 7 PM this could be a risk if security is a top priority.

    Are we allowed to change the office suit? If we are alloud to, I would update it to either the newest office system from Microsoft, or possibly change it if this is not possible to another office suite.

    Outlook express would be gone for sure. It's a nice client, but the fact that all you have to do to launch a virii attack on your system is preview a mail....I just don't trust users enough to not preview mail from people. I would change to a mail client that works in text mode of possible...*checks if mutt is available for Windows* WOOT!!! Ok, those people are going to use Mutt as they mail client. Unless I am sadly misunderstanding something, a hostile email message that would react to outlook should not work in mutt as all that shows up is text. Mutt also seems to be more secured. It is also the client I use the most. However if for some reason this is not possible, I'd say I agree with the one Maddy stated.

    The firewall I would change too. I would have it drop connections rather than block. Blocking allows someone too see that you are online in a way, while dropping gives out nothing.

    Also, the users would no longer be aloud to ftp, or web surf unless they absolutly had to. A proxy would be used to limit what they would be aloud to do.

    Setup B: Mid-sized contract developer's network of mixed operating systems. 10 Desktop developer boxes, and 14 servers.
    - 5 of the Developer boxes run Slackware 9.1, the other 5 run Windows XP Pro SP1a.
    - 4 of the servers are linux boxes dedicated to tasks other than development:
    - - One box is running OpenBSD 3.3 serving DHCP, DNS (internal), and acting as the firewall.
    - - - Firewall is configured to allow external access only via the web to the Slackware box housing webmail, and the two Windows servers dedicated to client app. testing, both on TCP/80 and TCP/443. Surfing is allowed similarly to the network above.
    - - Another is running Slackware 8.1 serves mail services only for a webmail client on the same box via Apache and PHP. This is the mail server, as well as doubling as the unix based production test site, where clients having web development done can login to their accounts and see notes from the developers about progress, as well as test the latest copy of the application.
    - - The third box is running Windows 2003 Server, serving out all ASP.NET web applications for clients in similar fashion to the second box.
    - - The fourth box is a Windows 2000 Server box, serving out domain services and file/print sharing.
    - The other 10 servers are
    - - 2 Windows 2003 Servers
    - - 3 Windows 2000 SP3 Servers
    - - 2 Linux Slackware 8.1 Servers
    - - 1 Linux RedHat 6.2 Server
    - - 2 Linux Debian 3.0 Servers
    - All servers are running on a mix of Pentium III/Pentium 4 servers from Dell, with the exception of the 2 Debian servers, which are running on completely new PowerPC 970 servers from IBM.
    - CVS is handled by one of the debian servers, which is still also a nix dev box.
    - There are two printers on the network: an Epson EPL6200 connected directly to the lan and shared by the Windows 2000 print sharing server, and a Lexmark Z22 Inkjet printer, which is hooked up to the print sharing server via USB.
    - Has been the target of a hack once before.
    Ok, first, there is no mention of a firewall or anti virii on the Slack and XP boxes so that would be my first hit. I'd also be sure they were completly up to date on all security patches. As I did above I would disallow surfing and so on unless absolutly needed. Also, for the Windows XP boxes, I would be sure nothing could be installed on the system by assuring that all users had user accounts only. Also there is a firewall and a few other software packages that could limit more of what users could do. I would come up with a plan and see exactly what the users needed to do their work and daily tasks, and block access to everything else. Also, Norton CE would be protected so it could not be shut down. Last time I used this software this was easy to do.

    Next, I would separate the Slackware 8.1 box from being a test site. If there was a compromise, it would be bad enough to screw the web server, but also corporate secrets could be in those projects, and another company would pay someone highly to get them....Also, the "clients" logging in, I think I would first set up a different server for this purpose, and use SSH. One of the clients could possible escelate privs and cause anarchy. This is to much of a risk for any company. They get another box all to themselves running Slackware so that they think it is the same box, and so the same apps can be used.


    The Redhat server is getting out of their too. In my experiance with older redhat distros, they are terrible. I'd replace that server with SuSE if possible, otherwise Slackware or Mandrake would go on it. Everything would be logged and email to the sys admin daily, which is pretty much a default Mandrake and SuSE feature, and would keepm him ahead if someone was trying to break in.

    Also, no where did I see a password policy, which I'm thinking is apart of this thread. A password policy would be enforced, and be similar to the BOFH password policy. The password would have a minimum of 10 chars, and would resemble almost audible line noise. If they have been attacked before, they probably have something someone wants. So the password policy could help out, and also, the machines would have a lock. before and after hours, all machines would first be locked with a steele casing, and also, BIOS passwords would be set on all machines, so if they were stolen data would be hard to read without a BIOS password crack of some sort. This is far from fool proof, which brings me to the next section; Encryption. I would set up encryption on these desktops. Unlike servers, desktops are more commonly stolen. Maybe they are easier to carry, but still they can be stolen easily.

    Also, for a quick fee to the bastard gore inc. company, all employees would have a manditory(sp?) 3 day class to learn about physical security, con artistry, and how to protect themselvesm, and the company, from being scammed. It makes no difference how secure you set up any network to be, any hacker can still easily rely on someone being stupid and or easy to talk into things, so I would teach bullshitting 101.

    Lastly....A company of this size and no DMZ?!?!?!?!?!?!?!?!?!!? Gotta stick SOMETHING in the middle, right?

    Good thread/Idea Chris.
    Kill the lights, let the candles burn behind the pumpkins’ mischievous grins, and let the skeletons dance. For one thing is certain, The Misfits have returned and once again everyday is Halloween.The Misfits FreeBSD
    Cannibal Holocaust
    SuSE Linux
    Slackware Linux

  6. #6
    Ninja Code Monkey
    Join Date
    Nov 2001
    Location
    Washington State
    Posts
    1,027
    Gore > for scenario 2, it all depends on if your windows developers use xp for development or not. From the way I read it, they do...and will most likely wipe the box after you're done to make it usable, or you will be giving them real privileges. Alot of windows developers make their windows dev boxes also act as their 'desktop'.

    I'd also remove cvs from the nix dev box. It's sloppy to have your source control server on a development box. Especially with how prone they are to getting wiped, screwed up, etc.
    "When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
    "There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
    "Mischief my ass, you are an unethical moron." - chsh
    Blog of X

  7. #7
    Banned
    Join Date
    Nov 2003
    Posts
    182
    Why not code it in Gore++, you won't need to do any debugging.

  8. #8
    AO BOFH: Luser Abuser BModeratorFH gore's Avatar
    Join Date
    Oct 2002
    Location
    Michigan
    Posts
    7,177
    Originally posted here by Juridian
    You are more than likely not going to give developers windows boxes with basic user accounts. They will laugh at you or walk out (or in my case, wipe the box and install what I need how I need it) since they would not be able to install the tools they needed or have access to the appropriate privileges to be able to do proper development with visual studio.net . Bad enough they wouldn't have proper permissions to actually debug anything...

    Ahh! Thank you! I knew something was a bit screwed in that part. Heh, Remember, I dont program, and wasn't sure about this, I was just trying to do as much as possible. And J, you can't count on all developers to have the security smarts you have proven you have. But yes, I'll trust you on the part you stated as I do not program and know almost nothing about visual studio. So, sorry about that part.

    If I said something stupid about programming, I'm sorry, I have hardly any experiance in it whatsoever....Add that to being awake a LONG time and it makes it hard to think heh.
    Kill the lights, let the candles burn behind the pumpkins’ mischievous grins, and let the skeletons dance. For one thing is certain, The Misfits have returned and once again everyday is Halloween.The Misfits FreeBSD
    Cannibal Holocaust
    SuSE Linux
    Slackware Linux

  9. #9
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255

    Re: Re: Security Best Practices: The Desktop.

    Originally posted here by gore
    Are we allowed to change the office suit?
    You are allowed to make any recommendation you like.

    Also, the "clients" logging in, I think I would first set up a different server for this purpose, and use SSH. One of the clients could possible escelate privs and cause anarchy.
    I'm sorry I wasn't clearer, I will edit the OP and make this clearer for ya, but the development is all web oriented, and the clients log in via a custom-designed web script that provides them access to their apps and only their apps. For the purposes of this excercise, however, vulnerabilities on the server are irrelevant to the measures you take on the desktop.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  10. #10
    Ninja Code Monkey
    Join Date
    Nov 2001
    Location
    Washington State
    Posts
    1,027
    Originally posted here by gore
    If I said something stupid about programming, I'm sorry, I have hardly any experiance in it whatsoever....Add that to being awake a LONG time and it makes it hard to think heh.
    No problemo. I've recently been through the process of getting boxes set up by admins who don't know about development or the quirks of the environment. Been helping other dev's get their stuff sorted out ever since (like the debugging thing). It makes me sad to see how many developers can't administer their own machines or do basic troubleshooting.
    "When I get a little money I buy books; and if any is left I buy food and clothes." - Erasmus
    "There is no programming language, no matter how structured, that will prevent programmers from writing bad programs." - L. Flon
    "Mischief my ass, you are an unethical moron." - chsh
    Blog of X

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides