Slashdot Mirror
How The NSA Secures Computers
An Anonymous Reader wrote to mention an NSA site covering secure configuration guidelines for a number of operating systems. From the site: "NSA initiatives in enhancing software security cover both proprietary and open source software, and we have successfully used both proprietary and open source models in our research activities. NSA's work to enhance the security of software is motivated by one simple consideration: use our resources as efficiently as possible to give NSA's customers the best possible security options in the most widely employed products."
... but there are also a few guides to the applications security available: http://www.nsa.gov/snac/downloads_all.cfm
my favorite are Cisco IOS and Microsoft CA guides
Holy shit, have we just slashdotted the NSA? I can't reach the article.
Coral Cache works beautifully, although directly from site wouldn't for me, neither would google's cache.
I have read the OsX guide a year ago and everything was written there seemed obvious to me. (ie usual "Don't use rsh, use ssh" stuff or similar).
Anyway, not a bad guide for beginners (as it's supposed to be).
The NSA has released it's over version of linux, SELinux, the Security Enhanced Linux.
SecureThe.Net - Practical Resources for Securing Systems
They do cover it: the Linux guidance is in the generic UNIX document.
SELinux isn't a distribution, it's a kernel patch and some utilities to enable mandatory access control. Fedora and RHEL both ship with SELinux enabled as standard, full SELinux support has just come through in debian (although much of it has been there for years).
SELinux is a neat solution to a problem that few users have.
/* FUCK - The F-word is here so that you can grep for it */
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
Unless you have weak passwords, then this is not much of of a problem.
In the sshd_config you may disable password logins, and login using a certificate. In addition, you may specify which users/groups that may login:
Many of those automated attempts to bruteforce sshd is run from a Linux machine, so a simple fix (if you use the OpenBSD packet filter that is ported to NetBSD) is qute simply to drop all packets to sshd that is sendt from a Linux computer.
I found the NIST WindowsXP Security guide,
http://csrc.nist.gov/itsec/guidance_WinXP.html
Is there a comparable server guide?
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Anyone happen to run across this info anywhere?
There's some information here about the additional secure authentication methods OS X supports.
~Philly
I wrote a script that did this not so long ago on OpenBSD; unfortunately, that system isn't immediately accessible. What it boiled down to was grepping /var/log/messages for any failed logins, sedding out everything but the IP address, piping the output to sort, doing uniq -c, finding any IPs listed "many" times (for whatever definition of "many" is reasonable), and then piping those IPs to pfctl to add to a blacklist. Since the logs rotate every week, if anyone tries to log in too many times, they'll be permanently blacklisted. Stick the script in a cronjob and call it good. Not exactly user-friendly to implement, but highly adaptable.
Sigs are like bumper stickers.
This is not remotely new. These things have been around for YEARS, and Slashdot covered them at that time. They were written for the use of other government agencies to secure their systems when using the listed products, but they also have a great deal of value to the public. They follow all the things we've been told over the years -- put up layered defenses, stop using old, broken protocols, use those with better hashes, disable unneeded services, reduce your attack surface... Or do you believe that these are things meant to make it easier for attackers to get in?
The guides are a valuable learning tool, too, and a number of companies have followed the idea. In fact, when Microsoft wrote its own guide for securing Windows 2003, the NSA decided that it was comprehensive enough that they didn't have to write one themselves. NSA even went so far as to mirror it themselves, presumably for government convenience.
The pace of the documentation has slowed significantly; for a while, there was a new guide coming out every month or two. But every so often, they cover new topics such as evaluating wireless IDS, as well as some other more esoteric titles like So Your Boss Bought you a New Laptop...How do you identify and disable wireless capabilities. You can see a complete list of titles here.
Go try reading the original material before criticizing it. You might actually learn something and be able to earn your karma through something other than a cheap shot.
You can never go home again... but I guess you can shop there.
Very simple government rule covers this.... Once it has been designated for one security clearance level you may NEVER designate it for use in lower classification level system, though it can be used in an equal or higher level system. And once its in an agency, its way too much of a hassle to share with a different branch, department or agency (the paperwork would eat up any cost savings).