linux服务器安全_足够安全的linux服务器，快速的安全性调整

最新推荐文章于 2024-09-18 12:27:20 发布

cullen2012

最新推荐文章于 2024-09-18 12:27:20 发布

阅读量375

点赞数

文章标签： linux java ssh 大数据数据库

原文链接：https://habr.com/en/post/499494/

版权

linux服务器安全

案例：您在云平台提供商(Amazon，DO，Google，Azure等)上启动了专业准备的Linux映像，它将运行某种生产级别的服务，适度受到黑客攻击(非针对性，非针对性)高级威胁)。 (The case: You fire up a professionally prepared Linux image at a cloud platform provider (Amazon, DO, Google, Azure, etc.) and it will run a kind of production level service moderately exposed to hacking attacks (non-targeted, non-advanced threats).)

What would be the standard quick security related tuning to configure before you install the meat?

在安装肉类之前要配置的与快速安全性相关的标准调整是什么？

release: 2005, Ubuntu + CentOS (supposed to work with Amazon Linux, Fedora, Debian, RHEL as well)

发行时间：2005年，Ubuntu + CentOS(应该与Amazon Linux，Fedora，Debian，RHEL一起使用)

免责声明： (Disclaimers:)

Read the micro threat model given in "The case" paragraph above before you compare my advise with your requirements. Otherwise please help me improve this page with your comments!
在将我的建议与您的要求进行比较之前，请阅读上面“案例”一节中给出的微型威胁模型。否则，请通过您的评论帮助我改进此页面！
It's not at all a guide for Docker containers or for a seriously hardened production server.
它根本不是Docker容器或经过严格加固的生产服务器的指南。
The author is not a certified unix admin or a devsecops guru.
作者不是认证的Unix管理员或devsecops专家。
It's a subjective advise!
这是一个主观建议！

假设条件 (Assumptions)

You are already experienced in Linux administration.
您已经具有Linux管理方面的经验。
As an admin you work on a trusted machine (desktop, laptop or tablet), properly hardened, continuously patched, with security not weared off by years of usage or being shared.
作为管理员，您需要在可靠的机器(台式机，笔记本电脑或平板电脑)上工作，这些机器经过适当加固，连续打补丁，并且安全性不会因多年使用或共享而受损。
There is a handy facility to generate and store passwords available on the above admin client.
在上面的管理客户端上有一个方便的工具可以生成和存储密码。
Your SSH keys or other credentials to admin the instance are handled securely on your admin machine. (An issue in itself how to satisfy this requirement. Like should your keys be enclosed in password or token protected key stores or drives?!)
您用于管理实例的SSH密钥或其他凭据已在管理计算机上安全处理。 (如何满足此要求本身就是一个问题。就像您的密钥应该放在受密码或令牌保护的密钥存储区或驱动器中一样！！)
Your access to the cloud platform provider is secure enough, and your user/account there is handled with security in mind.
您对云平台提供商的访问足够安全，并且在处理您的用户/帐户时要牢记安全性。
You manage the cloud platform provider's web UI in a browser which you use solely for admin tasks.
您可以在仅用于管理任务的浏览器中管理云平台提供商的Web UI。
To sum the above: The security context of your installation (instance cooking) work is on a higher level of assurance than the level you would expect from the instance you configure.
总结一下：安装(实例烹饪)工作的安全性上下文比您从配置的实例期望的安全性更高。
You use a Linux image provided by a party whose security competence is assumed (like the image baked by the cloud platform provider themselves or the Linux distro builder).
您使用假设安全性的一方提供的Linux映像(例如，云平台提供商本身或Linux发行版构建器发出的映像)。
You login to the instance via a trusted and clean terminal app or within admin browser via the native web-CLI.
您可以通过受信任且干净的终端应用程序登录实例，也可以通过本地Web-CLI在管理浏览器中登录实例。

The best approach is to adhere to cyber hygiene practices from the zero moment and not rely on an idea that security can be hardened in a bonus step afterwards.

最好的方法是从零时刻开始遵守网络卫生习惯，而不要依赖于以后可以通过额外的步骤来加强安全性的想法。

