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.

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

Quote:

---

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

Quote:

---

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

Dude, this is fun as hell. :)

Quote:

---

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.

Quote:

---

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.

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.

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

Quote:

---

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.

Quote:

---

Originally posted here by gore
Are we allowed to change the office suit?

---

You are allowed to make any recommendation you like.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally posted here by chsh
You are allowed to make any recommendation you like.


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.

---

Oh ****, I'm sorry Chris. I'v been awake a while and need some sleep and prolly should have reread this. Ok, the SSH thing I'll toss out as that method seems fine. I either missed the logging in part or didn't see it, but now it sounds much better ;)

I could be really wrong now, but I was told a long while ago that for a https connection (setup A) to initiazise you also need a http connection first to get the certificates... they told me you need an open port 80 (or at least a different port then 443 for the "normall" http stuff). It's pretty some while ago though, but that's what I recall.
I quite hope they explained wrong.

I didn't really think about improvements yet (drunk), but to add something to my post... You could add to the firewall to restrict outgoing connections from netbios ports (in this case 137-139) to dns (port 53). Or in general, how is the firewall setup besides the port 443? Just allow all other stuff?

Again, I STRESS desktop security only. This is targeted at host-based best practices. We will get to the network level stuff soon enough.

blah... give everyone a knoppix cd and a thumbdrive

Just to toss out a cookie here since no one mentioned it, how about a host based ids such as tripwire?

Maybe set up a central logging server so if a desktop is compromised they will have to work further to wipe out the logs.

And maybe, just maybe, setting up a script or commercial application to monitor the logs and notify an admin or list of people if something wacky is going on.

#3 would have helped greatly with the gaming house chsh mentioned since the compromised machine belonged to a user who was out of town and couldn't access his machine at the times/dates involved.

I'm not quite as expirenced in security as someone who acturally works it, but after a recent career test in school showed that "I'm not made for" Taxi Driving and Lifeguarding (I am a lifeguard?) but I had some stuff a System Admin/Security etc used in work...


As mentioned, Outlook / Outlook Express would need to go since the Preview Function leaves the system vulnerable to all sorts of IE bugs in HTML E-mails. I have heard that Endura is a good e-mail client, but have never used it myself. Since xmaddness mentioned it...

Since Mail Services are provided by the ISP, there is no guranteeing security on their end. I know we are to focus on desktop security, so assuming that there is encryption from the Network -> ISP when getting the e-mail off of the server (I think there is), I would set up the mail client to remove the e-mail from the e-mail server and store a local copy. I know Outlook does this, but since I recommended Endura I can only hope that it offers this basic feature also.

I would keep the current Microsoft Office (unless a higher version is avaliable) but would take time to secure it first by disabling macros from ALL sources. I have yet to run across a valid use of macros in my highschool career, except for maybe creating a document with the correct date/time. I doubt that retyping that information would be too critical to the workers, and it would protect them from macros in untrust worthy (all) sources. A company MS Word template would be created with basic company report format outlined, etc., so the workers wouldn't worry about re-enabling the macros (assuming you can't lock them off).

I would only allow the Administrator and System account write access to C:\WinNT\, so none of the users can try adding new screen savers that have potentially malicious code. I would also require logins to go through a CTRL+ALT+DEL screen to prevent fake login screens, and educate users to only type passwords into these login screens. I realize this won't protect too well against hidden key-loggers, but is a (an albit small) step in that direction.

These computers would also have the floppy drives physically disconnected and unplugged from the motherboard, the CD-ROM/DVD drives would not support burning CDs/DVDs, since the users have access to their personal folders via the Internet which we are assuming is secure. The BIOS would also be locked down, and boot order would be set to HDD, FDD, None. This makes it so that if the system fails for whatever reason, I do not need to retype the BIOS password and risk it being seen by others and spread around the workroom, and eventually into e-mail, forums, et al. I would simply get my (physical) key, unlock the PC case, plug in the FDD, put in my CD or whatnot, and a FDD with LILO/GRUB or other software (found one: http://btmgr.sourceforge.net/ ) that allows booting to continue from the CD/DVD. A password would never need to be entered. Although it could be a pain in the butt to do this a lot of times... Of course before I leave the open computer case would prompt me to disconnect the FDD before locking it back up.

Since all incomming connections (except 443) are dropped/blocked, and since we don't need to be able to connect to all of the 65535 or so ports outgoing, the allowed outgoing port connections would be basically limited to HTTP/HTTPS (80;8080;443), MAIL (???), and FTP (23?). A proxy would probably be used and a history of websites visited can be kept. Unfortunately I do no know how to go about doing this on any computer systems (proxy). Of course the users would be notified of this logging via the legal dialogue box following login to the system. I just looked this up, and http://www.ntop.org/Monitoring.html has some links to monitoring a network with Linux. From that, http://www.ntop.org/ntop.html looks like it could be useful to ensure the network is used as intended and to look up problems. Of course that touches the servers though...

And I don't quite understand how printing is managed. :confused: You say that the Linux server is dc?/Print/File Server. How exactly is it the print server if all of these printers have NICs (which make them serve up themselves on the Windows Protocol)? Or am I not understanding how a print server works? In either case, since the Printer Server I had used a kind of Telnet login for configuration (password sent in clear text), I would put those behind the Linux computer so that if the emploies riot and attack the router to make it act as a hub, the printers wouldn't be effected. Done with three NICs on the Linux Box. (DSL, Printer Network, Windows Network; Printer and Windows Network joined together, DSL connection through proxy...although I don't understand how to do this)

Unfortunately I don't think I could remove Internet Explorer from the 2K boxes, so I'd simply have to patch it ASAP (though there are unpatched problems) and probably disable ActiveX controls with security policy. Also the My Computer section would be locked down, or the cache on the browser would be set to 0 to hopefully prevent loading unsafe pages from cache into the My Computer / Trusted section from doing their dirty work. A pop-up stopper (google toolbar? or anything else...) and programs to prevent home page hijacking (???) would also be installed on these machines so that emploies are not tricked into clicking or loading weird pages.

Also to protect emploies from going to NSFW (Not Safe For Work) sites or other related things, I would get a net filter for the server. I don't know anything thing about this company, but http://www.n2h2.com/index.php might be a net filtering program I'd look at for supporting Red Hat Linux (and possibly other distros). Combined with the NTOP program this would let me see what users are doing on the Internet and I could probably step in if problems occured...

I don't quite know what to do for System B though. At least some stuff from System A could be put into System B, but I don't really know anything about how those systems interact with each other to have any ideas...At this point in time I probably couldn't implement a lot of the stuff I talked about for System A either...

This is a neat discussion. I like reading through what other people would do. Helps get a better grasp of security on the whole. :)

Quote:

---

Originally posted here by Tim_axe
This is a neat discussion. I like reading through what other people would do. Helps get a better grasp of security on the whole. :)

---

That was entirely the point. I'm glad it is appreciated. :)
Eventually, I would like to take all the good points people make throughout a thread, and I'll do up a post based on those, both in summary and in case study format.

i didnt notice if anyone mentioned it but one simple operation would be to rename the local administrator acount on the windows boxs. i would take it one step futher giving the size of the installation and create a new account which would have administrator permissions and disactive the local admin as any real attack will try to find the admins sid rather than its name.

To put things dirrently.. Let me focus on Macro aspect of desktop security.... I shall prefer segregating PC's as Critical Desktops and Non-critical Desktops....

The Best Practices for Desktop should include following points.

1. Installation of only standard OS as decided by the company.

2. All Desktops should be patched with the latest available service pack

3. All Desktops to have Password protected Screen Saver with would activate automatically after 15 Minutes (customizable)

4. All desktops shall be sited behind the main firewalls and protected from external networks. Desktops outside the organizations firewall must have personal firewalls and hardened configurations

5.All desktops shall have authorised anti-virus software installed and configured with latest signature updates also take due care to update Virus engine at regular intervals. Ensure that the users cannot disable the antivirus on their desktops. Try using tools like MCAfee EPO for automatic patch deployment.

