Hi Alan! You are not sending this out to your customer at consultpro.com are you? Laugh? That's okay, I am used to teaching open source solutions!
The question as to what level of security is needed is definitely specific to the use and exposure. You will have risk in this remote desktop solution. It can be a point of entry to your entire operation. While you will be giving trust, you will not want privileges escalated by accident or through interception of a password/pair and nepharious C buffer exploits via remote access. VPN's can be hijacked; logins can be socially engineered; Blackberry and phone systems "password safe" can be displayed through Bluetooth and/or clearly accessed from backups on home Windows systems. [Not all users, necessarily know that their $shares are PUBLIC - so anyone on the same wireless can cruise through their files]. Employees pre-gruntle, will setup backdoors, then trade logins on IRC groups after exit and worse. It's not ethical to allow people trust where they are incapable of carrying that burden. To protect against losing ownership, as you said, a great many tools are implemented by saavy systems engineer/administrator. IpSec is a complete science wherein use is identified with identification of solutions to mitigate risk and potentiate reward; but we will leave those lectures for another exercise. In Fedora SELinux is fairly painless and includes Wizards for setup and resolution of errors. In Novell's Suse, AppArmour is painless and includes extensive low level kernel changes to protect against risks like non-exec stack patches [like Pax and ExecSheild] (developed initially as Immunix by Crispen Cowen). You can also add ExecShield: http://kerneltrap.org/node/644 or Pax: http://pax.grsecurity.net/http://pax.grsecurity.net/ Which protect the kernel against various types of EXEC functions. These are EASY solutions - unless the server changes regularly they will just work! Other recommendationsIt's not ethical tIt's not ethical to allow people trust where they are incapable of carrying that burden to allow people trust where they are incapable of carrying that burden.u 1) Consider running as an XEN virtual in a PAE kernel. Users or exploiters will just break your XEN kernel and not the "real one"; Your disaster recovery post encroachment is a trivial matter of backing off user directories and recreating a new XEN kernel. 2) Be sure that your deliniation between production public and development is punctuated with a COMPLETE BACKUP and CRC check of the binaries. http://serverlinux.blogspot.com/2005/11/binaries-changing-size-in-fedora-core.htm http://www.codebreakers-journal.com/content/view/45/27/ Setup a regular check via Cron to ensure there have been no serious changes to CRC = tripwire does this. Or use a simple file find - diff shell script. Tripwire must be run and configured after build before the system goes production to be of any real use! 3) Disable and/or change permissions for all but essential tools for users. pam.d and sudo are not going to assist you to keep your users from ssh-ing to localhost, or nmap scanning your network, or overflowing binaries then mailing out their results, but file permissions will assist. You can also even give users a restricted shell, depending on what they need to do? http://www.vias.org/linux-knowhow/bbg_sect_01_02b_10.html They can't change directory or list files depending on the way you implement it. 4) Harden: (Distro-dependent) a) Remove all but essential packages, turn off all but essential services (bluetooth/cupsd/lisa/samba), turn down X, (you can run startx later), configure the semaphores. http://www.linux-tutorial.info/modules.php?name=MContent&pageid=291 http://packetstormsecurity.org/linux/admin/lasg-0-1-7.pdf Tripwire must be run and configured after build before the system goes production to be of any real use b) Verify versions of everything you add on - beit OpenSwan or NX VPN tools, each version has known issues. Even using a non-secure Firefox 2.0 without controls to troubleshoot your "server" can open a HUGE door, should you click on a Javascript XSS URI or open an email with an UTF encloding exploit somewhere while searching for a solution. 5) Patch initially and regularly - THIS IS VERY IMPORTANT!!!!!! 6) Use IPTABLES - so that they can't easily setup a SSH tunnel BACK to their house running on a unattended open port. This means you ONLY accept your VPN NX packets etc. and THAT IS all. You can trivially setup this in SUSE using their 3 zone firewall setup utilities. Fedora Core also has extensive examples available that you can tailor to your needs. 7) Scan test your system with a good pentest tool. Be sure you nmap from external IP to verify what you think is closed and what you think is configured correctly is REALLY so! ASSUME nothing! 8) Follow PCI Compliance and Sarbanes/Oxley recommendations: Use secure passwords [8 characters - do not set "passw0rd" as the starting temporary password Require password aging and changes regularly (automate it) May the source be with you, young Jedi night! http://wapedia.mobi/en/Obnosis | http://en.wiktionary.org/wiki/Citations:obnosis | Obnosis.com (503)754-4452Laugh at this MSN Footer ---------------------------------------- > Date: Fri, 31 Oct 2008 16:19:00 -0700 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: SELinux vs. AppArmor vs. Standard vs. What? > > Thanks for all the responses to my remote desktop login question. I'm > pretty sure we will deploy FreeNX for that function. > > This question has to do with the same server. A tech savvy manager > says we should use "NSA Linux" on the remote desktop host server. > What he means is use the SELinux security features. > > Now, I don't have lots of experience with setup and maintainence of > SELinux. I hAve read that it is painful and requires more > administration than just "set and forget." > > A similar technology is the AppArmor profiles for applications. Said > to be easier to use than SELinux but provides much the same benefits. > > Then a third camp seems to think that both of these are overkill and a > headache for the benefits gained. They feel that, configured > correctly, standard user security on a Linux box is secure enough for > most business applications. > > Where do any of you stand on this argument? Is SELinux really a pain > to setup and use? Is AppArmor interesting but not worth it? > > Given the function of the server as I previously described in that > other thread > (http://lists.plug.phoenix.az.us/lurker/thread/20081030.230820.05346d48.en.html#20081030.230820.05346d48), > What security extensions would you deploy and why? > > Alan > --------------------------------------------------- > PLUG-discuss mailing list - [email protected] > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss _________________________________________________________________ You live life beyond your PC. So now Windows goes beyond your PC. http://clk.atdmt.com/MRT/go/115298556/direct/01/ --------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
