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.
> 1.1.2 Minimize Software to Minimize Vulnerability
The NSA have different priorities to you. If you want to install all software possible, like in a software shop, fair enough.
There's nothing wrong with yum, so ignoring that point.
> 2.1.1.1 Disk Partitioning
It's better to keep /boot separate so that when you upgrade, say, your ext3 root filesystem to ext4, your bootloader will keep on working if the upgrade were to b0rk.
> 2.1.1.2 Boot Loader Configuration
Say the machine is in a cage in a rack. There is a BIOS password to prevent you changing the boot order and other settings. In this case a password for the boot loader could make sense.
> 2.3.5 Protect Physical Console Access
The machine is in a cage in a rack. A locked cage.
> 2.5.4.1 How TCP Wrapper Protects Services
TCP wrappers can give application level warnings that iptables can't.
> 3.5.1 Disable OpenSSH Server if Possible
If possible. You could admin using a kvm if you wanted, but yeah disabling OpenSSH is kinda silly, restricting to a management subnet is better.
I'm pretty sure the NSA still has to maintain their vast networks of computers. You don't need to be in a software shop to eventually require a new dependency. Networks of servers are hardly ever static. At some point you will need to deploy/upgrade/patch an application, troubleshoot an error or a network glitch, or support some added functionality. It is far less problematic to have the software available than deal with the potential fallout of problems of maintaining such a network and its access to installing software remotely.
Also, clearly you have never read the source to yum or dealt with its myriad bugs and functional inconsistencies. Let me just tell you that indeed, yum is horrible, and I urge you to avoid it whenever possible.
> It's better to keep /boot separate so that when you upgrade, say, your ext3 root filesystem to ext4, your bootloader will keep on working if the upgrade were to b0rk.
What are you going to do with a system with only a /boot partition? Install busybox? If you want a new filesystem you should be kickstarting via PXE and reinstalling the whole thing, not upgrading in place.
> Say the machine is in a cage in a rack. There is a BIOS password to prevent you changing the boot order and other settings. In this case a password for the boot loader could make sense.
If you've got physical access to the machine in the cage you can do anything you want, which includes bypassing BIOS and Bootloader passwords in about 5 minutes.
> The machine is in a cage in a rack. A locked cage.
You've never noticed that the cages are easy to scale? If i'm going to attack the datacenter i'm going to have a fake badge and pick up the key at the front desk anyway. Trust me, most datacenters are not really that hard to get into. NSA datacenters on the other hand...
> TCP wrappers can give application level warnings that iptables can't.
No, iptables can give you the exact same warning tcpwrappers will, which is access control based on host or IP. There are lots of ways to replicate it with iptables. The more important thing to note is that it's fucking retarded to rely on host or IP level access control of a network service. It's somewhat useful in preventing mass brute-force network attempts, but you should also have iptables rules in place to stop that.
> If possible. You could admin using a kvm if you wanted, but yeah disabling OpenSSH is kinda silly, restricting to a management subnet is better.
A kvm won't transfer files for you and it's usually pretty hard to script 1,000 KVMs to run automated commands in 10 minutes.
>It is far less problematic to have the software available than deal with the potential fallout of problems of maintaining such a network and its access to installing software remotely.
The purpose of this document is to make the system as secure as possible. It's not meant to make deployment or maintenance easier.
Is it problematic to have things you might need somewhere else? Sure. Can keeping those processes running on the system make it less secure? Probably. The entire reason you keep the smallest subset of executables, scripts and processes running is so you avoid any potential holes.
The NSA is choosing security over convenience. For systems that actually contain information that needs to be secure(medical/financial records, governmental data, etc.), I definitely wouldn't choose the convenient choice over the secure one.
You want a really secure system? Turn it off and unplug it, then lock it in a cave underground. With a really big lock. That's REALLY inconvenient, but REALLY secure. In real life you can't just choose security over convenience... it needs to be convenient enough for people to do their work, even if that means being potentially not as secure as possible.
And really, this document doesn't go nearly far enough to really harden your average Linux machine... jesus christ they don't even mention what services will run under what roles, reduced capabilities, device ownership... it's a really bare minimum document. But that's not why I critiqued some sections. I critiqued them because some parts are, to me, just stupid.
Like I mentioned twice, there is no potential for a security compromise from simply having excess "files" on a system. You have to actually have a security hole which can be taken advantage of by those files.
What are the files in question? Well, all sorts... icons, manuals, libraries, executables, .... ah, there's where we might see some potential for a security hole (heh, realistically even the icon files could be, but that's out of scope). And how could an executable by itself be a security hole? Usually it's got some modified permissions which allow it to run as another user (commonly root). They should be designed to be secure against an attack but nothing is bug-free. So you know what you do? You remove those permissions. Suddenly it's just a normal executable with the same capabilities as any other executable on the system (of which there are many even on a minimal system).
To accomplish this monstrously difficult task you can simply follow the rest of the NSA guide and it will secure these files for you. Hence, it was (imho) stupid for them to tell you to only install what you need, as their own guide removes any possibility that these excess files could do any damage to the system. On top of that, it's really annoying from the perspective of people who just want to get shit done.
>Usually it's got some modified permissions which allow it to run as another user (commonly root). They should be designed to be secure against an attack but nothing is bug-free. So you know what you do? You remove those permissions. Suddenly it's just a normal executable with the same capabilities as any other executable on the system (of which there are many even on a minimal system).
Or you don't even leave it on the system, which means that it can't exploit the hole. If you're aware of the hole, you don't put it on the system in the first place, and if you don't know about it, it's impossible for someone to use an exploit that doesn't exist.
That's rather simpler than leaving it on there, and hoping that permissions work. Nothing's bug free, so why take the chance?
First, there's no chance about it because you can't do anything with it once it's a normal executable. There's no "hoping" about it - remove special permissions and audit the whole FS and it can't be used for an attack (any more than any other binary on a minimal system could be). That being said, you do it to improve the efficiency of the system for the users and reduce time to troubleshoot issues.
If you've got physical access to the machine in the cage you can do anything you want, which includes bypassing BIOS and Bootloader passwords in about 5 minutes.
That assumes you have unlimited physical access. 5 minutes per machine * 80 in a rack * 1,000+ racks is a real world limitation.
PS: The NSA has a vary different approach to security than the average firm. To put this in perspective they have been known to refer to their computing power not by computer or rack but by the Acre.
True. But it would be unfeasible to access 16,000 machines even if there was no bootloader password. The best course of action is try to identify the management/admin server and take over that, which may have unrestricted access to every server on the VLAN (or as sometimes happens, every single server period).
(Also, what's your datacenter or machine profile that you can get 80 machines per rack and not hit overheading or overload your rack power circuits? We could only get 40 to be stable, but we were using commodity gear)
I highly doubt that these recommendations are intended for administering developer's workstations.
Also, a number of the recommendations you are railing against here are prefaced with "if possible" and "unless needed". For example, advice is provided on how to configure OpenSSH if it is deemed necessary to be run: "If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file"
The point of guides like this is to lock down everything that isn't necessary. As a part of this, it helps to question what services and actions each of your machines really needs. It's not unthinkable that some Linux servers deployed in a network do not need OpenSSH server running.
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.
>> 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.
You missed the point. More software means a larger attack surface. Minimizing software isn't meant to keep an attacker from installing software, it is meant to keep an attacker from using unmaintained/unneeded software to compromise the box in the first place.
> 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.
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.
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.