From wadehamptoniv at gmail.com Tue Mar 9 09:47:26 2010 From: wadehamptoniv at gmail.com (Wade Hampton) Date: Tue, 9 Mar 2010 10:47:26 -0500 Subject: [Clip] Several comments/issues with stig-fix scripts Message-ID: <7a57ad2a1003090747x6cd65aebnb6c2276a6fe95201@mail.gmail.com> Thanks for the great scripts. I have a few comments and observations. Some of these may need to be added to a FAQ???? 1) Typo in cat2/gen002820.sh. echo -n "-a exit, always -S acct...." >> /etc/audit/ audit.rules -- remove space before audit.rules 2) Could not login as root at console, hence had to edit the /etc/securetty. 3) Could not su w/o adding users to wheel group. 4) By default I could not login remotely via ssh, had to remove or change /etc/hosts.deny. 5) When building code on a locked-down server, auditd is using more CPU than cc1. Also, it caused my server to halt (kernel OOPS) due to the default rules. 6) There is no script to setup TMOUT so I created one to create /etc/profile.d/tmout.sh and tmout.csh /etc/profile.d/tmout.sh # TMOUT setup for bash TMOUT=900 export TMOUT /etc/profile.d/tmout.csh # TMOUT setup for csh (autologutout) set autologout = 15 Hope these help, -- Wade Hampton From eric at nixwizard.net Tue Mar 9 11:01:10 2010 From: eric at nixwizard.net (Eric Gearhart) Date: Tue, 9 Mar 2010 10:01:10 -0700 Subject: [Clip] Several comments/issues with stig-fix scripts In-Reply-To: <7a57ad2a1003090747x6cd65aebnb6c2276a6fe95201@mail.gmail.com> References: <7a57ad2a1003090747x6cd65aebnb6c2276a6fe95201@mail.gmail.com> Message-ID: <5792267e1003090901ga3b5f80lac2761c6b5c35ea2@mail.gmail.com> On Tue, Mar 9, 2010 at 8:47 AM, Wade Hampton wrote: > Thanks for the great scripts. ?I have a few comments and > observations. ?Some of these may need to be added to > a FAQ???? > > > 2) ?Could not login as root at console, hence had to edit the > ? ? ?/etc/securetty. > > 3) ?Could not su w/o adding users to wheel group. > > 4) ?By default I could not login remotely via ssh, had to remove or > ? ? change /etc/hosts.deny. > > 5) When building code on a locked-down server, auditd is using more > ? ?CPU than cc1. ?Also, it caused my server to halt (kernel OOPS) > ? ?due to the default rules. #2, 3, 4 & 5 are all "features" though, not bugs... for example /etc/hosts.deny defaults to "deny all" because the CLIP guys have no idea what networks to allow in, and if it wasn't there it would be a finding if the box was being audited and had to comply with the DoD STIGs. To fix that example, you wouldn't touch /etc/hosts.deny, you would add something like this to /etc/hosts.allow: sshd : 192.168.1. : ALLOW When added to /etc/hosts.allow, the above line will allow the entire 192.168.1.0/24 network to ssh in I do admit it could make things easier if these had been added to a "I just booted my box after CLIPing it... what now?" FAQ though Eric From bwhalen at tresys.com Tue Mar 9 12:20:28 2010 From: bwhalen at tresys.com (Brandon Whalen) Date: Tue, 09 Mar 2010 13:20:28 -0500 Subject: [Clip] Several comments/issues with stig-fix scripts In-Reply-To: <7a57ad2a1003090747x6cd65aebnb6c2276a6fe95201@mail.gmail.com> Message-ID: On 3/9/10 10:47 AM, "Wade Hampton" wrote: > Thanks for the great scripts. I have a few comments and > observations. Some of these may need to be added to > a FAQ???? > We're glad to see that the community is using some of the work we have done and we greatly appreciate your feedback. One of the things I'm currently working on is a simple user guide for the CLIP project. I'll make sure to add the things you listed into the document. > 1) Typo in cat2/gen002820.sh. > > echo -n "-a exit, always -S acct...." >> /etc/audit/ audit.rules > -- remove space before audit.rules > Thanks for this catch. We have ported all of the system configuration into puppet [1][2] so this has had little testing lately. We'll update this, but will probably be removing these shell scripts in future releases. > 2) Could not login as root at console, hence had to edit the > /etc/securetty. This is specifically denied to ensure auditing of user actions. NSSI-1253 AU-2 and AU-3 require that the system is able to identify which user performed an action. If you allow root to log in at the console the audit system cannot identify which actual user performed an action. By default we want to have any user su to root if they need to perform privileged commands. > > 3) Could not su w/o adding users to wheel group. This is part of role based separation. The system is trying to limit what users can perform privileged actions. > > 4) By default I could not login remotely via ssh, had to remove or > change /etc/hosts.deny. > As Eric said in his reply we lock down the network by default to pass the security compliance checks, specifically the SRR's. > 5) When building code on a locked-down server, auditd is using more > CPU than cc1. Also, it caused my server to halt (kernel OOPS) > due to the default rules. > As a project we always try to err on the side of being overly cautious with auditing. Any edits you have against our default rules that still meet the auditing requirements for your environment would be great. Hopefully the new security compliance framework we are working on will help solve a lot of these issues. > 6) There is no script to setup TMOUT so I created one to create > /etc/profile.d/tmout.sh and tmout.csh > > /etc/profile.d/tmout.sh > # TMOUT setup for bash > TMOUT=900 > export TMOUT > > /etc/profile.d/tmout.csh > # TMOUT setup for csh (autologutout) > set autologout = 15 > We do set the TMOUT variable in the shell scripts inside of gen000500.sh under the cat2 fixes. The Puppet content also sets this variable, specifically the AC-11 module. > Hope these help, > -- > Wade Hampton [1] http://oss.tresys.com/projects/clip/browser/trunk/RHEL5.4/puppet [2] http://reductivelabs.com/products/puppet/ > _______________________________________________ > Clip mailing list > Clip at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/clip Brandon Whalen Linux Solutions Practice Tresys Technology 8840 Stanford Boulevard, Suite 2100 Columbia, MD 21045 Phone: +1 410 290-1411 x147 FAX: +1 410 953-0494 bwhalen at tresys.com | www.tresys.com From eric at nixwizard.net Tue Mar 9 12:36:40 2010 From: eric at nixwizard.net (Eric Gearhart) Date: Tue, 9 Mar 2010 11:36:40 -0700 Subject: [Clip] Several comments/issues with stig-fix scripts In-Reply-To: References: <7a57ad2a1003090747x6cd65aebnb6c2276a6fe95201@mail.gmail.com> Message-ID: <5792267e1003091036u56cfe414l812562e89c96bda4@mail.gmail.com> On Tue, Mar 9, 2010 at 11:20 AM, Brandon Whalen wrote: >> 5) When building code on a locked-down server, auditd is using more >> ? ? CPU than cc1. ?Also, it caused my server to halt (kernel OOPS) >> ? ? due to the default rules. >> > As a project we always try to err on the side of being overly cautious with > auditing. Any edits you have against our default rules that still meet the > auditing requirements for your environment would be great. Hopefully the new > security compliance framework we are working on will help solve a lot of > these issues. Brandon - there are two places you must change settings so that your boxes do not kernel panic. I've personally run into this :) In /etc/audit/audit.rules there's a line: # Failure of auditd causes a kernel panic -f 2 ... you must change the '2' to a '1' to prevent boxes from kernel panic'ing when auditd restarts. Then in /etc/audit/auditd.conf there are various conditions listed, and what action to take if a condition exists. Basically just do a quick search and replace in your favorite editor, and change all the HALT keywords to SYSLOG I would reboot the box just to make sure after implementing these changes... I'm not sure if just doing a 'service auditd restart' is enough After doing these two things I've had CLIP'd boxes that only shutdown or reboot when I'm applying kernel updates (in other words, they're as stable as you would expect from a Linux box) :) If your boxes are being audited by the DoD, this would be something you would have to justify to them, possibly in a Mitigation Strategy Report (MSR). We have centralized logging configured and all the logs forward to a central rsyslog server, so having the boxes not kernel panic if they can't audit was justifiable in an MSR we had to write up. >> 6) There is no script to setup TMOUT so I created one to create >> ? ? ?/etc/profile.d/tmout.sh and tmout.csh >> >> ? ? ?/etc/profile.d/tmout.sh >> ? ? ? ? ? ? # TMOUT setup for bash >> ? ? ? ? ? ? TMOUT=900 >> ? ? ? ? ? ? export TMOUT >> >> ? ? ?/etc/profile.d/tmout.csh >> ? ? ? ? ? ? # TMOUT setup for csh (autologutout) >> ? ? ? ? ? ? set autologout = 15 >> > We do set the TMOUT variable in the shell scripts inside of gen000500.sh > under the cat2 fixes. The Puppet content also sets this variable, > specifically the AC-11 module. I have personally seen the timeout work on boxes I've recently CLIP'd... in ssh sessions I first I get "kicked out" of root, then my user account that I sudo'd from is also logged out. Just letting know know that as far as I know the TMOUT functionality works as intended. -- Eric From bwhalen at tresys.com Fri Mar 5 16:10:13 2010 From: bwhalen at tresys.com (Brandon Whalen) Date: Fri, 05 Mar 2010 17:10:13 -0500 Subject: [Clip] Copy of EULA for CLIP dependency package "ovaldi" In-Reply-To: <2B0195B08BA41748A38C4D58ADF44F2C04B23301@AZ25EXM01.gddsi.com> Message-ID: On 3/4/10 3:16 PM, "Bewsey, Alicia-p99926" wrote: > > > -----Original Message----- > From: clip-bounces at oss.tresys.com [mailto:clip-bounces at oss.tresys.com] > On Behalf Of clip-owner at oss.tresys.com > Sent: Thursday, March 04, 2010 1:14 PM > To: Bewsey, Alicia-p99926 > Subject: Copy of EULA for CLIP dependency package "ovaldi" > The ovaldi package was created and is maintained by Mitre. More information about the project is available at [1][2]. http://oval.mitre.org/oval/documents/docs-06/readme.html http://sourceforge.net/projects/ovaldi/ Brandon Whalen Linux Solutions Practice Tresys Technology 8840 Stanford Boulevard, Suite 2100 Columbia, MD 21045 Phone: +1 410 290-1411 x147 FAX: +1 410 953-0494 bwhalen at tresys.com | www.tresys.com