Scripting partioning on AWS
-
@IRJ said in Scripting partioning on AWS:
For anyone interested here are the CIS requirements.
https://secscan.acron.pl/ubuntu1604/1/1/2
https://secscan.acron.pl/ubuntu1604/1/1/6
https://secscan.acron.pl/ubuntu1604/1/1/7
https://secscan.acron.pl/ubuntu1604/1/1/12Note: we have Ubuntu 18.04 , but these requirements are the same.
Do I recall that you don't have a state management system like Salt or Ansible running correctly? That would be the easiest way to handle this.
If not, it should also be easy to script this in your favorite shell.
-
@travisdh1 said in Scripting partioning on AWS:
@IRJ said in Scripting partioning on AWS:
For anyone interested here are the CIS requirements.
https://secscan.acron.pl/ubuntu1604/1/1/2
https://secscan.acron.pl/ubuntu1604/1/1/6
https://secscan.acron.pl/ubuntu1604/1/1/7
https://secscan.acron.pl/ubuntu1604/1/1/12Note: we have Ubuntu 18.04 , but these requirements are the same.
Out of the 4 you linked to here, only adding nodev to /tmp even makes sense
Resizing filesystems is a common activity in cloud-hosted servers. Separate filesystem partitions may prevent successful resizing, or may require the installation of additional tools solely for the purpose of resizing operations. The use of these additional tools may introduce their own security considerations.
I know, DoD, can't question the system, yadda, yadda. Still doesn't mean I don't call out stupid when I see it.
I can see value to /var/log. You don't want runaway logs to fill up /. Separating /var and /var/log is much less useful. I can see /home too if it's an interactive system. If not then it's not that useful. Setting nosuid I think is valuable for /tmp also to help ensure something can't be elevated past normal privileges.
Do they also have you remove LVM and all the tooling for LVM?
We didn't have to for DISA STIGs, that's how we created the volumes.
-
@stacksofplates said in Scripting partioning on AWS:
@travisdh1 said in Scripting partioning on AWS:
@IRJ said in Scripting partioning on AWS:
For anyone interested here are the CIS requirements.
https://secscan.acron.pl/ubuntu1604/1/1/2
https://secscan.acron.pl/ubuntu1604/1/1/6
https://secscan.acron.pl/ubuntu1604/1/1/7
https://secscan.acron.pl/ubuntu1604/1/1/12Note: we have Ubuntu 18.04 , but these requirements are the same.
Out of the 4 you linked to here, only adding nodev to /tmp even makes sense
Resizing filesystems is a common activity in cloud-hosted servers. Separate filesystem partitions may prevent successful resizing, or may require the installation of additional tools solely for the purpose of resizing operations. The use of these additional tools may introduce their own security considerations.
I know, DoD, can't question the system, yadda, yadda. Still doesn't mean I don't call out stupid when I see it.
I can see value to /var/log. You don't want runaway logs to fill up /. Separating /var and /var/log is much less useful. I can see /home too if it's an interactive system. If not then it's not that useful. Setting nosuid I think is valuable for /tmp also to help insure something can't be elevated past normal privileges.
Do they also have you remove LVM and all the tooling for LVM?
We didn't have to for DISA STIGs, that's how we created the volumes.
Yes we are the same. It seems like we are following the same compliance
-
@IRJ said in Scripting partioning on AWS:
@stacksofplates said in Scripting partioning on AWS:
@travisdh1 said in Scripting partioning on AWS:
@IRJ said in Scripting partioning on AWS:
For anyone interested here are the CIS requirements.
https://secscan.acron.pl/ubuntu1604/1/1/2
https://secscan.acron.pl/ubuntu1604/1/1/6
https://secscan.acron.pl/ubuntu1604/1/1/7
https://secscan.acron.pl/ubuntu1604/1/1/12Note: we have Ubuntu 18.04 , but these requirements are the same.
Out of the 4 you linked to here, only adding nodev to /tmp even makes sense
Resizing filesystems is a common activity in cloud-hosted servers. Separate filesystem partitions may prevent successful resizing, or may require the installation of additional tools solely for the purpose of resizing operations. The use of these additional tools may introduce their own security considerations.
I know, DoD, can't question the system, yadda, yadda. Still doesn't mean I don't call out stupid when I see it.
I can see value to /var/log. You don't want runaway logs to fill up /. Separating /var and /var/log is much less useful. I can see /home too if it's an interactive system. If not then it's not that useful. Setting nosuid I think is valuable for /tmp also to help insure something can't be elevated past normal privileges.
Do they also have you remove LVM and all the tooling for LVM?
We didn't have to for DISA STIGs, that's how we created the volumes.
Yes we are the same. It seems like we are following the same compliance
Used to. Thankfully I'm out of that.
-
@stacksofplates do you happen to know what sizes were used for the partitions?
-
Found this chart on a somebody's project on github. Seems like a reasonable place to start?
-
@IRJ said in Scripting partioning on AWS:
@stacksofplates do you happen to know what sizes were used for the partitions?
How much disk usage is currently in use in those areas?
-
@IRJ said in Scripting partioning on AWS:
@stacksofplates do you happen to know what sizes were used for the partitions?
We didn't do it with a cloud provider. It was internal. I think we usually did 5GB for logs and /var depended on the applications.
-
@IRJ said in Scripting partioning on AWS:
Found this chart on a somebody's project on github. Seems like a reasonable place to start?
Ours would have been more like:
mount size / 12GB /home 1GB /var 10GB /var/log 5GB /var/log/audit 5GB /tmp 1GB -
@stacksofplates said in Scripting partioning on AWS:
@IRJ said in Scripting partioning on AWS:
Found this chart on a somebody's project on github. Seems like a reasonable place to start?
Ours would have been more like:
mount size / 12GB /home 1GB /var 10GB /var/log 5GB /var/log/audit 5GB /tmp 1GB That's a little too liberal for EC2 instances. I could definitely see that working for on prem though.
-
@IRJ said in Scripting partioning on AWS:
@stacksofplates said in Scripting partioning on AWS:
@IRJ said in Scripting partioning on AWS:
Found this chart on a somebody's project on github. Seems like a reasonable place to start?
Ours would have been more like:
mount size / 12GB /home 1GB /var 10GB /var/log 5GB /var/log/audit 5GB /tmp 1GB That's a little too liberal for EC2 instances. I could definitely see that working for on prem though.
Yeah. The numbers you had looked fine. Especially if they aren't going to be long living servers.