Our advice would be to use — a corporate managed — iPad as a trusted admin client at a remote location or a managed desktop at the enterprise internal network. In case you/the company are/is subject for targeted attacks then laptops are a weaker choice for paranoids. But that's an other story to which I will dedicate an article or a post later.

我们的建议是使用公司托管的iPad作为远程位置的受信任管理客户端，或者将其用作企业内部网络的托管桌面。如果您/公司受到定向攻击，则笔记本电脑是偏执狂的较弱选择。但这是另一个故事，稍后我将专门针对该故事或帖子进行讨论。

步骤 (The steps)

启用匹配的防火墙保护 (Have a matching firewall protection enabled)

I mean which serves as the internet facing firewall behind which your instance is running. Amazon calls it the security group, in DO that's the firewalls feature of a project. This filters ports internet connections can hit on your instance. Plan which external firewall preset will match the open ports of the instance you are installing. SSH + the ports of services. The external firewall may allow more ports as the preset may serve several types of instances. The good old approach to minimize the open ports is still valid.

我的意思是，它充当面向互联网的防火墙，您的实例正在其后面运行。 Amazon在DO中将其称为安全组，即项目的防火墙功能。此筛选器端口Internet连接可能会命中您的实例。计划哪个外部防火墙预设将与您正在安装的实例的打开端口匹配。 SSH +服务端口。外部防火墙可以允许更多端口，因为预设可以服务几种类型的实例。最小化开放端口的旧方法仍然有效。

You may have different firewall presets ready for different stages of your installations. Like in the beginning port 22 is the one you start off, but when a non standard SSH port is configured you may switch to a preset with 22 closed forever and the corresponding internet noise will not hit your instance.

您可能已为安装的不同阶段准备了不同的防火墙预设。就像在开始时一样，端口22是您要启动的端口，但是当配置了非标准SSH端口时，您可能会切换到永久关闭的22预设，并且相应的Internet噪声不会对您的实例造成影响。

选择初始的连接/登录方法 (Choosing the initial connect/login method)

In case you have your working practice to connect to the cloud platform resources, connect as you deem it safe. Otherwise:
如果您有工作习惯来连接到云平台资源，请在认为安全的情况下进行连接。除此以外：
If the cloud platform allows I would choose the option with connecting to ssh with a random root password generated by the platform (DO offers this). See the explanation of my pro-passwords (long random passwords) point of view in a below section ('Password authentication is wrong, key files rule! (Disagreed️)').
如果云平台允许，我将选择使用该平台生成的随机根密码连接到ssh的选项(DO提供此选项)。请参阅以下部分(“密码验证错误，密钥文件规则！(Disagreed️)”)对我的亲密码(长随机密码)观点的解释。

