NSA INFOSEC

The NSA Infosec dept., yes the guys behind SE Linux extensions, provides great guides to lock down your system. They have various guides available for most of the operating systems, routers etc etc.

This is a site I used to frequent a long time ago, and then somehow it got left out. Now, from what I see, they have added plenty of guides etc to the collections. All of these resources are free and for public domain use.

Here is the link to site. I hope you will make use of these documents.

http://www.nsa.gov/snac/downloads_all.cfm?MenuID=scg10.3.1

Labels: cisco, computers, guides, how to, linux, NSA, security, unix, windows

Data Execution Prevention

DEP can be enabled by modifying the system’s boot.ini file or through the Control Panel. The Control Panel cannot be used to configure the AlwaysOn or AlwaysOff setting. Both methods require Administrator privilege on the system.
To enable DEP through the boot.ini file, add one of the following flags to the end of each line in the [operating systems] section:
/noexecute=AlwaysOn
/noexecute=OptOut
Save the changes and reboot the system. These changes can also be made using the bootcfg.exe tool in Windows XP Professional.

Red Hat Enterprise Linux version 3 updt 3 and later, and Fedora Core 1 and later, provide DEP and address space layout randomization as part of the ExecShield feature. It is enabled by default. To verify, issue:
sysctl kernel.exec-shield
The expected output is 1. If the output is not 1, investigate /etc/sysctl.conf and startup scripts, to re-enable ExecShield. ExecShield provides hardware-enforced DEP even on older systems by using the code segment limit on all x86 processors. For further protection, install the kernel-PAE package to make use of the processor’s XD or NX feature.

Labels: computers, how to, NSA, security

Tough Day

I am awake from the last 25 hours. Gonna crash soon, so thought, why not write something about what happened today.

My eyes bulged when I found a couple of latest linux local root exploits those could really harm our servers.. The only methods are to upgrade to the latest kernel, configure, make blah blah, or get the latest patched kernel from RHN.

Here are the reports...

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2451
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2006-3626

Here is the link for the patch from RHN.
https://rhn.redhat.com/errata/RHSA-2006-0574.html

If you run CentOS, just do a yum update and it should fix the issues. How ever I do not like the way Redhat / CentOS deals with their software,l they should always opt for more up to date versions of kernels. In this regard, I feel Trustix is a better option.

So, I compiled the new kernel from source... Havent done this for a long time now. You know, this is what happens if you are stuck with proprietory software which runs only on Whinedoze.

First thing I noticed is that it doesnt need the 'make dep' command. I used a reference .config file from the last redhat kernel tree. compiled, installed, edited all the configs, then, something funny happened. iptables started crying about no support available in kernel. Upon checking found that the bloody module is not present.. I am still wondering what must have caused this because I used a redhat based base config file.

Lots of work to do after I get up :). More photos will be there from my last trip. Gotta shift my systems to upstairs.. Have to hunt a decent GPS and a couple of WRT54GSs for the community networking stuff...

So thats all for today..

*Snore*

Labels: computers, geek, linux, security