6. Train all critical desktop users to backup their data regularly. Try using softwares like stellar for the above purpose

7. No sharing of folders on the desktop.. Instead allocate a file server for common file that need to shared for Projects.

8. Very critical desktops should have boot password

9. In event of Mobile laptops ensure that encryption software is used to secure critical files..., also ensure that all mobile computers have a good personal firewall installed and an upto date Antivirus program installed on it....

10. Conduct security audits of desktops every month.......

11. Ensure standard desktop deployment with only standard desktop softwares (Try using Novell Identity Management services) for universal desktops....

12. Regular User awareness and training programs......

13. Follow Clear screen policy.. i.e No programs to be left active while the user is away....

14. Restrict accecss to outsiders to your work area....... Use visitor badges for clear identification of external users from internal.....

15. Well defined acceptable usage policy for every user

16. Implement a procedure to ensure that the critical data is permanently delted before giving the PC for repairs / replacements / disposal...


I guess this is what I can think of at this point of time.... But this would encompass the activities that organisation has to undertake to secure its desktops. It looks at Technical, process and training related measures which will help organization to raise its level of assurance as regards Desktops are concerned.


Regards


Kalp

ok,
As I mentioned before, it's nearly impossible to secure the desktop without enforcing server side policies but here goes.

Strictly desktop or desktop related.

--Physical
password protect the bios, and don't allow booting from removable devices.

The pc's should lock the desktop after 15 minutes of inactivity.

Policy: all users must lock their desktops when they leave their pc station. Logon hours. Users should only be allowed to login during normal operating hours. Users should not be able to logon locally to the machines.

If the computer case has the ability, lock the case via padlock or other device. (i.e. dells)

--
configure the systems to use ntsyslog or other syslogging type utility to log events to the server. Might as well utilize it...
configure an audit policy for logon events that succeed or fail.
--

IPsec filters on each windows host. Relatively easy to configure. Blocking traffic on key ports to the desktops except from internal hosts, adds an element to the whole buzzword 'defense in depth'. It's not much but it's something.

--
Get rid of IPC shares. They aren't neccessary. The desktops don't need to talk to eachother, Just the server. If an admin share is needed, create it with a non standard name, create a specific account that can use it, and give only that user permission to the share.

--
Centralize Antivirus. considering that linux is used as the server here, I'd switch to kapersky AV. Symantec is a good tool, consider this though, Live update only gets definitions once per week, regardless of how many times you tell it to update(this is barring "emergency" situations with a new and lethal virus.)You'd have to use SARC updates, which is possible and symantec provides a script for it, but you have no centralized control over your clients.
So, switch to Kapersky and centralize the control over AV services.

--
I know this one isn't really "desktop security" but it sure has a lot to do with it.
spam/junk mail etc...specially those containing viruses.. Set up an MTA for the network using something like exim, spamassasin or other BMF and also kill common virus laden attachments(.pif,.exe etc..). After a while spam should disappear for the most part.
--
get rid of outlook express. It's a piece of **** and should be replaced with a better client. Euroda is atleast a bit better even though it is crap as well. Hell, screw the MTA, set up a full blown mail server and use IMAP. oh wait...desktop only... /me hangs his head.

--
patch patch patch, use SUS like ammo said or something of the sort to automate patch rollouts. Keep everyone at the same level of software.
--
I'm tired of this, so that's all for now.

Okay, so what I'm getting from people is the following:
Setup A:
- Swap out Outlook Express for an alternate mail client. Perhaps Eudora or (my suggestion) Thunderbird.
- Install a proxy, and block outbound connections from the machines themselves.
- Disable all unneeded desktop shares.
- Disable booting to removable media in the BIOS
- Password protect the BIOS configuration.
- Lock cases that have the ability to, and favour cases with such security features over ones that do not when looking at upgrading.
- Configure desktops to log to a central logging server.
- Utilize SUS to handle automated critical updates.
- Set domain and local machine policies to restrict logon hours, local logons, etc.
- All desktops should be set to lock the desktop after 10-15 minutes of inactivity.
- Centralize and Homogenize the AV for the network. Consider alternatives to Symantec AntiVirus, as it does not update as frequently.

