
Secure your Linux server - HowTo by the NSA - hyyypr
http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
======
hvs
Looks like they have guides for multiple operating systems:

[http://www.nsa.gov/ia/guidance/security_configuration_guides...](http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml)

~~~
mcritz
I love the level of paranoia. The transparent message of these documents is
that its possible for The Enemy to exploit everything on your system. "Disable
your laptop camera. Disable your computer's audio input."

For the NSA and other top secret uses this makes good sense.

~~~
desigooner
I have duct tape on my Macbook Pro's webcam ever for the last 3 years or so ..

~~~
code_duck
Why not indeed: after hearing that the FBI could remotely activate microphones
on mobile phones when no call was even active, of the story of that school
that used webcams in Macs to spy on students at home with a special system
that disabled the activity light, and knowing the ability for malware to do
any of that: Why do I have this camera facing me all day, when I use it three
hours a week?

~~~
blasdel
There is no way to disable the activity light on a Mac's integrated camera.

In the case of that high school spying incident, the BOFH responsible had
handwaved away the random LED flashes as a bug.

~~~
code_duck
I see, I could be wrong about the particulars of that case. I could see how
someone might not notice or be concerned about the light flashing every now
and then, too.

If the school wanted to disable it though, it wouldn't be impossible for them
since they had access to the hardware. A thin dot of black paint might do the
trick, especially if they peeled back the glass a bit, which is a pain, but
quite do-able. Certainly something people in the NSA would be wary of... it's
a shame that high school students should have to worry about that, too.

------
vanni
They could have done better for OpenSSH securing: they forgot forcing key-
based authentication only and changing default port number.

~~~
gnaritas
> and changing default port number

That's not security, that's obscurity. If your ssh is secure, you don't need
to change your port number.

~~~
16s
If obscurity is useless, then why does the Army camouflage tanks? Why not just
paint them blazing orange/pink and let them stand on their own defenses? There
is a place for obscurity in security and the endless parroting of "security
through obscurity is useless" should stop.

~~~
oasisbob
Obscurity isn't useless in all situations, but in this case it's important to
realize that changing the port number is really only effective in preventing
scanning attacks.

For a targeted attacker, finding the new port is trivial. (There are only 65k
of them...)

Comparing service discovery with maintaining a fog of war isn't really an apt
comparison.

~~~
Joakal
How about using "password" as a password if security is so good? Or do you
suggest people keep track of 255 UTF-8 characters for a password?

An attacker would still need to go through all 65k ports. I would assume by
even false scanning 5 ports, the attacker gets immediately null-routed and
still get no response. I would also hope such programs have a paranoid sense
of security that they would deny user/password if either are false by not even
providing a response as if the program didn't exist.

Due to lack of feedback, users will get inconvenience and confusion why ssh
doesn't work. Much like passwords example, there's a trade off between
usability vs security with varying obscurity levels.

~~~
sorbus
> I would assume by even false scanning 5 ports, the attacker gets immediately
> null-routed and still get no response.

So run the scan using a botnet. Each machine makes one attempt (there are some
really big botnets out there). There's no way for the machine to prevent the
attacker from finding the port being used, unless the machine notices that
lots of requests are coming in from unknown machines and starts refusing all
requests - of course, refusing requests from unknown machines is a good thing
to do if you're being paranoid. Use a whitelist of allowed machines, not a
blacklist of disallowed machines.

~~~
Joakal
Is there really no way for the machine to prevent private ports from being be
known without a specific call? It seems to me that machines are designed to
follow the standard to be nice and respond back [0]. Even with a whitelist, I
have concerns that the machine is opening itself for a DDoS SYN attack by
simply replying back rejections.

[0]
[https://secure.wikimedia.org/wikipedia/en/wiki/Port_scan#TCP...](https://secure.wikimedia.org/wikipedia/en/wiki/Port_scan#TCP.2FIP_basic_knowledge)

~~~
bostonvaulter2
You should look into tar pits:

<http://en.wikipedia.org/wiki/Tarpit_%28networking%29>

------
vegasbrianc
Quite a detailed document. Glad to see the US taxes paying for something
decent for once.

~~~
andymoe
These have been around for years and years. I remember reading one for windows
2000 and NT.

~~~
cmurdock
I took a security class in college that and we used some of these documents to
secure some systems. They're a pretty helpful reference.

------
eck
Section 1.1.1: "Data transmitted over a network, whether wired or wireless, is
susceptible to passive monitoring."

Translation: We don't like those creeps on the other side of the building
either.

~~~
qpleple
And conclusion : turn off the network as well. You never know.

------
recampbell
Is there an OSS package for automating checks for such practices? Ie, security
lint checker?

~~~
IgorPartola
Yes. Have a look at Tiger: <http://savannah.nongnu.org/projects/tiger/>. There
are also much more active solutions. Specifically, take a look at
<http://en.wikipedia.org/wiki/Metasploit_Project>. With Metasploit you can
explore your entire network and try to break into it. I saw a great
presentation on this framework and while it's complex and the learning curve
is high the stuff is fascinating.

Basically, let's say you have a mixed Windows/UNIX network with a single UNIX-
like web server and a strict firewall. Metasploit will automate looking for
vulnerabilities on the exposed web server ranging from known shell and SQL
injection attacks to straight-up buffer overflow attacks on system services.
It will then automate deploying remote exploit, then a local exploit to get
root, and opening up a shell connection to the broken server (can tunnel
traffic through a variety of methods including DNS). It will then help you
scan the rest of the network from this newly rooted machine, doing the same
thing.

The takeaway is that once you get any access to any Windows machine, you've
owned the entire network because there is usually at least one local root
exploit on Windows and then it takes minutes to crack the admin password.
After that, you better pray that each machine has a different admin password,
or else it's game over.

EDIT: BTW, the presenter had some fun ideas/suggestions for what a person
breaking into the machine might do:

* Take a picture of the user using the web cam and set it as the desktop background.

* Take a screenshot and set it as the background.

* Play the sounds recorded through the mic to the speakers.

~~~
qpleple
Tiger doesn't seems ready yet.

"This same tool has now been resurrected and there is ongoing development in
order to make it useful for newer versions of the UNIX operating systems it
supported."

------
pgroves
In all seriousness, is there a shorter "cheat sheet" of this document or
something similar? I'm sure I'm not the only one here working on building a
server side app but has little security experience. "Security" is tough to
give top priority to at a startup and implementing a 200+ page security
protocol isn't realistically going to happen anytime soon.

~~~
kinofcain
In the page hvs linked to above there's a cheat sheet version:

[http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731....](http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf)

------
thibaut_barrere
Is there a tool I could run to check what's described in the document (or
similar) automatically ?

~~~
zwp
Nessus is probably (still) the best for Linux in this field (certainly in the
"free for home use" category): <http://www.tenable.com/products/nessus>

Lots of vendors have offerings in this area. The quality is ... variable. If
you are thinking of getting into this market, then the hard part is not the
scanning engine per se. The more difficult parts are:

* Keeping the policy rule set in sync with reality (changing business policy, attack and vulnerability landscape)

* Maintaining the rule set (are DSLs for non-specialists feasible? service model?)

* Interpreting and actioning the results in a timely fashion (eg <http://measurablesecurity.mitre.org> for some background)

* Intrusiveness (intrusive validation of a test platform requires careful change control -- is test identical to production? intrusive validation of production may lead to shot feet)

* Application, domain-related and physical security (as opposed to system security captured by this document). These things are harder to scan for automatically.

~~~
thibaut_barrere
Thank you for the link and your insight, too.

------
conradev
3.21 - Install the NSA Security Suite to ensure your computer's safety

------
olalonde
Could anyone quickly explain how partitioning helps with security?

~~~
udoprog
Also, as the guide mentions, it's possible to mount the partitions with
different options. As the following (all mentioned in the HowTo, excerpts from
"man mount"):

    
    
      noexec Do not allow direct execution of any binaries on the mounted filesystem.  (Until recently it was possible to run binaries  anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)
    
      nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe ifyou have suidperl(1) installed.)
    
      nodev  Do not interpret character or block special devices on the file system.
    

Of course this is just one less (perhaps improbable) attack vector. Never the
less; many of the mentioned partitions should never have these kind of files
unless it's for a malicious purpose.

Edit: fixed pre and clarification

~~~
Periodic
A common way for an attacker to get root access after exploiting a service and
getting accesses on that service's user account is to download some additional
tools to tmp. Since no one should be running programs from tmp, turning exec
off hopefully gives an attacker with a compromised daemon account no place to
download code that they can then execute.

------
malkia
If Only Sony.... ah... too late for that!

------
tzury
This is a bit out of date (2009) yet contain many Security goodies for Ubuntu
[pdf]

[http://www.securenetwork.it/ricerca/whitepaper/download/Debi...](http://www.securenetwork.it/ricerca/whitepaper/download/Debian-
Ubuntu_hardening_guide.pdf)

~~~
dcposch
No. The original is from 2009; this is a revision dated Sept 14, 2010.

It seems extraordinarily thorough. Is there any recommendation in particular
that you think is no longer relevant?

~~~
soulclap
Where did you find the 2010 revision?

The one from the parent link says VERSION 1.0 - 11/09/2009 (PDF creation date
is October 24th, 2009) and <http://www.securenetwork.it/ricerca/whitepaper/>
links to the same.

------
gks
Does anyone have any other guides like this? I'm using Arch Linux and want to
run nginx on it. I'd like to make sure it's as secure as I can make it before
deploying the website.

~~~
JshWright
Pacman doesn't verify the integrity of packages before installing them. This
is a pretty major security hole, in my opinion.

If you're concerned about running a secure and stable production server, Arch
should probably be your last choice.

Don't get me wrong, I think Arch is a fine distro, I just think rolling
releases are a scary idea for production servers.

------
tintin
_"Use a bios password"_ ... and don't reboot your server when running in a
remote server room?

~~~
Legion
KVM over IP. Type your BIOS password right in.

~~~
tintin
Thanks! I did not know about this. But doesn't this create extra security
issues?

~~~
Legion
Yes, you do have to take the KVM over IP device's security into account, like
any other remote service you expose. It's the same set of problems you face
with securing your other encrypted remote login (SSH) with similar solutions.

------
peterbotond
Interesting, FreeBSD/PcBSD is not on the list. is it due to lesser popularity?

~~~
sliverstorm
There are NO BSD's on the list. I suspect this is due to a few things.

1) How many people actually use BSD in a production environment?

