Lisa, that was an interesting post. On Fri, Oct 31, 2008 at 10:28 PM, Lisa Kachold wrote: > > 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: alandd@consultpros.com > > To: plug-discuss@lists.plug.phoenix.az.us > > 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 - PLUG-discuss@lists.plug.phoenix.az.us > > 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 - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -- :-)~MIKE~(-: