6 ms·

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 pos

by nodata 15y 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.

peterwwillis 15y 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.
- nodata 15y ago
  Yes, sure you could worry about all of those things too, and in some cases you should. It depends what/who you're guarding against. Your attacker could hire a private army and drive tanks into the datacentre and steal your data. But that's unlikely to happen. Security is about layers, and I think as a security agency, the NSA did a pretty good job. Choose how many layers you want, and which are appropriate.
- simpleTruth 15y ago
  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.
  - peterwwillis 15y ago
    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)
- cube13 15y ago
  >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.

by nodata 15y ago

peterwwillis 15y 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.

nodata 15y ago
Yes, sure you could worry about all of those things too, and in some cases you should. It depends what/who you're guarding against. Your attacker could hire a private army and drive tanks into the datacentre and steal your data. But that's unlikely to happen. Security is about layers, and I think as a security agency, the NSA did a pretty good job. Choose how many layers you want, and which are appropriate.
simpleTruth 15y ago
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.
- peterwwillis 15y ago
  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)
cube13 15y ago
>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.