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."

Comments

not only operating systems,

[ivlad]

... 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

Re:Slashdotted?

[Tezkah]

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.

Impressions

[josephdrivein]

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).

Re:Linux

[SecureTheNet]

The NSA has released it's over version of linux, SELinux, the Security Enhanced Linux.

Re:not needed! Re:Missing guide?

[Hymer]

NSA is deeply involved in SeLinux, as far as I remember... and they have btw. forgotten to mention xBSD too... and AIX... and HPUX... and Tru64...

Re:Missing guide?

[Motherfucking Shit]

Where is the guide for linux?

Right here.

Re:BSDs?

[Homology]

I run two colocated web servers on NetBSD. Both are stock installations and I haven't had any problems. The one thing I would like to see change is that a single IP address can do a dictionary attack on sshd for hours on end without OpenSSH saying "ok lets not listen to that IP address for a while. Getty does this, or something like it, why not ssh?

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:

Protocol 2
PermitRootLogin no
PasswordAuthentication no
ClientAliveCountMax 5
ClientAliveInterval 30
AllowTcpForwarding no
AllowUsers someuser

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.

Link to NIST Server Guide?

[mpapet]

I found the NIST WindowsXP Security guide,
http://csrc.nist.gov/itsec/guidance_WinXP.html

Is there a comparable server guide?

Re:BSDs?

[Poeir]

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.

Re:Great Idea..

[Martin Blank]

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.