mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
ZTinoZ
commit
caa042df56
@ -1,10 +1,10 @@
|
||||
Exaile 3.4.1 概述 — 一个全功能的GNOME音乐播放器
|
||||
Exaile 3.4.1 概览：一个全功能的GNOME音乐播放器
|
||||
================================================================================
|
||||
**Exaile** 在过去两年显得有些平静，也许只有一个或者两个稳定版发布，但尽管如此，在功能方面，它是一个和[Rhythmbox][1]或者[Banshee][2]相匹敌的全功能GNOME音乐播放器。然而，在过去的两个月，在"We’re not dead yet"的口号下，推出了一个新的稳定版3.4，同时在11月1日还推出了3.4.1增量版本。事实上，Exaile有很多的功能，我可以继续写很多的文章而不是在一篇文章里全部介绍到，就让我们来看一下一些最显著的特点吧。
|
||||
**Exaile** 在过去两年显得有些平静，也许只有一个或者两个稳定版发布，但尽管如此，在功能方面，它是一个和[Rhythmbox][1]或者[Banshee][2]相匹敌的全功能GNOME音乐播放器。不过，在过去的两个月，在"We’re not dead yet"的口号下，他们推出了一个新的稳定版3.4，同时在11月1日还推出了3.4.1增量版本。事实上，Exaile有很多的功能，我可以继续写很多的文章而不是在一篇文章里全部介绍到，就让我们来看一下一些最显著的特点吧。
|
||||
|
||||
|
||||
|
||||
[Exaile][3]是基于GTK-2，用Python写的音乐播放器，它能很好地兼容GNOME，有和旧的Amarok1.4或者Clementine非常类似的界面，以及一些很好的功能。界面主要由两个面板组成，两个都支持标签。左边的面板提供对音乐集，网络音频，只能和自定义播放列表，文件浏览，播客，组标签以及歌词的访问，窗口的主要部分是播放列表(支持多种，带标签的播放列表)和控制按钮。
|
||||
[Exaile][3]是基于GTK-2，用Python写的音乐播放器，它能很好地兼容GNOME，有和旧的Amarok1.4或者Clementine非常类似的界面，以及一些很好的功能。界面主要由两个面板组成，两个都支持标签。左边的面板提供对音乐集，网络音频，智能和自定义播放列表，文件浏览，播客，组标签以及歌词的访问，窗口的主要部分是播放列表(支持多个列表，以标签方式组织的播放列表)和控制按钮。
|
||||
|
||||
Exaile的界面和Clementine或者Amarok1.4非常相似，可以显示或者隐藏左边的标签。
|
||||
|
||||
@ -26,7 +26,7 @@ Exaile的功能几乎不尽其数。你可以在音乐集中组织音乐，听
|
||||
|
||||
|
||||
|
||||
首选项窗口允许多个方面配置Exaile，包括启用或者禁用插件，外观，系统托盘集成或者播放模式。外观设置允许你更改标签的布局，显示或者隐藏便签栏，启用或者禁用透明性或者禁用启动画面。
|
||||
首选项窗口允许配置Exaile的各个方面，包括启用或者禁用插件，外观，系统托盘集成或者播放模式。外观设置允许你更改标签的布局，显示或者隐藏便签栏，启用或者禁用透明性或者禁用启动画面。
|
||||
|
||||
|
||||
|
||||
@ -64,7 +64,7 @@ via: http://www.tuxarena.com/2014/11/exaile-3-4-1-overview-a-feature-complete-gn
|
||||
|
||||
作者：Craciun Dan
|
||||
译者：[ictlyh](https://github.com/ictlyh)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,24 +1,25 @@
|
||||
VirturalBox 5.0 beta版终于发布了
|
||||
VirturalBox 终于进入到 5.0 世代
|
||||
=======================================
|
||||
**甲骨文公司的桌面虚拟化软件获得了近五年来的第一次重大改版，但是更像是改进而不是革命性的的变化。**
|
||||
|
||||
**本月初，甲骨文公司的桌面虚拟化软件获得了近五年来的第一次重大改版，但是更像是改进而不是革命性的的变化。**
|
||||
|
||||
VirtualBox，由Sun公司创建，现在由甲骨文管理的开源虚拟化系统，获得了近5年来第一次的主版本更新发布。
|
||||
|
||||
从发行说明和测试版本身的表现来看，别期望任何真正革命性的改变。在此版本中，VirtualBox在视觉上和技术上都做了一些改进，但和VMware相比，它的主要优势仍然是相同核心功能的自由化。
|
||||
从发行说明和测试版本身的表现来看，别期望任何真正革命性的改变。在此版本中，VirtualBox在视觉上和技术上都做了一些改进，但和VMware相比，它的主要优势仍然是相同核心功能的开源实现。
|
||||
|
||||
VirtualBox 4.0的最后一个主要版本在2010年12月发布，它采用了新的图形化用户界面，新的虚拟化硬件和重组的项目设计，带来了重大的改版。但项目主要版本的发布步伐缓慢，上一次重要版本(版本4.3)在2013年底才发布。从那时起，一切都被正式称为“维修”发布。
|
||||
VirtualBox 4.0的最后一个主要版本在2010年12月发布，它采用了新的图形化用户界面，新的虚拟化硬件和重组的项目设计，进行了重大的改版。但项目主要版本的发布步伐缓慢，上一次重要版本(版本4.3)在2013年底才发布。从那时起，一切都被正式称为“维护”发布。
|
||||
|
||||
**VirtualBox 5.0**
|
||||
|
||||
|
||||
*VirtualBox 5.0的第一个测试版增加了编辑菜单，VM窗口的快捷方式图标等功能，如下面所示。*
|
||||
|
||||
VirtualBox 5.0最大的变化是增加了对硬件辅助虚拟化指令集扩展的支持。AES-NI指令集通常用于加密时的硬件加速，SSE 4.1和SSE 4.2指令集都包括在其中。另外一点是支持Windows和Linux客户机的半虚拟化，一个抽象主机音响的新的架构以及支持客户机中的USB 3（xHCI）控制器。
|
||||
VirtualBox 5.0最大的变化是增加了对硬件辅助虚拟化指令集扩展的支持。AES-NI指令集通常用于加密时的硬件加速，SSE 4.1和SSE 4.2指令集都包括在其中。另外一点是支持Windows和Linux客户机的半虚拟化，一个抽象主机音响设备的新的架构以及支持客户机中的USB 3（xHCI）控制器。
|
||||
|
||||
大部分可用更新都是对VirtualBox 图形化用户界面的改进。一个大的变化就是支持给单个虚拟主机自定义菜单和工具栏，这样很少或者从不使用的选项就可以彻底删除。另外重要的一点是可以在VirtualBox接口内部对虚拟磁盘进行加密，而不依赖于客户机操作系统自身的磁盘加密功能(假设有的话)。
|
||||
大部分可用性更新都是对 VirtualBox 图形化用户界面的改进。一个大的变化就是支持给单个虚拟主机自定义菜单和工具栏，这样很少或者从不使用的选项就可以彻底删除。另外重要的一点是可以在VirtualBox接口内部对虚拟磁盘进行加密，而不依赖于客户机操作系统自身的磁盘加密功能(假设有的话)。
|
||||
|
||||
甲骨文公司提醒由于这是个测试版软件，需要谨慎对待。当然，主界面和客户机系统界面在某方面都可能引起红黑测试版警告。但之前VirtualBox发行版(4.3.26)上创建的Windows 10虚拟机启动和运行都没问题，5.0版本中添加的VirtualBox客户机功能--更好的视频支持，双向复制和粘贴，以及其它功能--安装的时候也没有问题。(更好地支持Windows 10的修复从4.3.18版本后就开始出现)。
|
||||
甲骨文公司提醒由于这是个测试版软件，需要谨慎对待。当然，主界面和客户机系统界面的某个角落打着红黑相间的测试警告标志。但之前VirtualBox发行版(4.3.26)上创建的Windows 10虚拟机启动和运行都没问题，5.0版本中添加的VirtualBox客户机功能--更好的视频支持，双向复制和粘贴，以及其它功能--在安装的时候也没有问题。(从4.3.18版本就改进了对 Windows 10的支持)。
|
||||
|
||||
虽然没有明确指出5.0的最终版什么时候会发布，但是甲骨文公司[鼓励用户][1]在非生产环境中下载和使用测试版，并在[测试版反馈论坛][2]中报告bug文件。
|
||||
虽然没有明确指出5.0的最终版什么时候会发布，但是甲骨文公司[建议用户][1]在非生产环境中下载和使用测试版，并在[测试版反馈论坛][2]中提交bug报告。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -26,7 +27,7 @@ via: http://www.infoworld.com/article/2905098/virtualization/oracle-virtualbox-5
|
||||
|
||||
作者：[Serdar Yegulalp][a]
|
||||
译者：[ictlyh](https://github.com/ictlyh)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,74 +0,0 @@
|
||||
Linux Kernel 4.0 Features Live Kernel Patching, PS3 Support
|
||||
================================================================================
|
||||
|
||||
|
||||
**A new stable release of the Linux Kernel [has been announced][1] by Linus Torvalds on the Linux kernel mailing list. **
|
||||
|
||||
Linux 4.0, codenamed ‘Hurr durr I’m a sheep’ — no, really — brings with it a small set of new hardware support, driver improvements, performance tweaks, bug fixes and the like.
|
||||
|
||||
But remarking on the minor-ness of the update, Torvalds’ writes;
|
||||
|
||||
> “Feature-wise, 4.0 doesn’t have all that much special. Much have been made of the new kernel patching infrastructure, but realistically […] we’ve had much bigger changes in other versions. So this is very much a “solid code progress” release.”
|
||||
|
||||
Linus adds that Linux 4.1 is likely to be a ‘bigger release’.
|
||||
|
||||
### New Linux Kernel 4.0 Features ###
|
||||
|
||||
Install Kernel Updates Without Rebooting
|
||||
|
||||
If you’ve ever been put out by the need to reboot your Linux box to finish installing a kernel update you won’t be alone. It’s a minor inconvenience on the desktop, and a major one for servers.
|
||||
|
||||
|
||||
Reboot-free Kernel Updates
|
||||
|
||||
The ability to install/apply security patches to the Linux kernel “live”, without the need to reboot, has been a long-held want of many Linux enthusiasts for years.
|
||||
|
||||
A slew of third-party projects, like [Oracle’s KSplice][2] and Red Hat’s Kpatch, have sought to offer live patching functionality for certain distributions.
|
||||
|
||||
For servers, enterprise and mission-critical use cases where uptime is priority live kernel patching is a pretty big deal.
|
||||
|
||||
The good news is that Linux 4.0 makes having to reboot to complete a kernel update a thing of the past.
|
||||
|
||||
Well, almost.
|
||||
|
||||
The initial groundwork to support reboot-free patching arrives in this latest release, ready for experienced sysadmins to take advantage of in Linux 4.0.
|
||||
|
||||
Desktop Linux distributions should also be able to take advantage of the feature too (though given the complexity involved in configuring the reboot-less functionality on the end-user side it may be a little way off).
|
||||
|
||||
This infrastructure will continue to be refined and improved on over the course of the 4.x series. As it does so I expect we’ll all start to hear more about it.
|
||||
|
||||
#### Other Changes ####
|
||||
|
||||
Although it is considered a small release the latest Linux kernel manages to squeeze in a welcome set of hardware improvements, new drivers and performance tweaks. These include:
|
||||
|
||||
|
||||
- Improvements to Intel ‘Skylake’ platform
|
||||
- Intel Quark SoC support
|
||||
- Various patches to improve Linux running on a Playstation 3
|
||||
- TOpen-source AMD Radeon driver supports DisplayPort Audio
|
||||
- Various misc HID driver tweaks, including Lenovo compact keyboards, Wacom Cintiq 27QHD
|
||||
- Toshiba power settings driver adds USB sleep/charge functionality, rapid charge, sleep w/ music, etc
|
||||
- File System tweaks, including F2FS, BtrfFS, etc
|
||||
|
||||
### Install Linux Kernel 4.0 on Ubuntu ###
|
||||
|
||||
Although classed as stable there is, at present, **no need for desktop users or new-comers to go upgrade**.
|
||||
|
||||
The impatient and adept can take a crack at installing Linux 4.0 in Ubuntu 15.04 Beta by grabbing the appropriate set of packages from [Canonical’s mainline kernel archive][3] or by risking a third-party PPA hosted on Launchpad.
|
||||
|
||||
Ubuntu 15.04 Vivid Vervet is due later this month and will ship with Ubuntu Kernel 3.19 (the Ubuntu kernel is the Linux Kernel plus Ubuntu-specific patches that have not been accepted upstream).
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.omgubuntu.co.uk/2015/04/linux-kernel-4-0-new-features
|
||||
|
||||
作者：[Joey-Elijah Sneddon][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://plus.google.com/117485690627814051450/?rel=author
|
||||
[1]:https://lkml.org/lkml/2015/4/12/178
|
||||
[2]:http://www.omgubuntu.co.uk/2009/10/how-to-install-kernel-updates-without-rebooting
|
||||
[3]:http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
|
||||
@ -1,3 +1,5 @@
|
||||
FSSlc translating
|
||||
|
||||
How to Generate/Encrypt/Decrypt Random Passwords in Linux
|
||||
================================================================================
|
||||
We have taken initiative to produce Linux tips and tricks series. If you’ve missed the last article of this series, you may like to visit the link below.
|
||||
@ -101,4 +103,4 @@ via: http://www.tecmint.com/generate-encrypt-decrypt-random-passwords-in-linux/
|
||||
|
||||
[a]:http://www.tecmint.com/author/avishek/
|
||||
[1]:http://www.tecmint.com/5-linux-command-line-tricks/
|
||||
[2]:http://www.tecmint.com/echo-command-in-linux/
|
||||
[2]:http://www.tecmint.com/echo-command-in-linux/
|
||||
|
||||
@ -0,0 +1,158 @@
|
||||
HTTP Public Key Pinning Extension HPKP for Apache, NGINX and Lighttpd
|
||||
================================================================================
|
||||
Public Key Pinning means that a certificate chain must include a whitelisted public key. It ensures only whitelisted Certificate Authorities (CA) can sign certificates for `*.example.com`, and not any CA in your browser store. This article has background theory and configuration examples for Apache, Lighttpd and NGINX.
|
||||
|
||||
### HTTP Public Key Pinning Extension ###
|
||||
|
||||
An example might be your bank, which always have their certificate from CA Company A. With the current certificate system, CA Company B, CA Company C and the NSA CA can all create a certificate for your bank, which your browser will hapily accept because those companies are also trusted root CA's.
|
||||
|
||||
If the bank implements HPKP and pin's their first intermidiate certificate (from CA Company A), browsers will not accept certificates from CA Company B and CA Company C, even if they have a valid trust path. HPKP also allows your browser to report back the failure to the bank, so that they know they are under attack.
|
||||
|
||||
Public Key Pinning Extension for HTTP (HPKP) is a standard for public key pinning for HTTP user agents that's been in development since 2011. It was started by Google, which, even though it had implemented pinning in Chrome, understood that manually maintaining a list of pinned sites can't scale.
|
||||
|
||||
Here is a quick feature overview of HPKP:
|
||||
|
||||
- HPKP is set at the HTTP level, using the `Public-Key-Pins` response header.
|
||||
- The policy retention period is set with the max-age parameter, it specifies duration in seconds.
|
||||
- The PKP header can only be used over an error-free secure encryption.
|
||||
- If multiple headers are seen, only the first one is processed.
|
||||
- Pinning can be extended to subdomains with the `includeSubDomains` parameter.
|
||||
- When a new PKP header is received, it overwrites previously stored pins and metadata.
|
||||
- A pin consists out of the hashing algorithm and an "Subject Public Key Info" fingerprint.
|
||||
|
||||
This article first has some theory about the workings of HPKP, down below you'll find the part which shows you how to get the required fingerprints and has web server configuration.
|
||||
|
||||
### SPKI Fingerprint - Theory ###
|
||||
|
||||
As explained by Adam Langley in [his post][1], we hash a public key, not a certificate:
|
||||
|
||||
> In general, hashing certificates is the obvious solution, but the wrong one. The problem is that CA certificates are often reissued: there are multiple certificates with the same public key, subject name etc but different extensions or expiry dates. Browsers build certificates chains from a pool of certificates, bottom up, and an alternative version of a certificate might be substituted for the one that you expect.
|
||||
>
|
||||
> For example, StartSSL has two root certificates: one signed with SHA1 and the other with SHA256. If you wished to pin to StartSSL as your CA, which certificate hash would you use? You would have to use both, but how would you know about the other root if I hadn't just told you?
|
||||
>
|
||||
> Conversely, public key hashes must be correct:
|
||||
>
|
||||
> Browsers assume that the leaf certificate is fixed: it's always the starting point of the chain. The leaf certificate contains a signature which must be a valid signature, from its parent, for that certificate. That implies that the public key of the parent is fixed by the leaf certificate. So, inductively, the chain of public keys is fixed, modulo truncation.
|
||||
>
|
||||
> The only sharp edge is that you mustn't pin to a cross-certifying root. For example, GoDaddy's root is signed by Valicert so that older clients, which don't recognise GoDaddy as a root, still trust those certificates. However, you wouldn't want to pin to Valicert because newer clients will stop their chain at GoDaddy.
|
||||
>
|
||||
> Also, we're hashing the SubjectPublicKeyInfo not the public key bit string. The SPKI includes the type of the public key and some parameters along with the public key itself. This is important because just hashing the public key leaves one open to misinterpretation attacks. Consider a Diffie-Hellman public key: if one only hashes the public key, not the full SPKI, then an attacker can use the same public key but make the client interpret it in a different group. Likewise one could force an RSA key to be interpreted as a DSA key etc.
|
||||
|
||||
### Where to Pin ###
|
||||
|
||||
Where should you pin? Pinning your own public key is not the best idea. The key might change or get compromised. You might have multiple certificates in use. The key might change because you rotate your certificates every so often. It might key compromised because the web server was hacked.
|
||||
|
||||
The easiest, but not most secure place to pin is the first intermediate CA certificate. The signature of that certificate is on your websites certificate so the issuing CA's public key must always be in the chain.
|
||||
|
||||
This way you can renew your end certificate from the same CA and have no pinning issues. If the CA issues a different root, then you have a problem, there is no clear solution for this yet. There is one thing you can do to mitigate this:
|
||||
|
||||
- Always have a backup pin and a spare certificate from a different CA.
|
||||
|
||||
The RFC states that you need to provide at least two pins. One of the pins must be present in the chain used in the connection over which the pins were received, the other pin must not be present.
|
||||
|
||||
This other pin is your backup public key. It can also be the SPKI fingerprint of a different CA where you have a certificate issued.
|
||||
|
||||
An alternative and **more secure** take on this issue is to create at least three seperate public keys beforehand (using OpenSSL, see [this page][2] for a Javascript OpenSSL command generator) and to keep two of those keys as a backup in a safe place, offline and off-site.
|
||||
|
||||
You create the SPKI hashes for the three certificates and pin those. You only use the first key as the active certificate. When it is needed, you can then use one of the alternative keys. You do however need to let that certificate sign by a CA to create a certificate pair and that process can take a few days depending on the certificate.
|
||||
|
||||
This is not a problem for the HPKP because we take the SPKI hash of the public key, and not of the certificate. Expiration or a different chain of CA signer do not matter in this case.
|
||||
|
||||
If you have the means and procedures to create and securely save at least three seperate keys as described above and pin those, it would also protect you from your CA provider getting compromised and giving out a fake certificate for your specific website.
|
||||
|
||||
### SPKI Fingerprint ###
|
||||
|
||||
To get the SPKI fingerprint from a certificate we can use the following OpenSSL command, as shown in [the RFC draft][3]:
|
||||
|
||||
openssl x509 -noout -in certificate.pem -pubkey | \
|
||||
openssl asn1parse -noout -inform pem -out public.key;
|
||||
openssl dgst -sha256 -binary public.key | openssl enc -base64
|
||||
|
||||
Result:
|
||||
|
||||
klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=
|
||||
|
||||
The input `certificate.pem` file is the first certificate in the chain for this website. (At the time of writing, `COMODO RSA Domain Validation Secure Server CA, Serial 2B:2E:6E:EA:D9:75:36:6C:14:8A:6E:DB:A3:7C:8C:07.`)
|
||||
|
||||
You need to also do this with your backup public key, ending up with two fingerprints.
|
||||
|
||||
### Bugs ###
|
||||
|
||||
At the time of writing this article (2015-Jan) the only browser supporting HPKP (Chrome) has a serious issue where Chrome doesn't treat the max-age and includeSubdomains directives from HSTS and HPKP headers as mutually exclusive. This means that if you have HSTS and HPKP with different policiesfor max-age or includeSubdomains they will be interchanged. See this bug for more info: [https://code.google.com/p/chromium/issues/detail?id=444511][4]. Thanks to Scott Helme from [https://scotthelme.co.uk][5] for finding and notifying me and the Chromium project about it.
|
||||
|
||||
### Webserver configuration ###
|
||||
|
||||
Below you'll find configuration instructions for the three most populair web servers. Since this is just a HTTP header, almost all web servers will allow you to set this. It needs to be set for the HTTPS website.
|
||||
|
||||
The example below pins the `COMODO RSA Domain Validation Secure Server CA` and the `Comodo PositiveSSL` CA 2 as a backup, with a 30 day expire time including all subdomains.
|
||||
|
||||
#### Apache ####
|
||||
|
||||
Edit your apache configuration file (`/etc/apache2/sites-enabled/website.conf or /etc/apache2/httpd.conf` for example) and add the following to your VirtualHost:
|
||||
|
||||
# Optionally load the headers module:
|
||||
LoadModule headers_module modules/mod_headers.so
|
||||
|
||||
Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"
|
||||
|
||||
#### Lighttpd ####
|
||||
|
||||
The lighttpd variant is just as simple. Add it to your Lighttpd configuration file (`/etc/lighttpd/lighttpd.conf` for example):
|
||||
|
||||
server.modules += ( "mod_setenv" )
|
||||
$HTTP["scheme"] == "https" {
|
||||
setenv.add-response-header = ( "Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains")
|
||||
}
|
||||
|
||||
#### NGINX ####
|
||||
|
||||
NGINX is even shorter with its config. Add this in the server block for your HTTPS configuration:
|
||||
|
||||
add_header Public-Key-Pins 'pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains';
|
||||
|
||||
### Reporting ###
|
||||
|
||||
HPKP reporting allows the user-agent to report any failures back to you.
|
||||
|
||||
If you add an aditional `report-uri="http://example.org/hpkp-report`" parameter to the header and set up a listener there, clients will send reports if they encounter a failure. A report is sent as a POST request to the report-uri with a JSON body like this:
|
||||
|
||||
{
|
||||
"date-time": "2014-12-26T11:52:10Z",
|
||||
"hostname": "www.example.org",
|
||||
"port": 443,
|
||||
"effective-expiration-date": "2014-12-31T12:59:59",
|
||||
"include-subdomains": true,
|
||||
"served-certificate-chain": [
|
||||
"-----BEGINCERTIFICATE-----\nMIIAuyg[...]tqU0CkVDNx\n-----ENDCERTIFICATE-----"
|
||||
],
|
||||
"validated-certificate-chain": [
|
||||
"-----BEGINCERTIFICATE-----\nEBDCCygAwIBA[...]PX4WecNx\n-----ENDCERTIFICATE-----"
|
||||
],
|
||||
"known-pins": [
|
||||
"pin-sha256=\"dUezRu9zOECb901Md727xWltNsj0e6qzGk\"",
|
||||
"pin-sha256=\"E9CqVKB9+xZ9INDbd+2eRQozqbQ2yXLYc\""
|
||||
]
|
||||
}
|
||||
|
||||
### No Enforcment, report only ###
|
||||
|
||||
HPKP can be set up without enforcement, in reporting mode by using the `Public-Key-Pins-Report-Only` response header.
|
||||
|
||||
This approach allows you to set up pinning without your site being unreachable or HPKP being configured incorrectly. You can later move to enforcement by changing the header back to `Public-Key-Pins`.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html
|
||||
|
||||
作者：[Remy van Elst][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://raymii.org/
|
||||
[1]:http://www.imperialviolet.org/2011/05/04/pinning.html
|
||||
[2]:https://raymii.org/s/software/OpenSSL_Command_Generator.html
|
||||
[3]:https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#appendix-A
|
||||
[4]:https://code.google.com/p/chromium/issues/detail?id=444511
|
||||
[5]:https://scotthelme.co.uk/
|
||||
290
sources/tech/20150415 Strong SSL Security on nginx.md
Normal file
290
sources/tech/20150415 Strong SSL Security on nginx.md
Normal file
@ -0,0 +1,290 @@
|
||||
Strong SSL Security on nginx
|
||||
================================================================================
|
||||
[][1]
|
||||
|
||||
This tutorial shows you how to set up strong SSL security on the nginx webserver. We do this by disabling SSL Compression to mitigate the CRIME attack, disable SSLv3 and below because of vulnerabilities in the protocol and we will set up a strong ciphersuite that enables Forward Secrecy when possible. We also enable HSTS and HPKP. This way we have a strong and future proof ssl configuration and we get an A on the Qually Labs SSL Test.
|
||||
|
||||
TL;DR: [Copy-pastable strong cipherssuites for NGINX, Apache and Lighttpd: https://cipherli.st][2]
|
||||
|
||||
This tutorial is tested on a Digital Ocean VPS. If you like this tutorial and want to support my website, use this link to order a Digital Ocean VPS: [https://www.digitalocean.com/?refcode=7435ae6b8212][2]
|
||||
|
||||
This tutorial works with the stricter requirements of the SSL Labs test [announced on the 21st of January 2014][4] (It already did before that, if you follow(ed) it you get an A+)
|
||||
|
||||
- [This tutorial is also available for Apache][5]
|
||||
- [This tutorial is also available for Lighttpd][6]
|
||||
- [This tutorial is also available for FreeBSD, NetBSD and OpenBSD over at the BSD Now podcast][7]: [http://www.bsdnow.tv/tutorials/nginx][8]
|
||||
|
||||
You can find more info on the topics by following the links below:
|
||||
|
||||
- [BEAST Attack][9]
|
||||
- [CRIME Attack][10]
|
||||
- [FREAK Attack][11]
|
||||
- [Heartbleed][12]
|
||||
- [Perfect Forward Secrecy][13]
|
||||
- [Dealing with RC4 and BEAST][14]
|
||||
|
||||
We are going to edit the nginx settings in the file `/etc/nginx/sited-enabled/yoursite.com` (On Ubuntu/Debian) or in `/etc/nginx/conf.d/nginx.conf` (On RHEL/CentOS).
|
||||
|
||||
For the entire tutorial, you need to edit the parts between the `server` block for the server config for port 443 (ssl config). At the end of the tutorial you can find the complete config example.
|
||||
|
||||
*Make sure you back up the files before editing them!*
|
||||
|
||||
### The BEAST attack and RC4 ###
|
||||
|
||||
In short, by tampering with an encryption algorithm's CBC - cipher block chaining - mode's, portions of the encrypted traffic can be secretly decrypted. More info on the above link.
|
||||
|
||||
Recent browser versions have enabled client side mitigation for the beast attack. The recommendation was to disable all TLS 1.0 ciphers and only offer RC4. However, [RC4 has a growing list of attacks against it],(http://www.isg.rhul.ac.uk/tls/) many of which have crossed the line from theoretical to practical. Moreover, there is reason to believe that the NSA has broken RC4, their so-called "big breakthrough."
|
||||
|
||||
Disabling RC4 has several ramifications. One, users with shitty browsers such as Internet Explorer on Windows XP will use 3DES in lieu. Triple-DES is more secure than RC4, but it is significantly more expensive. Your server will pay the cost for these users. Two, RC4 mitigates BEAST. Thus, disabling RC4 makes TLS 1.0 users susceptible to that attack, by moving them to AES-CBC (the usual server-side BEAST "fix" is to prioritize RC4 above all else). I am confident that the flaws in RC4 significantly outweigh the risks from BEAST. Indeed, with client-side mitigation (which Chrome and Firefox both provide), BEAST is a nonissue. But the risk from RC4 only grows: More cryptanalysis will surface over time.
|
||||
|
||||
### Factoring RSA-EXPORT Keys (FREAK) ###
|
||||
|
||||
FREAK is a man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at [INRIA, Microsoft Research and IMDEA][15]. FREAK stands for "Factoring RSA-EXPORT Keys."
|
||||
|
||||
The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits.
|
||||
|
||||
It turns out that some modern TLS clients - including Apple's SecureTransport and OpenSSL - have a bug in them. This bug causes them to accept RSA export-grade keys even when the client didn't ask for export-grade RSA. The impact of this bug can be quite nasty: it admits a 'man in the middle' attack whereby an active attacker can force down the quality of a connection, provided that the client is vulnerable and the server supports export RSA.
|
||||
|
||||
There are two parts of the attack as the server must also accept "export grade RSA."
|
||||
|
||||
The MITM attack works as follows:
|
||||
|
||||
- In the client's Hello message, it asks for a standard 'RSA' ciphersuite.
|
||||
- The MITM attacker changes this message to ask for 'export RSA'.
|
||||
- The server responds with a 512-bit export RSA key, signed with its long-term key.
|
||||
- The client accepts this weak key due to the OpenSSL/SecureTransport bug.
|
||||
- The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
|
||||
- When the client encrypts the 'pre-master secret' to the server, the attacker can now decrypt it to recover the TLS 'master secret'.
|
||||
- From here on out, the attacker sees plaintext and can inject anything it wants.
|
||||
|
||||
The ciphersuite offered here on this page does not enable EXPORT grade ciphers. Make sure your OpenSSL is updated to the latest available version and urge your clients to also use upgraded software.
|
||||
|
||||
### Heartbleed ###
|
||||
|
||||
Heartbleed is a security bug disclosed in April 2014 in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client. It results from improper input validation (due to a missing bounds check) in the implementation of the DTLS heartbeat extension (RFC6520), thus the bug's name derives from "heartbeat". The vulnerability is classified as a buffer over-read, a situation where more data can be read than should be allowed.
|
||||
|
||||
What versions of the OpenSSL are affected by Heartbleed?
|
||||
|
||||
Status of different versions:
|
||||
|
||||
- OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
|
||||
- OpenSSL 1.0.1g is NOT vulnerable
|
||||
- OpenSSL 1.0.0 branch is NOT vulnerable
|
||||
- OpenSSL 0.9.8 branch is NOT vulnerable
|
||||
|
||||
The bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.
|
||||
|
||||
By updating OpenSSL you are not vulnerable to this bug.
|
||||
|
||||
### SSL Compression (CRIME attack) ###
|
||||
|
||||
The CRIME attack uses SSL Compression to do its magic. SSL compression is turned off by default in nginx 1.1.6+/1.0.9+ (if OpenSSL 1.0.0+ used) and nginx 1.3.2+/1.2.2+ (if older versions of OpenSSL are used).
|
||||
|
||||
If you are using al earlier version of nginx or OpenSSL and your distro has not backported this option then you need to recompile OpenSSL without ZLIB support. This will disable the use of OpenSSL using the DEFLATE compression method. If you do this then you can still use regular HTML DEFLATE compression.
|
||||
|
||||
### SSLv2 and SSLv3 ###
|
||||
|
||||
SSL v2 is insecure, so we need to disable it. We also disable SSLv3, as TLS 1.0 suffers a downgrade attack, allowing an attacker to force a connection to use SSLv3 and therefore disable forward secrecy.
|
||||
|
||||
Again edit the config file:
|
||||
|
||||
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
|
||||
|
||||
### Poodle and TLS-FALLBACK-SCSV ###
|
||||
|
||||
SSLv3 allows exploiting of the [POODLE][16] bug. This is one more major reason to disable this.
|
||||
|
||||
Google have proposed an extension to SSL/TLS named [TLSFALLBACKSCSV][17] that seeks to prevent forced SSL downgrades. This is automatically enabled if you upgrade OpenSSL to the following versions:
|
||||
|
||||
- OpenSSL 1.0.1 has TLSFALLBACKSCSV in 1.0.1j and higher.
|
||||
- OpenSSL 1.0.0 has TLSFALLBACKSCSV in 1.0.0o and higher.
|
||||
- OpenSSL 0.9.8 has TLSFALLBACKSCSV in 0.9.8zc and higher.
|
||||
|
||||
[More info on the NGINX documentation][18]
|
||||
|
||||
### The Cipher Suite ###
|
||||
|
||||
Forward Secrecy ensures the integrity of a session key in the event that a long-term key is compromised. PFS accomplishes this by enforcing the derivation of a new key for each and every session.
|
||||
|
||||
This means that when the private key gets compromised it cannot be used to decrypt recorded SSL traffic.
|
||||
|
||||
The cipher suites that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. Their disadvantage is their overhead, which can be improved by using the elliptic curve variants.
|
||||
|
||||
The following two ciphersuites are recommended by me, and the latter by [the Mozilla Foundation][19].
|
||||
|
||||
The recommended cipher suite:
|
||||
|
||||
ssl_ciphers 'AES128+EECDH:AES128+EDH';
|
||||
|
||||
The recommended cipher suite for backwards compatibility (IE6/WinXP):
|
||||
|
||||
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
|
||||
|
||||
If your version of OpenSSL is old, unavailable ciphers will be discarded automatically. Always use the full ciphersuite above and let OpenSSL pick the ones it supports.
|
||||
|
||||
The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The recommendation above prioritizes algorithms that provide perfect forward secrecy.
|
||||
|
||||
Older versions of OpenSSL may not return the full list of algorithms. AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Ubuntu or RHEL.
|
||||
|
||||
#### Prioritization logic ####
|
||||
|
||||
- ECDHE+AESGCM ciphers are selected first. These are TLS 1.2 ciphers and not widely supported at the moment. No known attack currently target these ciphers.
|
||||
- PFS ciphersuites are preferred, with ECDHE first, then DHE.
|
||||
- AES 128 is preferred to AES 256. There has been [discussions][20] on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.
|
||||
- In the backward compatible ciphersuite, AES is preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present.
|
||||
- RC4 is removed entirely. 3DES is used for backward compatibility. See discussion in [#RC4_weaknesses][21]
|
||||
|
||||
#### Mandatory discards ####
|
||||
|
||||
- aNULL contains non-authenticated Diffie-Hellman key exchanges, that are subject to Man-In-The-Middle (MITM) attacks
|
||||
- eNULL contains null-encryption ciphers (cleartext)
|
||||
- EXPORT are legacy weak ciphers that were marked as exportable by US law
|
||||
- RC4 contains ciphers that use the deprecated ARCFOUR algorithm
|
||||
- DES contains ciphers that use the deprecated Data Encryption Standard
|
||||
- SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated
|
||||
- MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm
|
||||
|
||||
### Extra settings ###
|
||||
|
||||
Make sure you also add these lines:
|
||||
|
||||
ssl_prefer_server_ciphers on;
|
||||
ssl_session_cache shared:SSL:10m;
|
||||
|
||||
When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the client's preference is used. If this directive is enabled, the server's preference will be used instead.
|
||||
|
||||
- [More info on sslpreferserver_ciphers][22]
|
||||
- [More info on ssl_ciphers][23]
|
||||
|
||||
### Forward Secrecy & Diffie Hellman Ephemeral Parameters ###
|
||||
|
||||
The concept of forward secrecy is simple: client and server negotiate a key that never hits the wire, and is destroyed at the end of the session. The RSA private from the server is used to sign a Diffie-Hellman key exchange between the client and the server. The pre-master key obtained from the Diffie-Hellman handshake is then used for encryption. Since the pre-master key is specific to a connection between a client and a server, and used only for a limited amount of time, it is called Ephemeral.
|
||||
|
||||
With Forward Secrecy, if an attacker gets a hold of the server's private key, it will not be able to decrypt past communications. The private key is only used to sign the DH handshake, which does not reveal the pre-master key. Diffie-Hellman ensures that the pre-master keys never leave the client and the server, and cannot be intercepted by a MITM.
|
||||
|
||||
All versions of nginx as of 1.4.4 rely on OpenSSL for input parameters to Diffie-Hellman (DH). Unfortunately, this means that Ephemeral Diffie-Hellman (DHE) will use OpenSSL's defaults, which include a 1024-bit key for the key-exchange. Since we're using a 2048-bit certificate, DHE clients will use a weaker key-exchange than non-ephemeral DH clients.
|
||||
|
||||
We need generate a stronger DHE parameter:
|
||||
|
||||
cd /etc/ssl/certs
|
||||
openssl dhparam -out dhparam.pem 4096
|
||||
|
||||
And then tell nginx to use it for DHE key-exchange:
|
||||
|
||||
ssl_dhparam /etc/ssl/certs/dhparam.pem;
|
||||
|
||||
### OCSP Stapling ###
|
||||
|
||||
When connecting to a server, clients should verify the validity of the server certificate using either a Certificate Revocation List (CRL), or an Online Certificate Status Protocol (OCSP) record. The problem with CRL is that the lists have grown huge and takes forever to download.
|
||||
|
||||
OCSP is much more lightweight, as only one record is retrieved at a time. But the side effect is that OCSP requests must be made to a 3rd party OCSP responder when connecting to a server, which adds latency and potential failures. In fact, the OCSP responders operated by CAs are often so unreliable that browser will fail silently if no response is received in a timely manner. This reduces security, by allowing an attacker to DoS an OCSP responder to disable the validation.
|
||||
|
||||
The solution is to allow the server to send its cached OCSP record during the TLS handshake, therefore bypassing the OCSP responder. This mechanism saves a roundtrip between the client and the OCSP responder, and is called OCSP Stapling.
|
||||
|
||||
The server will send a cached OCSP response only if the client requests it, by announcing support for the status_request TLS extension in its CLIENT HELLO.
|
||||
|
||||
Most servers will cache OCSP response for up to 48 hours. At regular intervals, the server will connect to the OCSP responder of the CA to retrieve a fresh OCSP record. The location of the OCSP responder is taken from the Authority Information Access field of the signed certificate.
|
||||
|
||||
- [View my tutorial on enabling OCSP stapling on NGINX][24]
|
||||
|
||||
### HTTP Strict Transport Security ###
|
||||
|
||||
When possible, you should enable [HTTP Strict Transport Security (HSTS)][25], which instructs browsers to communicate with your site only over HTTPS.
|
||||
|
||||
- [View my article on HTST to see how to configure it.][26]
|
||||
|
||||
### HTTP Public Key Pinning Extension ###
|
||||
|
||||
You should also enable the [HTTP Public Key Pinning Extension][27].
|
||||
|
||||
Public Key Pinning means that a certificate chain must include a whitelisted public key. It ensures only whitelisted Certificate Authorities (CA) can sign certificates for `*.example.com`, and not any CA in your browser store.
|
||||
|
||||
I've written an article about it that has background theory and configuration examples for Apache, Lighttpd and NGINX: [https://raymii.org/s/articles/HTTPPublicKeyPinningExtension_HPKP.html][28]
|
||||
|
||||
### Config Example ###
|
||||
|
||||
server {
|
||||
|
||||
listen [::]:443 default_server;
|
||||
|
||||
ssl on;
|
||||
ssl_certificate_key /etc/ssl/cert/raymii_org.pem;
|
||||
ssl_certificate /etc/ssl/cert/ca-bundle.pem;
|
||||
|
||||
ssl_ciphers 'AES128+EECDH:AES128+EDH:!aNULL';
|
||||
|
||||
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
|
||||
ssl_session_cache shared:SSL:10m;
|
||||
|
||||
ssl_stapling on;
|
||||
ssl_stapling_verify on;
|
||||
resolver 8.8.4.4 8.8.8.8 valid=300s;
|
||||
resolver_timeout 10s;
|
||||
|
||||
ssl_prefer_server_ciphers on;
|
||||
ssl_dhparam /etc/ssl/certs/dhparam.pem;
|
||||
|
||||
add_header Strict-Transport-Security max-age=63072000;
|
||||
add_header X-Frame-Options DENY;
|
||||
add_header X-Content-Type-Options nosniff;
|
||||
|
||||
root /var/www/;
|
||||
index index.html index.htm;
|
||||
server_name raymii.org;
|
||||
|
||||
}
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
If you have applied the above config lines you need to restart nginx:
|
||||
|
||||
# Check the config first:
|
||||
/etc/init.d/nginx configtest
|
||||
# Then restart:
|
||||
/etc/init.d/nginx restart
|
||||
|
||||
Now use the [SSL Labs test][29] to see if you get a nice A. And, of course, have a safe, strong and future proof SSL configuration!
|
||||
|
||||
- [Also read the Mozilla page on the subject][30]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
|
||||
|
||||
作者：[Remy van Elst][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://raymii.org/
|
||||
[1]:https://www.ssllabs.com/ssltest/analyze.html?d=raymii.org
|
||||
[2]:https://cipherli.st/
|
||||
[3]:https://www.digitalocean.com/?refcode=7435ae6b8212
|
||||
[4]:http://blog.ivanristic.com/2014/01/ssl-labs-stricter-security-requirements-for-2014.html
|
||||
[5]:https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html
|
||||
[6]:https://raymii.org/s/tutorials/Pass_the_SSL_Labs_Test_on_Lighttpd_%28Mitigate_the_CRIME_and_BEAST_attack_-_Disable_SSLv2_-_Enable_PFS%29.html
|
||||
[7]:http://www.bsdnow.tv/episodes/2014_08_20-engineering_nginx
|
||||
[8]:http://www.bsdnow.tv/tutorials/nginx
|
||||
[9]:https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack
|
||||
[10]:https://en.wikipedia.org/wiki/CRIME_%28security_exploit%29
|
||||
[11]:http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
|
||||
[12]:http://heartbleed.com/
|
||||
[13]:https://en.wikipedia.org/wiki/Perfect_forward_secrecy
|
||||
[14]:https://en.wikipedia.org/wiki/Transport_Layer_Security#Dealing_with_RC4_and_BEAST
|
||||
[15]:https://www.smacktls.com/
|
||||
[16]:https://raymii.org/s/articles/Check_servers_for_the_Poodle_bug.html
|
||||
[17]:https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
|
||||
[18]:http://wiki.nginx.org/HttpSslModule#ssl_protocols
|
||||
[19]:https://wiki.mozilla.org/Security/Server_Side_TLS
|
||||
[20]:http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html
|
||||
[21]:https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses
|
||||
[22]:http://wiki.nginx.org/HttpSslModule#ssl_prefer_server_ciphers
|
||||
[23]:http://wiki.nginx.org/HttpSslModule#ssl_ciphers
|
||||
[24]:https://raymii.org/s/tutorials/OCSP_Stapling_on_nginx.html
|
||||
[25]:https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
|
||||
[26]:https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html
|
||||
[27]:https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning
|
||||
[28]:https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html
|
||||
[29]:https://www.ssllabs.com/ssltest/
|
||||
[30]:https://wiki.mozilla.org/Security/Server_Side_TLS
|
||||
@ -0,0 +1,75 @@
|
||||
Linux内核4.0功能 实时内核补丁，支持PS3
|
||||
================================================================================
|
||||
|
||||
|
||||
**Linux Torvalds 在Linux内核邮件列表里[发布][1]了Linux内核新的稳定版。**
|
||||
|
||||
Linux 4.0，代号为‘Hurr durr I’m a sheep’ - 不，真的 - 带来了一小系列新的硬件支持，驱动改进，性能调整，错误修复等。
|
||||
|
||||
但对于微小更新的标注，Torvalds 写到：
|
||||
|
||||
>功能方面，4.0 并没有那么多特别的。虽然在内核补丁设施上做了很多工作，但事实上[...] 我们在其它版本中有更大的改变。所以这仅仅是一次“可靠代码进步”的发布。
|
||||
|
||||
Linus 补充说Linux 4.1 可能是一个“大版本”。
|
||||
|
||||
### Linux内核4.0新功能 ###
|
||||
|
||||
无需重启安装内核更新
|
||||
|
||||
你肯定曾今因为要重启你的Linux系统以完成内核更新而被打断工作，这并不是你一个人遇到的问题。这对于桌面操作系统来说是个小小的不方便，对于服务器来说却是大问题。
|
||||
|
||||
|
||||
内核更新无需重启
|
||||
|
||||
实时给Linux内核安装/使用安全补丁而不需要重启，多年来一直是Linux爱好者希望实现的事情。
|
||||
|
||||
一些第三方项目，例如[Oracle 的 KSplice][2]和红帽的Kpatch，力求为一些特定的发行版提供实时补丁的功能。
|
||||
|
||||
对于服务器，企业单位以及关键任务正常运行，实现实时内核补丁是一个相当大的问题。
|
||||
|
||||
好消息是Linux 4.0 使得重启系统以完成内核更新成为了过去。
|
||||
|
||||
或者，几乎。
|
||||
|
||||
在最新的发行版中，实现了支持免重启安装补丁的最初基础，随时为有经验的系统管理员利用Linux4.0的优势做好了准备。
|
||||
|
||||
桌面Linux发行版也应该能够利用这个功能的优势(但考虑到在最终用户端配置免重启功能会比较复杂而有一些路要走)。
|
||||
|
||||
在以后的4.x系列中，这个基础功能会持续完善和改进。我希望我们能更多听到它正是如此的信息。
|
||||
|
||||
#### 其它改进 ####
|
||||
|
||||
尽管被认为是一次小版本的发布，最新的Linux内核还是带来了一系列的硬件改进，新的驱动以及性能调整。
|
||||
它们包括：
|
||||
|
||||
|
||||
- 针对Intel ‘Skylake’ 平台的改进
|
||||
- 支持Intel Quark SoC
|
||||
- 改善Linux在Playstation 3上运行的系列补丁
|
||||
- TOpen-source AMD Radeon驱动支持DisplayPort音频
|
||||
- 各种HID驱动调整，包括Lenovo紧凑型键盘，Wacom Cintiq 27QHD
|
||||
- 东芝电源设置驱动器增加了USB睡眠/充电功能，快速充电，睡眠/音乐等
|
||||
- 文件系统调整，包括F2FS, BtrfFS等
|
||||
|
||||
### 在Ubuntu上安装Linux内核4.0 ###
|
||||
|
||||
尽管被归为稳定版本，目前而言，**桌面用户和新用户没有必要去升级**。
|
||||
|
||||
通过从[Canonical的主线内核文档][3]抓取合适的安装包或者冒第三方PPA库的风险在Ubuntu 15.04测试版安装Linux4.0，急躁或者不娴熟可能会带来问题。
|
||||
|
||||
Ubuntu 15.04 Vivid Vervet 将在本月晚些时候发布并会附带Ubuntu内核 3.19(Ubuntu内核是由Linux内核以及一些上游还没有接受的特定Ubuntu补丁组成)。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.omgubuntu.co.uk/2015/04/linux-kernel-4-0-new-features
|
||||
|
||||
作者：[Joey-Elijah Sneddon][a]
|
||||
译者：[ictlyh](https://github.com/ictlyh)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://plus.google.com/117485690627814051450/?rel=author
|
||||
[1]:https://lkml.org/lkml/2015/4/12/178
|
||||
[2]:http://www.omgubuntu.co.uk/2009/10/how-to-install-kernel-updates-without-rebooting
|
||||
[3]:http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
|
||||
@ -1,67 +1,66 @@
|
||||
[boredivan翻译中]
|
||||
How To Scan And Check A WordPress Website Security Using WPScan, Nmap, And Nikto
|
||||
怎样用 WPScan，Nmap 和 Nikto 扫描和检查一个 WordPress 站点的安全性
|
||||
================================================================================
|
||||
### Introduction ###
|
||||
### 介绍 ###
|
||||
|
||||
Millions of websites are powered by WordPress software and there’s a reason for that. WordPress is the most developer-friendly content management system out there, so you can essentially do anything you want with it. Unfortunately, every day some scary report about a major site being hacked or a sensitive database being compromised hits the web … and freaks everyone out.
|
||||
数百万个网站用着 WordPress ，这当然是有原因的。WordPress 是众多内容管理系统中对开发者最友好的，本质上说你可以用它做任何事情。不幸的是，每天都有些吓人的报告说某个主要的网站被黑了，或者某个重要的数据库被泄露了之类的，吓得人一愣一愣的。
|
||||
|
||||
If you haven’t installed WordPress yet, check the following article.
|
||||
On Debian based systems:
|
||||
如果你还没有安装 WordPress ，可以看下下面的文章。
|
||||
在基于 Debian 的系统上：
|
||||
|
||||
- [How to install WordPress On Ubuntu][1]
|
||||
|
||||
On RPM based systems:
|
||||
在基于 RPM 的系统上：
|
||||
|
||||
- [How to install wordpress On CentOS][2]
|
||||
|
||||
Following on from my previous article [How To Secure WordPress Website][3] show you **checklist** allows you to secure your WordPress site with as little effort as possible.
|
||||
我之前的文章 [How To Secure WordPress Website][3] 里面列出的**备忘录**为读者维护 WordPress 的安全提供了一点帮助。
|
||||
|
||||
In this article, will describe to you through the installation of **wpscan** and serve as a guide on how to use wpscan to locate any known vulnerable plugins and themes that may make your site vulnerable to attack. Also, how to install and use **nmap** the free Security Scanner For Network Exploration & Hacking . And at the end we will show you the steps to use **nikto**.
|
||||
在这篇文章里面，我将说明 **wpscan** 的安装过程，以及怎样使用 wpscan 来锁定任何已知的会让你的站点变得易受攻击的插件和主题。还有怎样安装和使用一款免费的网络探索和攻击的安全扫描软件 **nmap** 。最后展示的是使用 **nikto** 的步骤。
|
||||
|
||||
### WPScan to Test for Vulnerable Plugins and Themes in WordPress ###
|
||||
### 用 WPScan 测试 WordPress 中易受攻击的插件和主题 ###
|
||||
|
||||
**WPScan** is a black box WordPress Security Scanner written in Ruby which attempts to find known security weaknesses within WordPress installations. Its intended use it to be for security professionals or WordPress administrators to asses the security posture of their WordPress installations. The code base is Open Source and licensed under the GPLv3.
|
||||
**WPScan** 是一个 WordPress 黑盒安全扫描软件，用 Ruby 写成，它是专门用来寻找已知的 WordPress 的弱点的。它为安全专家和 WordPress 管理员提供了一条评估他们的 WordPress 站点的途径。它的基于开源代码，在 GPLv3 下发行。
|
||||
|
||||
### Download and Install WPScan ###
|
||||
### 下载和安装 WPScan ###
|
||||
|
||||
Before we get started with the installation, it is important to note that wpscan will not work on Windows systems, so you will need access to a Linux or OSX installation to proceed. If you only have access to a Windows system you can download Virtualbox and install any Linux distro you like as a Virtual Machine.
|
||||
在我们开始安装之前，很重要的一点是要注意 wpscan 不能在 Windows 下工作，所以你需要使用一台 Linux 或者 OS X 的机器来完成下面的事情。如果你只有 Windows 的系统，拿你可以下载一个 Virtualbox 然后在虚拟机里面安装任何你喜欢的 Linux 发行版本。
|
||||
|
||||
WPScan is hosted on Github, so if it is not already installed we will need to install the git packages before we can continue.
|
||||
WPScan 的源代码被放在 Github 上，所以需要先安装 git。
|
||||
|
||||
sudo apt-get install git
|
||||
|
||||
Once git is installed, we need to install the dependencies for wpscan.
|
||||
git 装好了，我们就要安装 wpscan 的依赖包了。
|
||||
|
||||
sudo apt-get install libcurl4-gnutls-dev libopenssl-ruby libxml2 libxml2-dev libxslt1-dev ruby-dev ruby1.9.3
|
||||
|
||||
Now we need to clone the wpscan package from github.
|
||||
把 wpscan 从 github 上 clone 下来。
|
||||
|
||||
git clone https://github.com/wpscanteam/wpscan.git
|
||||
|
||||
Now we can move to the newly created wpscan directory and install the necessary ruby gems through bundler.
|
||||
现在我们可以进入这个新建立的 wpscan 目录，通过 bundler 安装必要的 ruby 包。
|
||||
|
||||
cd wpscan
|
||||
sudo gem install bundler && bundle install --without test development
|
||||
|
||||
Now that we have wpscan installed, we will walk through using the tool to search for potentially vulnerable files on our WordPress installation. Some of the most important aspects of wpscan are its ability to enumerate not only plugins and themes, but users and timthumb installations as well. WPScan can also perform bruteforce attacks against WordPress– but that is outside of the scope of this article.
|
||||
现在 wpscan 装好了，我们就可以用它来搜索我们 WordPress 站点潜在的易受攻击的文件。wpcan 最重要的方面是它能列出不仅是插件和主题，也能列出用户和缩略图的功能。WPScan 也可以用来暴力破解 WordPress —— 但这不是本文要讨论的内容。
|
||||
|
||||
#### Update wpscan ####
|
||||
#### 跟新 WPScan ####
|
||||
|
||||
ruby wpscan.rb --update
|
||||
|
||||
#### Enumerate Plugins ####
|
||||
#### 列举插件 ####
|
||||
|
||||
To enumerate plugins, all we need to do is launch wpscan with the `--enumerate p` arguments like so.
|
||||
要列出所有插件，只需要加上 “--enumerate p” 参数，就像这样：
|
||||
|
||||
ruby wpscan.rb --url http(s)://www.yoursiteurl.com --enumerate p
|
||||
|
||||
or to only display vulnerable plugins:
|
||||
或者仅仅列出易受攻击的插件：
|
||||
|
||||
ruby wpscan.rb --url http(s)://www.yoursiteurl.com --enumerate vp
|
||||
|
||||
Some example output is posted below:
|
||||
下面是一些例子：
|
||||
|
||||
| Name: akismet
|
||||
| Name: ukiscet
|
||||
| Location: http://********.com/wp-content/plugins/akismet/
|
||||
|
||||
| Name: audio-player
|
||||
@ -92,17 +91,18 @@ Some example output is posted below:
|
||||
| Name: contact
|
||||
| Location: http://********.com/wp-content/plugins/contact/
|
||||
|
||||
#### Enumerate Themes ####
|
||||
#### 列举主题 ####
|
||||
|
||||
列举主题和列举插件差不多，只要用"--enumerate t"就可以了。
|
||||
|
||||
Enumeration of themes works the same as enumeration of plugins, just with the `--enumerate t` argument.
|
||||
|
||||
ruby wpscan.rb --url http(s)://www.host-name.com --enumerate t
|
||||
|
||||
Or to only display vulnerable themes:
|
||||
或者只列出易受攻击的主题：
|
||||
|
||||
ruby wpscan.rb --url http(s)://www.host-name.com --enumerate vt
|
||||
|
||||
Sample output:
|
||||
例子的输出：
|
||||
|
||||
| Name: path
|
||||
| Location: http://********.com/wp-content/themes/path/
|
||||
@ -127,29 +127,30 @@ Sample output:
|
||||
| Style URL: http://********.com/wp-content/themes/twentyten/style.css
|
||||
| Description:
|
||||
|
||||
#### Enumerate Users ####
|
||||
#### 列举用户 ####
|
||||
|
||||
WPScan can also be used to enumerate users with valid logins to the WordPress installation. This is usually performed by attackers in order to get a list of users in preparation for a bruteforce attack.
|
||||
WPscan 也可以用来列举某个 WordPress 站点的用户和有效的登录记录。攻击者常常这么做——为了获得一个用户清单，好进行暴力破解。
|
||||
|
||||
ruby wpscan.rb --url http(s)://www.host-name.com --enumerate u
|
||||
|
||||
#### Enumerate Timthumb Files ####
|
||||
#### 列举 Timthumb 文件 ####
|
||||
|
||||
The last function of wpscan we’ll discuss in this article is the ability to enumerate timthumb installations. In recent years, timthumb has become a very common target of attackers due to the numerous vulnerabilities found and posted to online forums, message lists, and advisory boards. Using wpscan to find vulnerable timthumb files is done with the following command.
|
||||
关于 WPscan ，我要说的最后一个功能是列举 timthub 相关的文件。近年来，timthumb 已经成为攻击者眼里的一个普通的目标，因为无数的漏洞被找出来并发到论坛上、邮件列表等等地方。用下面的命令可以通过 wpscan 找出易受攻击的 timthub 文件：
|
||||
|
||||
ruby wpscan.rb --url http(s)://www.host-name.com --enumerate tt
|
||||
|
||||
### Nmap to Scan for Open Ports on your VPS ###
|
||||
### 用 Nmap 扫描你 VPS 的开放端口 ###
|
||||
|
||||
**Nmap** is an open source tool for network exploration and security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics
|
||||
**Nmap** 是一个开源的用于网络探索和安全审查方面的工具。它可以迅速扫描巨大的网络，也可一单机使用。Nmap 用原始 IP 数据包通过不同寻常的方法判断网络里那些主机是正在工作的，那些主机上都提供了什么服务（应用名称和版本），是什么操作系统（以及版本），用的什么类型的防火墙，以及很多其他特征。
|
||||
|
||||
### Download and install nmap on Debian and Ubuntu ###
|
||||
### 在 Debian 和 Ubuntu 上下载和安装 nmap ###
|
||||
|
||||
要在基于 Debian 和 Ubuntu 的操作系统上安装 nmap ，运行下面的命令：
|
||||
|
||||
To install nmap for Debian and Ubuntu Linux based server systems type the following apt-get command:
|
||||
|
||||
sudo apt-get install nmap
|
||||
|
||||
**Sample outputs:**
|
||||
**输出样例**
|
||||
|
||||
Reading package lists... Done
|
||||
Building dependency tree
|
||||
@ -167,27 +168,27 @@ To install nmap for Debian and Ubuntu Linux based server systems type the follow
|
||||
Processing triggers for man-db ...
|
||||
Setting up nmap (5.21-1.1ubuntu1) ...
|
||||
|
||||
#### Examples ####
|
||||
#### 打个例子 ####
|
||||
|
||||
To find the nmap version, enter:
|
||||
输出 nmap 的版本：
|
||||
|
||||
nmap -V
|
||||
|
||||
OR
|
||||
或者
|
||||
|
||||
nmap --version
|
||||
|
||||
**Sample outputs:**
|
||||
**输出样例**
|
||||
|
||||
Nmap version 5.21 ( http://nmap.org )
|
||||
|
||||
### Dowonlad and install nmap on Centos ###
|
||||
### 在 Centos 上下载和安装 nmap ###
|
||||
|
||||
To install nmap on RHEL based Linux distributions, type the following yum command:
|
||||
要在基于 RHEL 的 Linux 上面安装 nmap ，输入下面的命令：
|
||||
|
||||
yum install nmap
|
||||
|
||||
**Sample outputs:**
|
||||
**输出样例**
|
||||
|
||||
Loaded plugins: protectbase, rhnplugin, security
|
||||
0 packages excluded due to repository protections
|
||||
@ -226,63 +227,63 @@ To install nmap on RHEL based Linux distributions, type the following yum comman
|
||||
|
||||
Complete!
|
||||
|
||||
#### Examples ####
|
||||
#### 举个比方 ####
|
||||
|
||||
To find the nmap version, enter:
|
||||
输出 nmap 版本号：
|
||||
|
||||
nmap --version
|
||||
|
||||
**Sample outputs:**
|
||||
**输出样例**
|
||||
|
||||
Nmap version 5.51 ( http://nmap.org )
|
||||
|
||||
#### Scan Ports with Nmap ####
|
||||
#### 用 Nmap 扫描端口 ####
|
||||
|
||||
You can got a lot of information about your server or host using nmap and it let you to think like someone has malicious intent.
|
||||
你可以用 nmap 来获得很多关于你的服务器的信息，它让你站在对你的网站不怀好意的人的角度看你自己的网站。
|
||||
|
||||
For this reason, only test it on servers that you own or in situations where you’ve notified the owners.
|
||||
因此，请仅用它测试你自己的服务器或者在行动之前通知服务器的所有者。
|
||||
|
||||
The nmap creators actually provide a test server located at:
|
||||
nmap 的作者提供了一个测试服务器：
|
||||
|
||||
scanme.nmap.org
|
||||
|
||||
Some commands may take a long while to complete:
|
||||
有些命令可能会耗时较长：
|
||||
|
||||
To scan an IP address or a host name (FQDN), run:
|
||||
要扫描一个 IP 地址或者一个主机名（全称域名），运行：
|
||||
|
||||
nmap 192.168.1.1
|
||||
|
||||
Sample outputs:
|
||||
输出样例：
|
||||
|
||||
|
||||
|
||||
Scan for the host operating system:
|
||||
扫描以获得主机的操作系统：
|
||||
|
||||
sudo nmap -O 192.168.1.1
|
||||
|
||||
pecify a range with “-” or “/24″ to scan a number of hosts at once:
|
||||
加上“-”或者“/24”来一次性扫描某个范围里面的多个主机：
|
||||
|
||||
sudo nmap -PN xxx.xxx.xxx.xxx-yyy
|
||||
|
||||
Scan a network range for available services:
|
||||
扫描某个范围内可用的服务：
|
||||
|
||||
sudo nmap -sP network_address_range
|
||||
|
||||
Scan without preforming a reverse DNS lookup on the IP address specified. This should speed up your results in most cases:
|
||||
扫描 IP 地址时部进行反向 DNS 解析。多数情况下这会加快你获得结果的速度：
|
||||
|
||||
sudo nmap -n remote_host
|
||||
|
||||
Scan a specific port instead of all common ports:
|
||||
扫描一个特定端口而不是所有常用端口：
|
||||
|
||||
sudo nmap -p port_number remote_host
|
||||
|
||||
Scan a network and find out which servers and devices are up and running
|
||||
扫描一个网络，找出那些服务器在线，分别运行了什么服务
|
||||
|
||||
This is known as host discovery or ping scan:
|
||||
这就是传说中的主机探索或者 ping 扫描：
|
||||
|
||||
nmap -sP 192.168.1.0/24
|
||||
|
||||
Sample outputs:
|
||||
输出样例：
|
||||
|
||||
Host 192.168.1.1 is up (0.00035s latency).
|
||||
MAC Address: BC:AE:C5:C3:16:93 (Unknown)
|
||||
@ -293,25 +294,25 @@ Sample outputs:
|
||||
MAC Address: 00:11:32:11:15:FC (Synology Incorporated)
|
||||
Nmap done: 256 IP addresses (4 hosts up) scanned in 2.80 second
|
||||
|
||||
Understanding port configuration and how to discover what the attack vectors are on your server is only one step to securing your information and your VPS.
|
||||
理解端口配置和如何发现你的服务器上的攻击的载体只是确保你的信息和你的 VPS 安全的第一步。
|
||||
|
||||
### Nikto to Scan for vulnerabilities in your website ###
|
||||
### 用 Nikto 扫描你网站的缺陷 ###
|
||||
|
||||
[Nikto][4] Web-scanner is a open source web-server scanner which can be used to scan the web-servers for malicious programs and files. Nikto can be used to scan the outdated versions of programs too. Nikto will provide us a quick and easy scan to find out the dangerous files and programs in server, At the end of scan result with a log file.
|
||||
[Nikto][4] 网络扫描器是一个开源的 web 服务器的扫描软件，它可以用来扫描 web 服务器上的恶意的程序和文件。Nikto 也可一用来检查软件版本是否过期。Nikto 能进行简单而快速地扫描以发现服务器上危险的文件和程序。扫描结束后会给出一个日志文件。`
|
||||
|
||||
### Download and install Nikto on Linux server ###
|
||||
### 在 Linux 服务器上下载和安装 Nikto ###
|
||||
|
||||
Perl is pre-installed in linux so all you need to do is download nikto from the [project page][5], unpack it into a directory and start your testing.
|
||||
Perl 在 Linux 上是预先安装好的，所以你只需要从[项目页面][5]下载 nikto ，解压到一个目录里面，然后开始测试。
|
||||
|
||||
wget https://cirt.net/nikto/nikto-2.1.4.tar.gz
|
||||
|
||||
You can unpack it with an archive manager tool or use tar and gzip together with this command.
|
||||
你可以用某个归档管理工具或者用下面这个命令，同时使用 tar 和 gzip 。
|
||||
|
||||
tar zxvf nikto-2.1.4.tar.gz
|
||||
cd nikto-2.1.4
|
||||
perl nikto.pl
|
||||
|
||||
This should be your results from a working installation:
|
||||
安装正确的话会得到这样的结果：
|
||||
|
||||
- ***** SSL support not available (see docs for SSL install) *****
|
||||
- Nikto v2.1.4
|
||||
@ -348,27 +349,27 @@ This should be your results from a working installation:
|
||||
|
||||
Note: This is the short help output. Use -H for full help.
|
||||
|
||||
The error is merely telling us we did not fill in the necessary parameters for a test to run. The SSL support can be enabled by installing the necessary perl ssl module (sudo apt-get install libnet-ssleay-perl).
|
||||
这个报错只是告诉我们没有给出必要的参数。SSL 支持可以通过安装相关的 perl ssl 模块得到（sudo apt-get install libnet-ssleay-perl）。
|
||||
|
||||
#### Update the nikto Database ####
|
||||
#### 更新 nikto 数据库 ####
|
||||
|
||||
Before performing any scan we need to update the nikto database packages using.
|
||||
在开始使用之前我们需要先更新 nikto 数据库：
|
||||
|
||||
/usr/local/bin/nikto.pl -update
|
||||
|
||||
To list the available Plugins for nikto we can use the below command.
|
||||
下面的命令可以列出可用的 nikto 插件。
|
||||
|
||||
nikto.pl -list-plugins // To list the installed plugins //
|
||||
|
||||
#### Scan for vulnerabilities ####
|
||||
#### 扫描以寻找缺陷 ####
|
||||
|
||||
For a simple test for we will use test a single url.
|
||||
我们用一个 url 来在做个简单的测试。
|
||||
|
||||
perl nikto.pl -h http://www.host-name.com
|
||||
|
||||
**Sample outputs:**
|
||||
**输出样例**
|
||||
|
||||
This will produce fairly verbose output that may be somewhat confusing at first. Take the time to read through the output to understand what each advisory means. Many of the alerts in Nikto will refer to OSVDB numbers. These are Open Source Vulnerability Database ([http://osvdb.org/][6]) designations. You can search on OSVDB for further information about any vulnerabilities identified.
|
||||
会有十分冗长的输出，可能一开始会让人感到困惑。许多 Nikto 的警报会返回 OSVDB 序号。这是开源缺陷数据库（[http://osvdb.org/][6]）的意思。你可以在 OSVDB 上找出相关缺陷的深入说明。
|
||||
|
||||
$ nikto -h http://www.host-name.com
|
||||
- Nikto v2.1.4
|
||||
@ -399,18 +400,18 @@ This will produce fairly verbose output that may be somewhat confusing at first.
|
||||
+ 1 host(s) tested
|
||||
$
|
||||
|
||||
**Nikto** is an extremely lightweight, and versatile tool. Because of the fact that Nikto is written in Perl it can be run on almost any host operating system.
|
||||
**Nikto** 是一个非常轻量级的通用工具。因为 Nikto 是用 Perl 写的，所以它可以在几乎任何服务器的操作系统上运行。
|
||||
|
||||
Hope this will will bring you a good idea to scan vulnerbalites for your wordpress website. Following on from my previous article [How To Secure WordPress Website][7] show you **checklist** allows you to secure your WordPress site with as little effort as possible.
|
||||
希望这篇文章能在你找你的 wordpress 站点的缺陷的时候给你一些提示。我之前的文章[怎样保护 WordPress 站点][7]记录了一个**清单**，可以让你保护你的 WordPress 站点的工作变得更简单。
|
||||
|
||||
If you have any feedback or comments, feel free to post them in the comment section below.
|
||||
有想说的，留下你的评论。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.unixmen.com/scan-check-wordpress-website-security-using-wpscan-nmap-nikto/
|
||||
|
||||
作者：[anismaj][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
译者：[boredivan](https://github.com/boredivan)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
Loading…
Reference in New Issue
Block a user