Security Best Practices: The Desktop.

[chsh]

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.

[xmaddness]

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

[ammo]

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...

[bpiedlow]

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

[gore]

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.

[Juridian]

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.

[SexyBadGirl]

Why not code it in Gore++, you won't need to do any debugging.

[gore]

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.

[chsh]

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.

[Juridian]

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.