I'll just skip to the juicy bits:<p>1.1.2 Minimize Software to Minimize Vulnerability<p>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.<p>2.1.1.1 Disk Partitioning<p>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 <i>IMPLEMENT DISK SPACE MONITORING</i> 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.<p>2.1.1.2 Boot Loader Configuration<p>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!<p>2.2.1 Restrict Partition Mount Options<p>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.<p>2.3.5 Protect Physical Console Access<p>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).<p>2.5.3.1 Disable Support for IPv6 unless Needed<p>Too lazy to use ip6tables, huh? Yeah you're right, we'll never need IPv6.<p>2.5.4.1 How TCP Wrapper Protects Services<p>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.<p>3.5.1 Disable OpenSSH Server if Possible<p>....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?<p>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.