Secure your Linux server - HowTo by the NSA

http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

by hyyypr • 15 years ago

396 97 15 years ago

nsa.gov

hvs• 15 years ago

Looks like they have guides for multiple operating systems:

http://www.nsa.gov/ia/guidance/security_configuration_guides...

zabuni• 15 years ago

There's also the DoD's Security Technical Implementation Guides:

http://iase.disa.mil/stigs/stig/index.html

mcritz• 15 years ago

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.

jonknee• 15 years ago

Not even just disable, they recommend physically removing it.

desigooner• 15 years ago

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

oasisbob2• 15 years ago

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

vegasbrianc• 15 years ago

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

chopsueyar• 15 years ago

I think we're only covering interest.

andymoe• 15 years ago

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

cmurdock• 15 years ago

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.

tintin2• 15 years ago

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

nodata3• 15 years ago

You should use a bios password to stop bios settings being changed. I doubt they mean at boot.

derobert• 15 years ago

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

Legion2• 15 years ago

KVM over IP. Type your BIOS password right in.

tintin2• 15 years ago

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

peterwwillis6• 15 years ago

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.

brown9-2• 15 years ago

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 conﬁguration ﬁle"

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.

nodata3• 15 years ago

To reply to your points:

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

peterwwillis6• 15 years ago

> The NSA have different priorities to you.

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.

static_cast2• 15 years ago

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• 15 years ago

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

peterwwillis6• 15 years ago

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

nuclearsandwich• 15 years ago

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• 15 years ago

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

lorlandar• 15 years ago

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.

squamigera• 15 years ago

Anyone find an attempt to install any backdoor? :D

vanni• 15 years ago

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

gnaritas• 15 years 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.

16s2• 15 years ago

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.

phlux• 15 years ago

There is another reason to do this as well, when at Lockheed - we changed all SSH ports as we were scanned literally continuously in real-time from chinese IP blocks.

IgorPartola2• 15 years ago

For a long while I ran a tricky firewall chain that would allow you to connect to port 22 only 3 times before it would lock out your IP for 30 minutes. My ssh port was at something like 2022 so I (almost) never got caught in this, but an unsuspecting scan bot would get stuck on it (http://en.wikipedia.org/wiki/Tarpit_(networking)#The_origina...).

Xurinos• 15 years ago

This is true, but it has advantages. For example, system log files are much smaller. :) When I adopted this policy on my own systems, it was to help me change my worry profile from "noise from every random bot on the net" to "targeted attack".

jacques_chester2• 15 years ago

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

It's also a mild performance hack. Bouncing a connection to a closed port is faster than waking up the SSH daemon to bounce the same connection. Port 22 gets a lot of traffic.

thirsteh• 15 years ago

For ports, maybe--because there's a limited range of possibilities--but by that logic, all DNS servers should allow zone transfers.

16s2• 15 years ago

40 character passwords, along with host-based firewalls that /dev/null you after 10 failed attempts are just as effective as keys. In case you are wondering, the passwords are pasted, not typed.

ghshephard2• 15 years ago

...Until someone hacks your system and manages to grab the password. The nice thing about keys is you don't have to reveal your secret, just prove you have it.

malkia• 15 years ago

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

conradev• 15 years ago

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

thibaut_barrere2• 15 years ago

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

zwp• 15 years ago

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_barrere2• 15 years ago

Thank you for the link and your insight, too.

recampbell• 15 years ago

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

IgorPartola2• 15 years ago

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.

qpleple3• 15 years ago

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• 15 years ago

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.

kinofcain2• 15 years ago

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

http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731....

gks• 15 years ago

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.

khafra2• 15 years ago

The 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

[1] http://en.wikipedia.org/wiki/Common_Criteria

JshWright2• 15 years ago

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.

peterbotond• 15 years ago

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

sliverstorm2• 15 years ago

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• 15 years ago

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.

michael_h• 15 years ago

There is one for freebsd here: http://benchmarks.cisecurity.org/en-us/?route=downloads.mult...

eck• 15 years ago

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.

qpleple3• 15 years ago

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

olalonde• 15 years ago

Could anyone quickly explain how partitioning helps with security?

dasrecht• 15 years ago

locking 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• 15 years ago

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

udoprog3• 15 years ago

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

Periodic2• 15 years ago

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.

Periodic2• 15 years ago

I really hope we can get to a new generation of filesystems soon. Something closer to what ZFS is now. It frustrates me that I have an 80GB disk and I have to allocate portions of it to each of these tasks and try to correctly estimate in advance what each one will use. Eventually it will turn out I mis-estimated and it will be a pain to juggle already-filled partitions.

With a system like ZFS, you create logical filesystems essentially at a folder level. So you can say that /tmp is noexec and has a quota of 20GB but a reserved space of 2 GB. You can also make sure that your root drive has at least 10GB reserved, so even if /var fills up, you still have at least 10GB for your root space.

And this is without heavyweight partitioning, things are easily modifiable on the fly, and you still get constant-time snapshots.

Fortunately, logical volume managers exist and do help.

tzury• 15 years ago

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

http://www.securenetwork.it/ricerca/whitepaper/download/Debi...

dcposch• 15 years ago

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• 15 years ago

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.

Secure your Linux server - HowTo by the NSA

Related Stories