2) If you are the sort to actually use BSD in a production internet-facing
environment, you are probably using OpenBSD and you are probably already so
paranoid about security the NSA has nothing left to teach you

~~~
rdl
BSDs get used a lot in production environments, even in DoD, but they're
usually embedded in devices or otherwise certified and managed as a specific
product, not as a general purpose operating system.

------
peterwwillis
I'll just skip to the juicy bits:

1.1.2 Minimize Software to Minimize Vulnerability

Really, NSA? So you enjoy tracking down broken package dependencies,
installing software 5x a week as developers need it (thus slowing down their
development time), and not having the tools to troubleshoot downed systems
when they're down (and potentially without access to Yum)? Not to mention
having to USE YUM, which is in itself not a fate i'd wish on anyone. If you
actually audit and secure stupid stuff like excess running network services
and setuid-root binaries you are left with one thing: usermode applications
which cannot be used for any attacks. Thus it's not only annoying to not have
software already on the box, it's stupid too.

2.1.1.1 Disk Partitioning

Are you people really stuck in 1998? Are we really still making a separate
partition for /boot? Look, guys. BIOSes could access disks past the 1024th
sector like 10 years ago. And for christ's sake, nobody has ever been saved
from having a 4GB /var/log partition and a 20GB / partition. The disk space is
finite. If you run out, YOU'VE RUN OUT. Just make one bigass partition and
_IMPLEMENT DISK SPACE MONITORING_ and clean up your crappy logs before the
disk runs out. If /var fills up you're fucked anyway, so might as well give it
as much space as possible.