不要让新鲜的实例像野外一样运行 (Don't let a fresh instance run as is in the wild)

Be paranoid, don't let a fresh instance to run unpatched while exposed to internets. When fired up log in within minutes to start patching.

偏执，不要让新实例在暴露于Internet的情况下不打补丁运行。启动后，请在几分钟内登录以开始修补。

… and

…和

sudo -s

root. root用户身份发出。

确保裸机系统是最新的 (Make sure the bare system is up-to-date)

# Ubuntu
apt update
apt ugrade
# CentOS
dnf update
dnf upgrade
# + both optionally:
shutdown -r now

Restarting is technically not necessary, but it won't harm.

从技术上来说，重新启动不是必需的，但不会造成危害。

基本步骤 (Basic steps)

Enable the local firewall and allow some ports. (It's indeed useless to enable the firewall if you already enabled a frontfacing firewall on the provider's host, but still.)
启用本地防火墙并允许一些端口。 (如果您已经在提供者的主机上启用了前端防火墙，则启用防火墙确实没用，但是仍然如此。)
Set the timezone.
设置时区。

Ubuntu:

Ubuntu：

ufw enable
ufw allow 22, <*your custom ssh, eg 52112*>
# see the SSHd setup below
ufw status
# make your time meaningful, change the location:
timedatectl set-timezone Europe/Berlin

CentOS:

CentOS的：

# may firewalld not present:
dnf install firewalld
systemctl enable firewalld --now
# then
firewall-cmd --state
# should be '*running*'
firewall-cmd --list-all
# should be telling something like:
# *public (active)*
# *services: cockpit dhcpv6-client ssh*
firewall-cmd --list-all-zones | more
firewall-cmd --get-default-zone
# public
# add a custom ssh port, see the SSHd setup below
firewall-cmd --permanent --zone=public --add-port=<*your custom ssh, eg 52112*>/tcp
# success
firewall-cmd --complete-reload
firewall-cmd --list-all
# now should also contain your custom ssh port

# make your time meaningful, change the location:
timedatectl set-timezone Europe/Berlin

SELinux，AppArmor (SELinux, AppArmor)

Check the AppArmor or SELinux status:

检查AppArmor或SELinux状态：

# Ubuntu:
apparmor_status
# CentOS:
sestatus

It's not that you should bother with it, but it's still more secure to utilize an Linux distro preconfigured with LSM in enforcing mode active, so try to make it an aspect when you choose your provider and select from the factory maintained images there. However based on other's opinions and considering the "micro threat model" set out above I would not make it a prerequisite. In order for LSM to make real sense it should be tuned adequately to your services and the particular situation.

并不是您应该为此而烦恼，但是在强制模式下使用预先配置有LSM的Linux发行版仍然更加安全，因此在选择提供程序并从那里的工厂维护的映像中进行选择时，请尝试使其成为一个方面。但是，基于其他人的观点并考虑上述“微观威胁模型”，我不会将其作为前提条件。为了使LSM真正有意义，应根据您的服务和特定情况进行适当调整。

舒适至上 (Comfort first)

Make yourself comfortable and productive, like:

使自己舒适高效，例如：

zsh, fish or a similar advanced shell will help you a lot (tuning it is not discussed here).
zsh， fish或类似的高级shell会对您有很大帮助(调整这里不再讨论)。
wget is used in this guide.
本指南中使用了wget。
Don't hesitate to install the editor of choice as early as possible (I promote micro here, tho it's a bit more complicated to install).
不要犹豫，尽早安装所选的编辑器(我在这里介绍了micro，因为安装起来有点复杂)。

apt/dnf install zsh wget
which zsh
echo $0
# Ubuntu
snap install micro --classic

Yes I start with suppressing a security alert. Let's be realistic. Let's face it all systems are non-secure, even bash had horrible security flaws, everything has, maybe except ssh written by paranoid and methodic freaks.))

是的，我首先禁止显示安全警报。让我们现实一点。让我们面对所有系统都是不安全的，甚至bash都有可怕的安全漏洞，一切都有，也许除了偏执狂和有条理的怪胎写的ssh之外。))

Alternatively install micro from:

或者从以下位置安装micro：

https://github.com/zyedidia/micro/releases/

See my suggestions in the below 'Then services, folders, extensions' section.
请在下面的“然后服务，文件夹，扩展名”部分中查看我的建议。

mkdir -p /tank/packagez
chown -R root:wheel /tank/packagez
mkdir /opt/bin

cd /tank/packagez
wget https://github.com/zyedidia/micro/releases/download/v2<...>/micro-2<...>-linux64.tar.gz
tar xf micro...
mv micro.../micro /opt/bin/

chown -R root:root /opt/bin
chmod -R 755 /opt/bin
export PATH="$PATH:/opt/bin"
micro /etc/profile.d/env.sh
# create or add
export PATH="$PATH:/opt/bin"
# * or to the PATH in /etc/environment if that one is in use by the os

密码质量 (Password quality)

Mod the password quality settings:

修改密码质量设置：

# on Ubuntu you may need to install this first
apt install libpam-pwquality
# then
micro /etc/security/pwquality.conf
# enable:
minlen = 20
ocredit = -2