Setup B
Identical to A, with the additional step of DMZing the network, and blocking traffic between the clients and servers except for on the necessary ports.

Missing anything?

HIDS like tripwire.

I still think the redhat server should be changed. Not just because I don't like 6.X, but also because there won't be any support for it. Might as well change to another distro. They already have Slackware running, and I think that would eb a great replacement for it.

Again, thanks for the great thread, and thanks to everyone for the input/discussion. We need alot more threads like this one, so Chris, make sure the next one is coming soon lol.

EDIT: Scratch that last part, heh, I see the new one :)

Quote:

---

Originally posted here by Juridian
HIDS like tripwire.

---

I'm not entirely convinced that's necessarily a desktop solution. HIDS is more designed for systems that are not constantly in use on a user level. I agree in principle with what you're saying, but I don't know if it's practical to stick a HIDS on every desktop...

Quote:

---

Originally posted here by gore
I still think the redhat server should be changed. Not just because I don't like 6.X, but also because there won't be any support for it.

---

Servers are irrelevant gore.

I agree mostly with the other posters' comments, with a few exceptions.

Setup A:
- Ensure all users are using non-admin logins wherever possible (i.e. hopefully everywhere)
- Only allow domain administrators (and any log on to any other servers with admin or special privs) to log on from authorised locations (by policy, not technically enforcing this rule)
- If you need local admin rights on an individual PC, use the local admin user not the domain admin, ensuring that all workstations have different local admin passwords and different from the server (perhaps you can create some sort of script to set the local admin passwords). This ensures that if a keylogger is present, you don't give it the domain admin pw.

Setup B:

This is a tricky one. Basically, you've got a load of developers, no doubt all of whom have different setups on their workstations. Additionally, it's almost certainly the case that they need admin / root access for their day to day work.

The Windows developers will moan unimaginably loudly if you remove their local administrator rights, even if they have the admin password - due to the fact that the "su" command (what equivalent(s) exist in Windows) are not widely know about, or used, or even can be used. Things like M$ Visual Studio assumes that all web developers are going to have local admin rights, and won't even let you do anything (web dev wise) if you don't.

Slarty

Sorry, forgot the desktop only thing. I posted that when I was waking up and...Sorry, heh.

MsMittens comes in and sticks a magnet over every hard drive

HA!

Shall I add "Lead-lined cases" to the list? ;)

When I did physical security in an old boeing building they were renovating there were entire rooms lined with copper plating to stop any kind of surveilance. Maybe that would be helpful?

I guess a personal firewall solutions for critical desktop is missing....

Again we have listed down all technical points...

Remember you Network is as secured as your waekest link Many a times Humans form this weakes link...

So any best practice which ignores User training / awareness shall fall short of a complete defense program.

Also a mention has to be there for backup solutions aswell.... Remember the three fundamentals of Information Security...

Confidentiality
Which will include

Quote:

---

Swap out Outlook Express for an alternate mail client. Perhaps Eudora or (my suggestion) Thunderbird.
- Install a proxy, and block outbound connections from the machines themselves.
- Disable all unneeded desktop shares.
- Disable booting to removable media in the BIOS
- Password protect the BIOS configuration.
- Lock cases that have the ability to, and favour cases with such security features over ones that do not when looking at upgrading.

---

Integrity

Quote:

---

Configure desktops to log to a central logging server.
- Utilize SUS to handle automated critical updates.
- Set domain and local machine policies to restrict logon hours, local logons, etc.
- All desktops should be set to lock the desktop after 10-15 minutes of inactivity.
- Centralize and Homogenize the AV for the network. Consider alternatives to Symantec AntiVirus, as it does not update as frequently.

---

But we missing on the availailty front...

I guess it should include following

A proper backup solution for backing up the systems to the last good use... Proper backup of critcal files on a separate network Server...

Proper network design to ensure high uptime....

Dependance on trusted carriers in event of mobile communications....