2.1.1.2 Boot Loader Configuration

Oh my god, HOW could we possibly be secure without a password to BOOT OUR
MACHINE. The damn disks and boot partition aren't even encrypted, guys! This
is useless! If i'm at the machine trying to change the boot configuration i'm
just gonna remove the hard drive or use a jump drive and get at the data
myself!

2.2.1 Restrict Partition Mount Options

OK, they redeem themselves here on the partition shit. I still think /tmp
should be tmpfs or a swap partition, but whatever. Mounting user-writeable
partitions with nodev,nosuid,noexec is actually a really effective and easy
way to prevent payloads from being dropped and executed. Of course you can
still just buffer overflow and have at whatever service you want, but it makes
it much more annoying for attackers as they can't just download a payload to
disk and run it. Of course this also means you can't scp scripts as a normal
user and run them; you'd need to make a special account that can write to / or
some other directory which can execute scripts, so you can copy admin
tools/scripts there on the fly for maintenance etc.

2.3.5 Protect Physical Console Access

Again, this is stupid. BIOS password? I'll just remove the CMOS battery. Boot
loader password? I'll use a jump drive or remove the hard drive (or put in my
own and boot to it, then access your disk).

2.5.3.1 Disable Support for IPv6 unless Needed

Too lazy to use ip6tables, huh? Yeah you're right, we'll never need IPv6.

