10 ms·
Secure your Linux server - HowTo by the NSA
- hvs 15y agoLooks like they have guides for multiple operating systems: http://www.nsa.gov/ia/guidance/security_configuration_guides/operating_systems.shtml http://www.nsa.gov/ia/guidance/security_configuration_guides...
- zabuni 15y agoThere's also the DoD's Security Technical Implementation Guides: http://iase.disa.mil/stigs/stig/index.html http://iase.disa.mil/stigs/stig/index.html
- mcritz 15y agoI 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.
- jonknee 15y agoNot even just disable, they recommend physically removing it.
- rdtsc 15y agoDoD had a removable device scare a while back (someone intruduced a windows virus into an internal network via one), and for a while there they were going around and filling external USB ports with epoxy. Eventually they "relaxed" their position on that.
- desigooner 15y agoI have duct tape on my Macbook Pro's webcam ever for the last 3 years or so ..
- code_duck 15y agoWhy 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?
- webXL 15y agoand now there's one on our phones!!!
- blasdel 15y agoThere 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 15y agoI 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.
- runjake 15y agoIf people want something that won't discolor the plastic or leave residue, use the sticky portion of a yellow sticky note to cover the camera. I've been using the same piece of little sticky for 2 years or so. On Macs it has the added bonus of still letting you see when the camera light comes on.
- deleted 15y ago
- oasisbob 15y agoThey also have a very useful guide focused on network infrastructure hardening. It's intended for Cisco IOS switches, but many of the principles can be adopted to other platforms: http://www.nsa.gov/ia/_files/switches/switch-guide-version1_01.pdf http://www.nsa.gov/ia/_files/switches/switch-guide-version1_...
- deleted 15y ago[deleted]
- deleted 15y ago[deleted]
- vegasbrianc 15y agoQuite a detailed document. Glad to see the US taxes paying for something decent for once.
- chopsueyar 15y agoI think we're only covering interest.
- andymoe 15y agoThese have been around for years and years. I remember reading one for windows 2000 and NT.
- cmurdock 15y agoI took a security class in college that and we used some of these documents to secure some systems. They're a pretty helpful reference.
- tintin 15y ago"Use a bios password" ... and don't reboot your server when running in a remote server room?
- nodata 15y agoYou should use a bios password to stop bios settings being changed. I doubt they mean at boot.
- derobert 15y agoSecurity recommendations must be understood and modified (even ignored) as the environment requires. If you're in an environment where security is very important, then having to send someone on-site to reboot a server may be reasonable. Or maybe your data center is staffed. Or maybe you have an IP-KVM, so you can access the console remotely. Alternatively, most BIOSes I've seen have both a supervisor and user password, or similar: one disallows access to the BIOS setup, the other restricts booting. You could set only the one that disallows setup access.
- Legion 15y agoKVM over IP. Type your BIOS password right in.
- tintin 15y agoThanks! I did not know about this. But doesn't this create extra security issues?
- Legion 15y agoYes, 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.
- peterwwillis 15y agoI'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.
- nuclearsandwich 15y agotl;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 15y agoPart 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_Encryption_Standard_.28DES.29 http://en.wikipedia.org/wiki/National_Security_Agency#Data_E...
- lorlandar 15y agoA 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 15y agoExcept 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.
- squamigera 15y agoAnyone find an attempt to install any backdoor? :D
- pgroves 15y agoIn 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 15y agoIn the page hvs linked to above there's a cheat sheet version: http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731....
- vanni 15y agoThey could have done better for OpenSSH securing: they forgot forcing key-based authentication only and changing default port number.
- gnaritas 15y ago> 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 15y agoIf 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.
- kinofcain 15y agoWe need some sort of Big-O notation for security. It seems like the argument against security through obscurity is similar to the argument that T(n) = 10,000n^2 is equivalent to T(n) = 10n^2, as both are O(n^2) even though they have vastly different coefficients. At the end of the day, they have the same Big-O notation, but one of them is a thousand times better than the other. Sometimes the coefficients matter. Obscurity in security is like the 'lost' coefficient in Big-O notation: it's not the first thing you should focus on, but it can really help.
- oasisbob 15y agoObscurity 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 15y ago
- malkia 15y agoIf Only Sony.... ah... too late for that!
- conradev 15y ago3.21 - Install the NSA Security Suite to ensure your computer's safety
- thibaut_barrere 15y agoIs there a tool I could run to check what's described in the document (or similar) automatically ?
- zwp 15y agoNessus is probably (still) the best for Linux in this field (certainly in the "free for home use" category): http://www.tenable.com/products/nessus 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 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 15y agoThank you for the link and your insight, too.
- recampbell 15y agoIs there an OSS package for automating checks for such practices? Ie, security lint checker?
- IgorPartola 15y agoYes. Have a look at Tiger: http://savannah.nongnu.org/projects/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 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 15y agoTiger 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."
- gks 15y agoDoes 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.
- khafra 15y agoThe NSA's STIGs are a useful resource. If you want the higher-level policies they come from, NIST[0] is one candidate. If you want documents around the same level of specificity as the STIGs, you'll probably need a non-governmental source. Arch Linux and Nginx are not EAL certified[1] at any level, so the US Government isn't even going to try to secure them. [0] http://csrc.nist.gov/publications/PubsITLSB.html http://csrc.nist.gov/publications/PubsITLSB.html [1] http://en.wikipedia.org/wiki/Common_Criteria http://en.wikipedia.org/wiki/Common_Criteria
- JshWright 15y agoPacman 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.
- deleted 15y ago[deleted]
- peterbotond 15y agoInteresting, FreeBSD/PcBSD is not on the list. is it due to lesser popularity?
- sliverstorm 15y agoThere 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 15y agoBSDs 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.
- michael_h 15y agoThere is one for freebsd here: http://benchmarks.cisecurity.org/en-us/?route=downloads.multiform http://benchmarks.cisecurity.org/en-us/?route=downloads.mult...
- eck 15y agoSection 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 15y agoAnd conclusion : turn off the network as well. You never know.
- olalonde 15y agoCould anyone quickly explain how partitioning helps with security?
- dasrecht 15y agolocking your filesystems helps you sometimes take /var/log as example. if someone floods your server with traffic and you log every tiny bit (or even worse you have the debug level set to on) the logs will quickly take lots of space. if the space is full no further write access is possible if it's a seperate partition you can't write more logs... if it's on the same partition you won't be able to log in by ssh as example because your drive is full and you can't spawn the sshd agent ;)
- skeletonjelly 15y agoThis one is worth doing. I've been asked to fix a Trixbox that was blocking calls because they were logging every phone call and it filled up the harddrive. Easy solution to a possibly annoying problem.
- udoprog 15y agoAlso, 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 15y agoA 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.
- tzury 15y agoThis is a bit out of date (2009) yet contain many Security goodies for Ubuntu [pdf] http://www.securenetwork.it/ricerca/whitepaper/download/Debian-Ubuntu_hardening_guide.pdf http://www.securenetwork.it/ricerca/whitepaper/download/Debi...
- dcposch 15y agoNo. 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 15y agoWhere 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/ http://www.securenetwork.it/ricerca/whitepaper/ links to the same.