This will set the minimum password length to 20 and require 2 special characters in it. Why 20? Ok, let it be 25. See also my bellow comment regarding passwords vs key files. (I suggest using random passwords and SSH password authentication instead of key files, hence the length. See the explanation of my pov in the below 'Password authentication is wrong, key files rule! (Disagreed️)' section.

这会将密码的最小长度设置为20，并需要2个特殊字符。为什么是20？好的，设为25。另请参阅以下有关密码与密钥文件的波纹管评论。 (我建议使用随机密码和SSH密码身份验证，而不是密钥文件，因此使用长度。请参见下面“密码身份验证错误，密钥文件规则！(Disagreed️)”部分对我pov的解释。

您的个人用户 (Your personal user)

For sshing your persistent instance imo a good practice would look like follows:

对于ssh持久实例imo，一个好的做法如下所示：

ssh -p 52112 lola@acme.web

custom user, custom port
自定义用户，自定义端口

Create an admin user:

创建一个管理员用户：

# Ubuntu
useradd --uid <*1111*> -N --home /home/.<*lola*> --shell /usr/bin/zsh -g admin -G users <*lola*>
# CentOS
useradd --uid <*1111*> -N --home /home/.<*lola*> --shell /bin/zsh -g wheel -G users <*lola*>

mind to rewrite 'lola' to your nick
介意将“萝拉”改写为你的昵称
UID does not matter actually
UID实际上并不重要
zsh may not be your choice
zsh可能不是您的选择
mind that home directory is hidden in the above example (yes I think obscurity adds to security a bit))
请注意，上面的示例隐藏了主目录(是的，我认为晦涩难懂会增加安全性)

Create your password as a random token. Eg.:

创建您的密码作为随机令牌。例如。：

< /dev/urandom tr -cd '[:alpha:][:digit:]_!$%' | head -c30 ; echo ""
# OR create it on the client device and copy or retype
passwd <*lola*>

Tweaking the choice of special characters try to use the ones which are available for manual entering on different devices.

调整特殊字符的选择，尝试使用可在不同设备上手动输入的字符。

SSHd模组 (SSHd mods)

Consider this: a) SSHd config is already properly set, b) there are many settings in there which makes sense to harden. So you can choose from leaving it as is to diving into tuning it to death (given you read a lot about the meaning and the effects).

考虑一下：a)SSHd配置已经正确设置，b)那里有很多设置值得强化。因此，您可以从保留原样到跳入死亡调整中进行选择(假设您已经阅读了很多有关其含义和作用的信息)。

Consider the following quick mods:

考虑以下快速修改：

custom port (52112 is an example)
自定义端口(52112是示例)
disallowing root and any unexpected account to login
禁止root和任何意外帐户登录

Note: A stupid mistake in sshd config may lock out your access forever. (Except that you may login via the providers console.) So:

注意：sshd配置中的一个愚蠢错误可能会永远锁定您的访问权限。 (除了您可以通过提供者控制台登录。)因此：

Open two SSH connections to the remote instance, one with the original default user and one with your new custom user. SSHd will not lock out a live connection in most situations even if reloaded with a broken configuration (failed restart will not kick your live sessions in most cases).

打开两个到远程实例的SSH连接 ，一个使用原始默认用户，另一个使用您的新自定义用户。在大多数情况下，即使重新加载了损坏的配置，SSHd也不会锁定实时连接(失败的重新启动在大多数情况下不会启动实时会话)。

Modify the below setting in the sshd config. The settings in < > are to be fixed by you.

在sshd配置中修改以下设置。 < >中的设置由您确定。

micro /etc/ssh/sshd_config
# mods:
Port <*52112*>
AllowUsers <*lola*>
DenyUsers root guest test admin toor *ec2-user bitnami <...default accounts>*
DenyGroups
AllowGroups

Mind to use the same extra port which you accepted with the local and external firewalls.
注意使用与本地和外部防火墙相同的额外端口。

For better cipher, mac and key exchange settings add the following to the end of the config:

为了获得更好的密码，mac和密钥交换设置将以下内容添加到配置末尾：

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

