document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Translated

Browse Source
This commit is contained in:
GOLinux 2017-01-15 11:03:48 +08:00
parent 9612e7ac23
commit 01b577eef0
3 changed files with 194 additions and 198 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
sort.sh
View File

@ -1,2 +0,0 @@
#!/bin/bash
sh -c "$(wget https://raw.githubusercontent.com/LCTT/GetNewOne/master/gn1.sh -O -)"

196
sources/tech/20170104 50 ways to avoid getting hacked in 2017.md
View File

@ -1,196 +0,0 @@
Translating by GOLinux!
50 ways to avoid getting hacked in 2017
============================================================
### Paul Simon outlined "50 Ways to Leave Your Lover," whereas we present 50 ways to secure your systems.
![secure your systems](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/rh_003601_05_mech_osyearbook2016_security_cc.png?itok=VNmpz6K- "secure your systems")
Image by : 
Opensource.com
When I was young, Paul Simon released his hit song, [50 Ways to Leave Your Lover][3]. Inspired by this song, I've collected 50 ways sysadmins and laypeople can avoid getting hacked:
### "You just slip out the back, Jack"
1\. Backup your data. If you get hit with ransomware, you don't have to pay if you have backups.
2\. Use a [syncstop][4] when you have to charge your phone in a public place, or bring your own battery backup.
3\. Take advantage of the auditing subsystems. There are lots of cool tools to help monitor your system. If you do have a break in, the audit system might well be able to tell you what happened and what the attacker did.
4\. Speaking of logs, offloading the logs to a centralized server is always a good idea because if a hacker breaks into your system, the first thing he is going to attack is the logging system to cover his tracks. Having a good intrusion system watching the logs also helps.
### "Make a new plan, Stan"
5\. Run SELinux in enforcing mode (see [stopdisablingselinux.com][5]). Didn't think it would take me this long to get to that one? SELinux prevents escalations of zero day vulnerabilities. When [Shell Shock][6] came out, SELinux was the only defense.
6\. Run applications in the [SELinux Sandbox][7] whenever possible—it was a container before containers were cool. Also follow the development of [Flatpack][8], which soon should be developing sandboxing capabilities.
7\. Don't install or use Flash. Firefox no longer supports it, and hopefully most web servers are moving away from it.
8\. Use [confined SELinux users][9] to control what users do in your systems. If you are running a shared login system, set up users as **guest_t**.
### "You don't need to be coy, Roy"
9\. Take [advantage of systemd tools][10] to help secure your services. Most system attacks are going to come through a service listening on the network. Systemd provides great ways to lock down the service. For example, use **[PrivateTmp=yes][1]**. PrivateTmp takes advantage of the mount namespace to set up a private **tmpfs** mount for the server's **/tmp**. This prevents a hacked service from getting access to content in the host's **/tmp** and potentially attacking the rest of the system based on services listening on **/tmp**.
10. **InaccessibleDirectories=/home** is a systemd unit flag that uses the mount namespace to eliminate the **/home** (or any other directory) from the services view, which makes it more difficult for a hacked service ability to attack the content.
11. **ReadOnlyDirectories=/var** is another systemd unit flag that uses the mount namespace to turn the directories contents into read-only mode. You probably should always run with **/usr** in **ReadOnlyMode**. This would prevent a hacked application from rewriting the binary, so the next time it started the service, you would already be hacked.
12\. Drop capabilities from a service (**CapabilityBoundingSet=CAP_CHOWN CAP_KILL**). In the kernel, priviliged processes are broken down into a series of distinct capabilities. Most services do not need many (if any), and systemd provides a simple switch to drop them from a service.
13\. If your service is not going to use the network, then you can turn it off for the service using **PrivateNetwork=yes**. Just turning this on in a service unit file takes advantage of the network namespace and turns off all networks available to the service. Oftentimes a hacker does not actually want to break into your machine—he just wants to use it as an attack server to attack other machines. If the service can't see the network, it cannot attack it.
>Control the devices available to your service.
14\. Control the devices available to your service. Systemd provides the **DeviceAllow** directive, which controls the devices available to the service. **DeviceAllow=/dev/null rw** will limit access to **/dev/null** and only this device node, disallowing access to any other device nodes. The feature is implemented on top of the device's cgroup controller.
15\. Coming soon to a systemd system near you is a new feature, **[ProtectSystem Strict][2]**, which can turn on all of these namespaces to fully lock down the environment in which a service runs.
### "Just get yourself free"
16\. Don't use a cell phone without SELinux ([SEAndroid][11]) in enforcing mode. Luckily, I heard that more than 90% of all Android phones now run with SEAndroid on in enforcing mode. That makes me happy. Now if we could only get those Apple guys to use SELinux.
>Only install software from trusted sources.
17\. Only install software from trusted sources. Don't install dodgy things you find on the Internet. This goes for your cell phone, computer system, virtual machines, containers, and so on.
18\. I don't do online banking on my phone—only on my Linux computer. If a hacker steals my credit card, I lose 50 bucks; if he gets into my bank account, I lose a lot more. I guess I am old. (Get off my lawn.)
19\. One cool thing I did do with my phone is set up my credit card companies to send me a text every time my credit card has been charged. That way if the number gets stolen, I will know a lot quicker.
>I don't do online banking on my phone—only on my Linux computer.
20\. When you need to communicate securely, use the [Signal secure messaging app][12].
### "Hop on the bus gus"
21\. Run Linux on your systems. When I first hooked my father up with a computer system, I barely got home before his system was infested with viruses. I returned and installed Linux on his system, and he has been running it ever since. I believe Linux generally is a more secure system because of the way it was designed, but I also believe the desktop is less likey to be hacked because of the smaller user base. Some would argue that Windows has improved greatly over the years, but for me, I am still sticking with what I know.
22\. Only run distributions with a [Security Response Team][13] watching over the security of the distribution. Enterprise Software is important.
23\. Run an enterprise-level kernel. In containers, the single point of failure is the kernel. If you want to keep it secure, use an enterprise-level kernel, which means it has the latest security fixes, but is not bleeding edge. Remember the latest kernel comes with the latest security fixes, but it also comes with a ton of new code that could have vulnerabilities.
### "You don't need to discuss much"
24\. Most hacks are social engineering—for example, email links, web browser attacks, and phone calls. The best option here is to be educated and skeptical. No one from Nigeria is giving you money. The IRS is not calling your house demanding money. If you get a link to a web site in email from your bank, don't use the link. Type the address directly on the web browser.
25\. Always keep your systems fully up to date with the latest security fixes. The number of systems that are outdated and have known security vulnerabilities is scarey. Script kiddies rely on you **not** to update your system.
>Always keep your systems fully up to date with the latest security fixes.
26\. Always use HTTPS when connecting to services on the network. Chrome and Firefox now have modes to enforce this. If a web site does not support secure communications by 2016, it is probably not worth your visit.
27\. Use [seccomp][14] in your containers. This limits the attack surface on the kernel, which is the single point of failure. Limit what the processes can discuss.
### "Just drop off the key, Lee"
28\. Use a [YubiKey][15] for storing private keys.
29\. Encrypt your data on your systems. At least for laptops, keep your **homedir**and your other data directories encrypted. I was riding the subway in London a few years ago, and had my Laptop "nicked"—the door of the train car closed, and I noticed by laptop was gone and the train was pulling out of the station. Luckily, the disks were encrypted.
30\. Use [Let's Encrypt][16] for all your web sites. There's no reason not to run HTTPS anymore.
31\. Never use the same password on different web servers. This one is difficult not to fall into the trap. Tools like Let's Encrypt help a lot. It's even better if you use ssh keys to log into systems.
32\. Use two-factor authentication (2FA). Passwords have become just about useless. Using YubiKeys and the like make two-factor easy. We all have cell phones. Having a secret in your head and one generated on the phone is always better than a password.
33\. Nothing aggravates me more than websites always asking me to set up an account—can't we do better? Always use a password-generating tool for your website passwords. I am old school: I use [Password Safe][17] and cut and paste into the web browser. I have heard that other people have good luck with [LastPass][18]and other tools that integrate your phone and web service.
34\. Set up a service like [FreeIPA][19] to use for identity services. Using tools such as [Kerberos][20] for authentication and authorization makes keeping track of employees and their access to systems much easier (and it has cool crypto services). Using Active Directory is ok, but I am a little prejudiced.
>When you must use a password that you need to type in often, use an easily remembered sentence rather the a word.
35\. When you must use a password that you need to type in often, use an easily remembered sentence rather the a word. My preferred way to remember passwords is to use a phrase several words long that is easy to type.
### "And get yourself free"
36\. Use [USBGuard][21] to protect your system from rogue USB devices.
37\. The past few years, I have been working on containers, so now let's dive into security on containers. First run them on a system with SELinux turned on in enforcing mode. If your system does not support SELinux, switch the distribution to one that does. SELinux is the best tool for protecting against container break out using the file system.
38\. Run your service inside of a container whenever possible. I believe this is the future—applications using [OCI Image Format][22] and Linux container technology. Launch these containers with Docker, [runC][23], OCID, RKT, Systemd-nspawn, and so on. Although I have often said "containers do not contain," they do contain better than not running them inside of a container.
39\. Run your container in a VM. Virtual machines provide better isolation than containers. Running like containers on virtual machines provides you scalability and isolation from each other.
40\. Run containerized apps with different security needs on different virtual machines. Run your web service containers on virtual machines in the DMZ, but run the database containers on virtual machines outside of the DMZ.
41\. Also remember to run your virtual machines requiring the most security on different physical machines, on different virtual machines inside of containers (a.k.a., defense in depth).
42\. Run your containers in [read-only mode.][24] Containers in development need to be able to write to **/usr**, but a container in production should only be able to write to **tmpfs** and volumes mounted into the container.
43. [Drop capabilities from your containers][25]. We run our processes in and outside of containers with many more "capabiltiies" than they need. You can make your processes more secure by dropping capabilties.
44. [Don't run your processes in containers as root][26]. Most services never need root privileges, or they need it to bind to a port < 1024 and then switch to a non-root user. I would advise always running apps as non-root.
45\. Keep your containers updated with the latest CVEs fixes. Using a system like OpenShift for building and maintaining your container images is a good idea, because it automatically rebuilds container images when a new security fix appears.
46\. An associate of mine says, "Docker is all about running random code from the Internet as root on your host." Get your software from a trusted source. Don't grab the first Apache application that you find at docker.io. The [operating system matters][27].
47\. Run your containers in production on a limited containerized optimized host, such as an [Atomic Host][28], which comes with all of the security turned on, optimized for running containers, with a limited attack surface and atomic updates. What is not to like there?
48\. Use tools like [OpenScap][29] to scan your systems for vulnerabilities. Sadly, new vulnerabilities are always popping up, so you must keep your scanners up to date. (Take a look at [atomic scan][30] for scanning your containers, as well.)
49\. OpenScap also has features to scan for [security configuration][31], such as STIGs (Security Technical Implementation Guides).
50\. Set up a special guest network for all those Christmas IoT devices your kids receive. I love my Amazon Echo and automated lights and power switches ("Alexa, turn on the Christmas Lights"), but each one of these is a Linux operating system that has questionable security.
### "There must be 50 more ways not to get hacked"
What would you add to the list? Let us know in the comments.
_Josh Bressers contributed to this article._
--------------------------------------------------------------------------------
作者简介：
![](https://opensource.com/sites/default/files/styles/profile_pictures/public/walsh1.jpg?itok=JbZWFm6J)
Daniel J Walsh - Daniel Walsh has worked in the computer security field for almost 30 years. Dan joined Red Hat in August 2001.
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/1/yearbook-50-ways-avoid-getting-hacked
作者：[Daniel J Walsh][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/rhatdan
[1]:http://danwalsh.livejournal.com/51459.html
[2]:https://www.phoronix.com/scan.php?page=news_item&px=systemd-New-Protect-Tunables
[3]:https://www.youtube.com/watch?v=0H5chfbcWtY
[4]:http://syncstop.com/
[5]:http://stopdisablingselinux.com/
[6]:http://danwalsh.livejournal.com/71122.html
[7]:http://danwalsh.livejournal.com/31146.html
[8]:http://flatpak.org/
[9]:http://danwalsh.livejournal.com/37404.html
[10]:http://0pointer.de/blog/projects/security.html
[11]:https://source.android.com/security/selinux/
[12]:https://whispersystems.org/
[13]:https://access.redhat.com/blogs/766093/posts/2695561
[14]:https://lwn.net/Articles/656307/
[15]:https://www.yubico.com/
[16]:https://letsencrypt.org/
[17]:https://pwsafe.org/
[18]:https://www.lastpass.com/
[19]:https://www.freeipa.org/page/Main_Page
[20]:https://web.mit.edu/kerberos/
[21]:https://github.com/dkopecek/usbguard
[22]:https://www.opencontainers.org/
[23]:https://runc.io/
[24]:http://www.projectatomic.io/blog/2015/12/making-docker-images-write-only-in-production/
[25]:http://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/
[26]:https://www.projectatomic.io/blog/2016/01/how-to-run-a-more-secure-non-root-user-container/
[27]:https://opensource.com/16/12/yearbook-why-operating-system-matters
[28]:https://access.redhat.com/articles/rhel-atomic-getting-started
[29]:https://www.open-scap.org/
[30]:https://developers.redhat.com/blog/2016/05/02/introducing-atomic-scan-container-vulnerability-detection/
[31]:https://www.open-scap.org/security-policies/scap-security-guide/

194
translated/tech/20170104 50 ways to avoid getting hacked in 2017 copy.md Normal file
View File

@ -0,0 +1,194 @@
2017年系统免遭黑客侵袭的50种方法
============================================================
### Paul Simon 概括了“与爱人分手的50法”，而这里，我们提供了提高系统安全性的50种方法。
![secure your systems](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/rh_003601_05_mech_osyearbook2016_security_cc.png?itok=VNmpz6K- "secure your systems")
图片来自： 
Opensource.com
当我还是小孩子，耳畔萦绕着流行歌[与爱人分手的50法][3]（Paul Simon）。当我渐渐地长大，突然受歌的启发，收集了50种方法，免得你——门内汉和门外汉——遭受黑客侵袭啊：
### "你刚刚从后头溜出去了，杰克"
1\. 备份你的数据。如果你不幸被勒索软件光顾，那么你就不用付出任何代价，因为你做了备份。
2\. 当你需要在公共场所为你的手机充电，那就使用[sysncstop][4]吧，或者你也可以用你的备份电池。
3\. 利用好你的审计子系统，里头有好多很酷的工具可以帮助你监控系统。如果你确实遭到了入侵，那么审计系统也许就可以告诉你发生了什么，以及攻击者做了些什么。
4\. 说到日志，把日志分流到集中式服务器上总是一个不错的想法，因为如果某个黑客侵入你的系统里，他首先要攻击的就是日志系统以便隐藏他的踪迹。构建一个好的入侵检测系统来监控日志，这对于防范黑客也很有帮助。
### "做份新的计划吧，斯坦"
5\. 以强制模式运行 SELinux（见 [stopdisablingselinux.com][5]）。没想到它会花费我这么长时间来达到那个目的？ SELinux 可以防止 0 day 漏洞的升级。当 [Shell Shock][6] 漏洞出现的时候，SELinux是曾唯一的防护手段。
6\. 如果可能，在 [SELinux 沙盒][7]中运行应用程序吧——在容器冷却前，它还是个容器。同时，请遵循 [Flatpack][8] 开发，这个工具很快会开发沙盒功能。
7\. 不要安装或者使用 Flash。Firefox 不再支持它了，同时也希望大多数 web 服务器正在远离它。
8\. 使用 [定义的 SELinux 用户][9]来控制它们在系统中所做的事。如果你正运行着一台共享登陆的系统，设置用户为 **guest_t**。
### "你不必害羞，罗伊"
9\. 利用 [systemd 工具][10]来帮助你提升系统安全。大多数系统攻击是通过监听网络上的服务来实现的，而 Systemd 提供了一些很棒的方法来锁定服务。例如，使用 **[PrivateTmp=yes][1]** 。Privatemp 利用挂载命名空间来为服务器的 **/tmp** 设置一个私有的 **tmpfs** 挂载，这可以阻止被入侵的服务访问到主机 **/tmp** 中的内容，以及潜在的针对基于监听 **/tmp** 的服务的系统其它剩余部分的攻击。
10. **InaccessibleDirectories=/home** 是一个 systemd 单元的标记，它使用挂载命名空间来从服务视图中消除 **/home**（或者其它任何目录），这会使得被入侵的服务攻击内容更为困难。
11. **ReadOnlyDirectories=/var** 是另外一个 systemd 单元的标记，它使用挂载命名空间来将目录内容变成只读模式。你可能总是应该以**只读模式**运行 **/usr** 。这可以阻止一个被入侵的应用程序重写二进制文件，因为那可以在下次服务重启时，保持服务被入侵状态。
12\. 降低服务权限（**CapabilityBoundingSet=CAP_CHOWN CAP_KILL**）。在内核中，特权服务被分解成一些列不同的权限。大多数服务不需要很多（如果需要），而 systemd 提供了一个简单的开关来降低服务中的这些权限。
13\. 如果服务不使用网络，那么你可以使用 **PrivateNetwork=yes** 来为该服务关闭网络功能。只需在服务的单元文件中开启，就可以享受它带来的好处，关闭服务所有可能访问到的网络。黑客常常并不是真的想入侵你的机器——他只是想用它作为攻击服务器来攻击其它机器。如果服务不连上网络，那么就不会受到攻击。
>控制服务可用的设备
14\. 控制服务可用的设备。 Systemd 提供了 **DeviceAllow** 指针，它控制了服务可用的设备。**DeviceAllow=/dev/null rw** 将访问限制为 **/dev/null**，仅可访问该设备节点，不允许对其它任何设备节点的访问。该功能部署在设备的 cgroup 控制器顶端。
15\. Systemd 系统即将迎来的一个新功能是 **[ProtectSystem Strict][2]**，该功能可以开启所有这些名命名空间以完全锁定服务运行的环境。
### "刚刚重获自由"
16\. 不要使用没有运行着 SELinux（[SEAndroid][11]）强制模式的手机。幸运的是，我听说目前超过 90% 的安卓手机都运行着 SEAndroid 的强制模式，这真让我高兴。现在要是我们能让那些果粉们使用 SELinux 就好了。
>只从受信源安装软件。
17\. 只从受信源安装软件。不要安装你从因特网找来的危险东西，对于你的手机、计算机系统、虚拟机以及容器等等也一样。
18\. 我不会在我的手机上进行网上银行操作——我只在我的 Linux 计算机上做这事儿。如果黑客偷了我的信用卡，也许我就丢了那么 50 美元；而如果他黑进我的银行账户，那我丢的钱就会更多。我想我是个老古板。（滚出我的地盘。）
19\. 我用我手机做的一件很酷的事情，就是设置让我的信用卡公司每次在我的信用卡记账时给我发送文本信息。那样的话，如果账号被盗，我会更快地知道。
>我不会在我的手机上进行网上银行操作——我只在我的 Linux 计算机上做这事儿。
20\. 当你需要安全地通讯，请使用[信号安全信息应用][12].
### "搭个便车，格斯"
21\. 在你的计算机系统上运行 Linux。当我第一次用一台计算机系统连上我父亲的计算机时，我就在他的系统受病毒感染前直接回家了。我回去，给他的系统安了个 Linux，而他从那以后就一直运行着它。我相信 Linux 大体上说是一个更加安全的系统，因为它的设计方式。而且我也相信这个桌面被黑的可能性也相对较小，因为用它的人相对较少。有些人或许要持反对意见了，他们会说 Windows 在过去几年中已经有了很大的改进了，但对于我而言，我仍然坚持己见。
22\. 只运行那些有[安全反应团队][13]进行安全监管的发行版。企业软件及其重要。
23\. 运行一个企业级内核。在容器中，单点故障往往是内核。如果你想要保证它安全，那么就使用一个企业级内核，即便它不是一个最新的版本，但这也意味着包含了最新的安全补丁。记住，最新的内核虽然带来了最新的安全补丁，但是它也带来了大量的新代码，这些代码可能存在漏洞。
### "你不要说太多"
24\. 大多数非法入侵都是通过社会工程学实施的——例如，电子邮件链接，web 浏览器攻击，以及电话。对于此，最好的选择是接受相关教育，并且对一切留个心眼儿。没有哪个来自尼日利亚的家伙会给你钱。美国国税局也不会打电话到你家问你要钱。如果你电子邮件收到了来自你银行的电子邮件，里面包含有到某个网站的链接，那么不要直接去点击那个链接，在 web 浏览器中输入那个地址来打开。
25\. 总是把你的系统打上最新的安全补丁。已知有安全漏洞以及过时的系统的数量十分可怕，脚本小子们依赖于你**不**更新系统。
>总是把你的系统打上最新的安全补丁。
26\. 当连接到网络上的服务时，请始终使用 HTTPS。Chrome 和 Firefox 现在已经开启了强制模式。到 2016 年为止，那些还不支持安全通讯的网站可能就不值得你们访问。
27\. 在你的容器中使用 [seccomp][14]，这会限制针对内核表面的攻击，这只是单点故障。限制什么进程可以会话。
### "就把那钥匙丢下吧，李"
28\. 使用 [YubiKey][15] 来存储私钥。
29\. 加密你系统上的数据。至少对于笔记本而言，应该把**家目录**以及你的其它数据目录加密。几年前，我正乘坐在伦敦的地铁上，我的笔记本就成了某些人的目标——我下了车，车门关上了，而我发现我的笔记本不见了。此时，地铁已经驶出了站台。幸运的是，我把磁盘加密了。
30\. 给你的所有网站用上 [Let's Encrypt][16] 吧，没有任何理由不再运行 HTTPS 了。
31\. 绝不要在不同 web 服务器上使用相同的密码。虽然这个很难不落入陷阱，但是像 Let's Encrypt 这样的工具会有很大帮助。如果你使用 ssh 密钥来登陆进系统，这会更好。
32\. 使用双因素认证（2FA）。密码变得无关紧要，使用 Yubieys 以及诸如此类的工具可以使得双因素认证很方便，我们都有手机。在手机中生成一个密钥，并把秘密藏在你的大脑中，总是比一个密码来得更好。
33\. 网站总要我设置帐号，没有比这更激怒我的事情了——我们就不能做得更好点？对于网站密码，始终都要使用密码生成工具来生成。我是个保守派：我使用 [Password Safe][17] 来生成密码，然后剪切粘贴到 web 浏览器中。我听说，其他人使用 [LastPass][18]，或者其它整合在手机和 web 服务中的工具也用着不错。
34\. 配置像 [FreeIPA][19] 之类的服务，用于身份认证。使用像 [Kerberos][20] 之类的工具来认证和授权，会使得跟踪雇员和他们对系统的访问更为简便（而且它也有很酷的加密服务）。使用活动目录也很不错，或许我有点偏颇。
>如果你经常输入密码，那就使用一个容易记忆的句子，而不是一个单词。
35\. 如果你经常输入密码，那就使用一个容易记忆的句子，而不是一个单词。我所偏好的用于记忆密码的方式，就是使用几个单词长度并且易于输入的词组。
### "让自己自由"
36\. 使用 [USBGuard][21] 来保护你的系统免遭流氓 USB 设备破坏。
37\. 在过去几年中，我一直工作在容器中，让我们来说说容器的安全吧。首先，让它们在开启强制模式的 SELinux 的系统中运行。如果你的系统不支持 SELinux，那就换个支持它的版本吧。SELinux 是使用文件系统来保护容器免遭破坏的最佳工具。
38\. 如果可能，在容器中跑你的服务吧。我相信，使用 [OCI Image Format][22] 和 Linux 容器技术是应用的未来。用 [runC][23]，OCID，RKT，Systemd-nspawn 等等应用来启动这些容器。虽然我常常说“容器并不包容“，但是这些服务确实在容器外运行时要比容器内好。
39\. 在虚拟机中运行容器。虚拟机提供比容器更好的隔离机制，在虚拟机中跑像容器之类的东西，更加灵活有弹性，并且互相隔离。
40\. 在不同的虚拟中，按不同的安全需求跑容器应用。你可以在 DMZ 中的虚拟机上跑 web 服务容器，而在 DMZ 外的虚拟机上跑数据容器。
41\. 同时，记得在不同的物理机上跑需要最高安全性的虚拟机，并且抛在在容器内的不同虚拟机上（这也叫深度防护）。
42\. 以[只读模式][24]跑容器。开发环境中的容器需要能够写入到 **/usr**，但是生产环境中的容器只能写入到 **tmpfs**，并且将卷挂载到容器中。
43\. [降低容器权限][25]。不管是在容器中，还是在容器外，我们都以比它们所需的更多的“权限”跑它们的进程，你可以通过降低权限来让你的进程更加安全。
44\. [不要以 root 身份在容器中跑进程][26]。大多数服务都不需要 root 特权，或者它们需要该权限来绑定到 < 1024 的端口，然后切换到非 root 用户。我会建议你始终以非 root 身份来跑应用。
45\. 给你的容器打上最新的 CVE 补丁。使用像 OpenShift 这样的工具来构建并维护你的容器镜像是个不错的主意，因为它会在新的安全补丁出现时自动重构容器镜像。
46\. 我的一个同事说“Docker 就是用来在你的主机上以 root 身份运行来在因特网的随机代码的。”从一个受信源获取软件，不要随意在 docker.io 上抓取第一个 Apache 应用。[操作系统有重要关系][27]。
47\. 在一台受限的容器化优化的主机上跑生产环境容器，例如在一台[原子主机][28]上，它开启了所有安全特性，为运行中的容器而优化，带有受限的攻击表层和原子更新。有什么不喜欢那儿的吗？
48\. 使用像 [OpenScap][29] 这样的工具来扫描你系统的漏洞。糟糕的是，新的漏洞总是层出不穷，所以你得时刻更新你的扫描器。（也可以看看 [atomic scan][30]，用于扫描你的容器。）
49\. OpenScap 也具有扫描[安全配置][31]的功能，如 STIG（安全技术部署指南）。
50\. 为你孩子收到的所有那些圣诞物联网设备设置一个特别的客户网络。我钟爱我的 Amazon Echo，还有自动化灯以及电源开关（“亚力克沙，打开圣诞灯“），但是所有这些都是由可能存在安全问题的 Linux 操作系统控制。
### "一定还有着另外 50 种免遭黑客侵害的方法"
你会为这个列表添加点什么呢？在下面的评论中告诉我们吧。
_Josh Bressers 对本文作出贡献。_
--------------------------------------------------------------------------------
作者简介：
![](https://opensource.com/sites/default/files/styles/profile_pictures/public/walsh1.jpg?itok=JbZWFm6J)
Daniel J Walsh - Daniel Walsh 已经致力于计算机安全领域将近 30 年。Dan 在 2001 年 8 月份加入 Red Hat。
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/1/yearbook-50-ways-avoid-getting-hacked
作者：[Daniel J Walsh][a]
译者：[GOLinux](https://github.com/GOLinux)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/rhatdan
[1]:http://danwalsh.livejournal.com/51459.html
[2]:https://www.phoronix.com/scan.php?page=news_item&px=systemd-New-Protect-Tunables
[3]:https://www.youtube.com/watch?v=0H5chfbcWtY
[4]:http://syncstop.com/
[5]:http://stopdisablingselinux.com/
[6]:http://danwalsh.livejournal.com/71122.html
[7]:http://danwalsh.livejournal.com/31146.html
[8]:http://flatpak.org/
[9]:http://danwalsh.livejournal.com/37404.html
[10]:http://0pointer.de/blog/projects/security.html
[11]:https://source.android.com/security/selinux/
[12]:https://whispersystems.org/
[13]:https://access.redhat.com/blogs/766093/posts/2695561
[14]:https://lwn.net/Articles/656307/
[15]:https://www.yubico.com/
[16]:https://letsencrypt.org/
[17]:https://pwsafe.org/
[18]:https://www.lastpass.com/
[19]:https://www.freeipa.org/page/Main_Page
[20]:https://web.mit.edu/kerberos/
[21]:https://github.com/dkopecek/usbguard
[22]:https://www.opencontainers.org/
[23]:https://runc.io/
[24]:http://www.projectatomic.io/blog/2015/12/making-docker-images-write-only-in-production/
[25]:http://rhelblog.redhat.com/2016/10/17/secure-your-containers-with-this-one-weird-trick/
[26]:https://www.projectatomic.io/blog/2016/01/how-to-run-a-more-secure-non-root-user-container/
[27]:https://opensource.com/16/12/yearbook-why-operating-system-matters
[28]:https://access.redhat.com/articles/rhel-atomic-getting-started
[29]:https://www.open-scap.org/
[30]:https://developers.redhat.com/blog/2016/05/02/introducing-atomic-scan-container-vulnerability-detection/
[31]:https://www.open-scap.org/security-policies/scap-security-guide/