2.5.4.1 How TCP Wrapper Protects Services

REALLY, NSA? Allow only specific IPs or hosts? Are we really talking about
fucking TCP wrappers? If you rely on TCP wrappers you should probably be
fired.

3.5.1 Disable OpenSSH Server if Possible

....how the hell am I supposed to maintain the system then? Use Rsh? Just hope
that nothing ever goes wrong so I never have to log in to troubleshoot?

Clearly somebody just decided to list every single commonly-available-at-
install "security feature" found in modern Linux distros instead of showing
how to implement security best practices and a structure of limited access
control on available services (combined with robust configuration management).
Yes this is all very nice for beginners, but if you're really trying to secure
a machine you shouldn't be giving the task to a beginner.

~~~
static_cast
This guide is written by the NSA so it is reasonable for them to be paranoid
by default.

> 1.1.2 Minimize Software to Minimize Vulnerability

I agree on yum. If the attacker has root and can run yum. It is too late.

In regards to user mode applications: If you have wget, python, gcc on a php-
only shared hosting server and your security depends of open_basedir (bad
idea, don't do this) these usermode applications give you access to all data
on the server.

> 2.1.1.1 Disk Partitioning

> nobody has ever been saved from having a 4GB /var/log partition

This is just plain wrong. If there is no disc-space left all kinds of strange
error beginn to appear - e.g. your emails are not beeing delivered, apache
fails with strange errors, users can't login. Imagine an attacker that wants
to DoS you and he managed to fill your logs with excessive data.

> 2.1.1.2 Boot Loader Configuration

> Oh my god, HOW could we possibly be secure without a password to BOOT OUR
> MACHINE. The damn disks and boot partition aren't even encrypted, guys! This
> is useless!

It is not. I can boot from my USB thumbdrive and my private toolbox is now
part of of the network (I can hijack the MAC and IP-Adress of the computer in
question, can do arp-spoofing. If they use an old version of nfs I can even
gain access to all files on the nfs server, because older nfs versions trust
the client. And I can doing this likely without beeing noticed.

2.3.5 Protect Physical Console Access

Again. I'm into GRUB and and I can edit the linux-boot entry and add
init=/bin/bash and voila I'm root on the machine. Without having to open the
computer.

> 2.5.3.1 Disable Support for IPv6 unless Needed

IPv6 is still not largely deployed and it is a possible attack vector you can
easily avoid unless you need it. I don't see a problem with this approach.

2.5.4.1 How TCP Wrapper Protects Services

It is another onion-ring in your security scheme. You should only permit hosts
that require connections with your system. It is part of a bigger picture not
the whole strategy.

3.5.1 Disable OpenSSH Server if Possible

Why not? E.g. I managed to sniff/can have a look at your E-Mail and you are so
stupid to send plaintext account data around (happens all the time). Without
access to OpenSSH I can't easily login into your server.

They just show a lot of possible attack vectors you can focus on. Taken alone
every point mentioned here sounds kind of useless to implement. But if you
combine all these ideas and implement them across your network/your server you
have better security.

I can't understand why you ridicule this suggestions, they all are important
depending on the context.

~~~
peterwwillis
> I agree on yum. If the attacker has root and can run yum. It is too late.

Having yum is not the problem, it just has really annoying bugs and
limitations.

> In regards to user mode applications: If you have wget, python, gcc on a
> php-only shared hosting server and your security depends of open_basedir
> (bad idea, don't do this) these usermode applications give you access to all
> data on the server.

You're telling me if you're depending on an un-secure method of operation that
it could be un-secure?

> This is just plain wrong. If there is no disc-space left all kinds of
> strange error beginn to appear - e.g. your emails are not beeing delivered,
> apache fails with strange errors, users can't login. Imagine an attacker
> that wants to DoS you and he managed to fill your logs with excessive data.

Having your logs partition fill up is not something that's supposed to happen
anyway. This is what we have log rotators for. Some software fails to work
entirely once logs can't be written. Bottom line: if your partition is filling
up, you're screwed. Be proactive and put in place limits, log rotation, and
disk alerts.

> It is not. I can boot from my USB thumbdrive and my private toolbox is now
> part of of the network (I can hijack the MAC and IP-Adress of the computer
> in question, can do arp-spoofing. If they use an old version of nfs I can
> even gain access to all files on the nfs server, because older nfs versions
> trust the client. And I can doing this likely without beeing noticed.

Spoofing network shit has nothing to do with physical security.

> Again. I'm into GRUB and and I can edit the linux-boot entry and add
> init=/bin/bash and voila I'm root on the machine. Without having to open the
> computer.

Yes. And it'll take me a whole 5 minutes (or less) to do the same thing with a
bootloader password. Congratulations, you have been owned by security through
obscurity.

> IPv6 is still not largely deployed and it is a possible attack vector you
> can easily avoid unless you need it. I don't see a problem with this
> approach.

Like I said. Learn ip6tables. You'll need it soon.

> It is another onion-ring in your security scheme. You should only permit
> hosts that require connections with your system. It is part of a bigger
> picture not the whole strategy.

Iptables _does this already_ and does a much better job.

> Why not? E.g. I managed to sniff/can have a look at your E-Mail and you are
> so stupid to send plaintext account data around (happens all the time).
> Without access to OpenSSH I can't easily login into your server.

What the fuck are you talking about? Sniffing my e-mail? Look. OpenSSH is a
pretty secure codebase. Lock it down more and use 2-factor and it's pretty
goddamn reliable. And everybody needs remote access to their boxes, and this
is as good a solution as anything else.

Yes, I agree that combining many methods to secure a system makes it much more
robust/secure in general. But you need to have more than just a guide to
hardening a system. It takes a certain mindset and a particular idea of _just
how secure_ you want your system. Even following everything in this guide I
could probably still own a variety of machines if they were maintained and
used carelessly.

I ridiculed the suggestions because it's the goddamn NSA. They should be able
to come up with a better guide than this, and one which is realistic for both
the individual at home and the large enterprise network admin. This shit looks
like an infosec intern threw it together from other online hardening guides.
And like I said originally, yes, it's a beginner's guide at the most, but it
does a disservice to those that will use it and wave it as a flag to show
they've hardened their machine. Now amateurish admins will tell their bosses
"I just hardened our server according to the NSA's specifications!" and the
boss will jump and clap with giddy moronic glee, because that's what bosses
do. And they'll still get owned.

~~~
static_cast
I agree on your conclusion. After re-reading your original post and my answer
It seems that I misunderstood some of your points.

After skimming through the guide again, I also found that certain security
related aspects are not included. There is no discussion about sensible
ressource limits and other topics.

I found the guides from the german BSI (a goverment agency for information
security) much better.
[https://www.bsi.bund.de/EN/Publications/publications_node.ht...](https://www.bsi.bund.de/EN/Publications/publications_node.html;jsessionid=3BCD46AC05B9125196407522C71F482A.2_cid165)

------
squamigera
Anyone find an attempt to install any backdoor? :D

------
nuclearsandwich
tl;dr: Don't take security advice from organizations whose job is spying on
you.

I don't know about anyone else. But the NSA is one of the last organizations
I'd let give me security advice. I wouldn't put it past them to purposefully
omit a pointer or two in the hope that those who follow the guide to the
letter not knowing any better will leave a way in. Based on the other comments
the advice is banal rubbish. Perhaps this is purposeful.

~~~
patrickyeon
Part of the NSA's mandate is protecting US interests and communications as
well. My personal favourite example of this is the changes they recommended to
DES while it was being established that strengthened DES against differential
attacks, a class of attacks that was not publicly known of until years later
[http://en.wikipedia.org/wiki/National_Security_Agency#Data_E...](http://en.wikipedia.org/wiki/National_Security_Agency#Data_Encryption_Standard_.28DES.29)

~~~
lorlandar
A more secure _society_ wouldn't have secret agencies operating in peacetime.
Why? Because their mandates, budgets, policies are also secret and subject to
mission creep.

~~~
udoprog
Except that this specific document comes with good advice and rationale. There
is nothing here that indicates a secret agenda. It's not as if the document is
telling you to install a backdoor for them.