You may also mod the below settings in the sshd_config (keep all the other original settings as they are!), walk thru it, edit (uncomment and edit) the mentioned below lines. (It's not the new content of the config, these are the lines in the original which I suggest to modify accordingly).

您还可以在sshd_config中修改以下设置( 保持所有其他原始设置不变！) ，遍历它，编辑(取消注释和编辑)下面提到的几行。 (这不是配置的新内容，这些是我建议相应修改的原始行)。

LoginGraceTime 45
PermitRootLogin no
MaxAuthTries 6
MaxSessions 3
ClientAliveInterval 60
ClientAliveCountMax 2
ChallengeResponseAuthentication no
GSSAPIAuthentication no
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitUserEnvironment no

If there are duplicate settings, SSH will take the last one, so check the whole config file. (Technically if you add the above to the end of the config file that will override the previous settings.)

如果有重复的设置，SSH将采用最后一个设置，因此请检查整个配置文件。 (从技术上讲，如果将以上内容添加到将覆盖先前设置的配置文件的末尾。)

You may also disallow (with a leading hash) the SFTP subsystem unless you know scp is something you really need and can't solve it otherwise. (Consider that scp allows for dumping any amount of data from your system.)

除非您知道scp是您真正需要的东西，否则您可能也不允许SFTP子系统(带前导哈希)。 (考虑到scp允许从系统中转储任何数量的数据。)

#Subsystem sftp /usr/lib/openssh/sftp-server

Restart the service, check the status and review the effective settings:

重新启动服务，检查状态并查看有效设置：

systemctl restart sshd.service
systemctl status sshd.service
# check the listening port
sshd -T
# in case of errors:
# - Ubuntu:
tail -30 /var/log/syslog
# - CentOS:
tail -30 /var/log/messages
# - both:
journalctl -xe

Keeping the live SSH connections/terminals alive, open a new terminal and check if connecting with your custom admin user works:

使实时SSH连接/终端保持活动状态，打开一个新终端，并检查与自定义admin用户的连接是否有效：

ssh -p <52112> <lola>@<IP>

Restart your instance and ssh into it with your user.

重新启动实例并与您的用户一起SSH。

密码验证错误，密钥文件规则！ (不同意️️) (Password authentication is wrong, key files rule! (Disagreed️️))

You may wonder why don't I recommend to immediately forbid PasswordAuthentication and allow PubkeyAuthentication only?!

您可能想知道为什么我不建议立即禁止PasswordAuthentication并仅允许PubkeyAuthentication ？！

You may prove the opposite, but I see no practical cryptographic strength difference between a large random password and a key. Beyond a certain level of entropy we care to put into our password. A random password and a key are both just a bunch of random bytes.

您可能证明了相反的情况，但是我发现大型随机密码和密钥之间在实用的密码强度上没有区别。除了一定程度的熵外，我们还希望输入密码。随机密码和密钥都只是一堆随机字节。

From the practical point of view then we have a significant difference in handling the two kinds of secrets. A 20-30 char password you can even type in while looking at it stored in your password store well protected on an iOS device. With the keys there is always a drama of moving those around and protecting the key file. Unless you have an enterprise grade key store. So it's up to you. Obviously you can if you prefer so:

从实践的角度来看，我们在处理这两种机密方面有很大的不同。您甚至可以在查看密码的同时输入20到30个字符的密码，该密码存储在iOS设备上受到良好保护的密码存储中。有了密钥，总会有戏剧性地移动密钥并保护密钥文件。除非您有企业级密钥库。因此，取决于您。显然，如果愿意，您可以：

PasswordAuthentication no

May you want and have an MFA capability to use a token like Yubikey — that would be the winning solution to heighten the level of assurance.

希望您拥有MFA功能，并具有使用Yubikey这样的代币的能力-这将是提高保证水平的成功解决方案。

杀死root用户 (Kill the root user)

When you are done with the ssh configuration, and your custom user safely logs in to the instance, it's time to kill the root. Not that it's absolutely a good idea, but you never know how it was misconfigured. :) 'Killing' is done by assigning a random password.

完成ssh配置后，您的自定义用户可以安全地登录到实例，是时候杀死根了。并不是说这绝对是个好主意，但是您永远都不知道它是如何配置错误的。 :)杀死是通过分配随机密码来完成的。

Check interactive password holders (Ubuntu only):

检查交互式密码持有人(仅Ubuntu)：

passwd -Sa | grep P

Change the root password to a random one (Ubuntu, CentOS):

将根密码更改为随机密码(Ubuntu，CentOS)：

echo -n "root:$( < /dev/urandom tr -cd '[:lower:][:digit:]_!$%,.[=*=][=#=]' | head -c40 )" | chpasswd

