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

[twstdroot]

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

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