Note that root can assign any password (despite the fine policy we created above), so be careful with issuing the command without tuning, or test what it does.

请注意，root用户可以分配任何密码(尽管我们在上面创建了很好的策略)，因此在发出命令时请小心，不要进行调整或测试其作用。

If there were other interactive users assign random passwords to them unless you understand the reason for their interactive presence at your instance.

如果还有其他交互式用户，则为他们分配随机密码，除非您了解实例中其交互式存在的原因。

然后是服务，文件夹，扩展 (Then services, folders, extensions)

Now you are done with installing the base system — bada-bing-bada-boom.

现在您已完成基本系统的安装-bada-bing-bada-boom。

Pproceed to installing your services. That may involve adding new available ports to the firewall and new users. But first make the standard folder structure.

进行安装您的服务。这可能涉及向防火墙和新用户添加新的可用端口。但是首先要建立标准的文件夹结构。

/坦克 (/tank)

My subjective practice is to create a /tank folder for storing custom stuff including the installation material:

我的主观做法是创建一个/tank文件夹，用于存储包括安装材料在内的自定义内容：

mkdir -p /tank/packagez
chown -R root:admin /tank/packagez
# * under CentOS admin is wheel
cd /tank/packagez

So the 'packagez' (or anything like that, 'install', you name it) will be the location to download the installation sources which you can return to and check later what was the source of the running softwares. Like:

因此，“ packagez”(或类似的名称，“ install”，即您自己的名字)将成为下载安装源的位置，您可以将安装源返回并稍后查看正在运行的软件的源。喜欢：

wget [https://github.com/caddyserver/caddy/releases/download/v2.0.0-rc.1/caddy_2.0.0-rc.1_Linux_x86_64.tar.gz](https://github.com/caddyserver/caddy/releases/download/v2.0.0-rc.1/caddy_2.0.0-rc.1_Linux_x86_64.tar.gz)

/选择 (/opt)

I would suggest to install your tools and service binaries to the /opt folder. This ensures that you can keep track of what additional software you deployed on the instance.

我建议将您的工具和服务二进制文件安装到/ opt文件夹中。这样可以确保您可以跟踪实例上部署了哪些其他软件。

Using caddy as an example:

以球童为例：

cd /tank/packagez
tar xf caddy -C /opt/caddy
chown -R root:root /opt/caddy
chmod -R 755 /opt/caddy
/opt/caddy/caddy —help

caddy reverse-proxy --from acme.web --to localhost:9000 caddy reverse-proxy --from acme.web --to localhost:9000

构型 (Configurations)

As for the location of configuration stuff I would suggest to follow the standard guides. Like mostly that suggests /etc/:

至于配置资料的位置，我建议遵循标准指南。像大多数建议/ etc /一样：

mkdir /etc/caddy
touch /etc/caddy/Caddyfile
chown -R root:caddy /etc/caddy
mkdir /etc/ssl/caddy
chown -R root:caddy /etc/ssl/caddy
chmod 0770 /etc/ssl/caddy

创建服务的用户 (Create a user for the service)

For the service users a good idea would be to not assign a working shell to them, like:

对于服务用户，一个好主意是不要为他们分配工作的shell，例如：

groupadd --system caddy
useradd --system --gid caddy --create-home --home-dir /var/lib/caddy --shell /bin/false --comment "Caddy web server" caddy

Mind to assign a fake shell to it. Alternatively: --shell /usr/sbin/nologin
注意为它分配一个假壳。或者：-- --shell /usr/sbin/nologin

系统的 (systemd)

Mostly your services will require automatic start. For that you presumably use systemd. Like:

通常，您的服务需要自动启动。为此，您大概使用systemd。喜欢：

wget https://raw.githubusercontent.com/caddyserver/dist/master/init/caddy.service -P /etc/systemd/system
chmod 644 /etc/systemd/system/caddy.service
micro /etc/systemd/system/caddy.service
# General approach
User=caddy
Group=caddy
...
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
ProtectSystem=full

# Then:
systemctl daemon-reload
systemctl status caddy
journalctl -u caddy -b -f
tail -40 /var/log/caddy.log
# when works
systemctl enable caddy