Configure the https server for nginx and prevent attacks

Service Denial-of-service attacks are divided into two stages: Recognition and Control.

Controls include bans, isolation, and restrictions.Blocking means that access is not allowed at all. Isolation means that abnormal traffic is isolated to the sandbox environment and limited server resources are provided. The restriction is similar to the above limit_req function, that is, providing quantitative service resources. I tend to block and isolate them.

Bans can be based on rules and models.As we want to discover a large amount of abnormal traffic, rather than some exception points, we personally feel that the ban rules are more appropriate.

In the ban rules, any http header variable can be set to key (generally ip address or special cookie value) to check the Access frequency in the M Time Window. If the Access frequency limit is reached, the N-time block will be disabled and will be automatically unblocked upon expiration. I personally feel that using Lua + redis is a simple and feasible method. For a request:

• Calculate the remaining seconds in the current time window
• Use the specified http header variable as the key and add the redis counter. The remaining time of the preceding step is the timeout time.
• Check the redis counter. If the frequency limit is reached, 403 forbid

The entire nginx cluster uses a unified redis server and can use keys for hash grouping to support performance expansion.

To cope with the following attacks:

• Frequent access from a single IP Address: The key is binary_remote_addr, and access from this IP address is limited.
• Frequent access from a single IP Address: The key is binary_remote_addr + user agent, and access from the same IP address UA is restricted.
• The same URL for DDOS attacks: the key is refer + request_uri.
• Machine traffic: Use the userid in the cookie after logon as the key to limit frequent access to the same userid
• Server traffic: The userid + UserAgent + remote_Ip in the cookie after logon is used as the key to restrict frequent access from the same userid, UA, and IP address.

In addition, you can restrict unauthorized user access. If the cookie does not match, you cannot access the visible URL of logon. Although this will introduce the application layer logic, in the case of attacks, it can reduce the pressure on the application layer server.

IsolationIs to group servers to achieve physical separation. It can be split by ip address, or by the special values in cookies (when the cookie is null needs to be processed), or even by url, or frequently accessed traffic is isolated, let them compete on their own.

Recognition Methods include real-time and non-real-time.The above Lua implementation scheme adopts real-time identification. It can be used to identify attacks that have occurred in history or have established rules in real time. But it is inevitable to encounter new types of attacks, which requires non-real-time identification and quick feedback to the ban Policy (for fast feedback, I also want to use Lua for blocking ).

Log Analysis is a kind of non-real-time identification method that can compare normal and abnormal traffic in multiple dimensions, in the form of reports/charts, and semi-automated detection of abnormal traffic and traffic characteristics. Compared with real-time recognition, this method can add more types of monitoring.

For example, under normal circumstances, the access to a url is 100/s. If the access to a url suddenly increases to 800/s at a certain time point, it may be an exception, you need to split this part of traffic, view IP/refer/cookie, and find the appropriate features. Once you determine that the block is required, you can quickly organize the Lua script and add it to nginx.

------------

Generate Certificate

1. Create a CA certificate:

Ca. key CA private key, where Enter pass phrase for ca. key must be 4 to 8191 characters in length. The ca. key file is generated. Here 123456 is used:

$ Openssl genrsa-des3-out ca. key 2048

The generated ca. key file is in the following format:

-- Begin rsa private key --
Proc-Type: 4, ENCRYPTED
DEK-Info: DES-EDE3-CBC, 3F630DA2B00F0C16

BJeth9Fw + leyqpnd9hgk2pzy7rmylhwan9m21_3ou2xeebdxo9zlmw5hn/jAvMk7

......

Mdp + 9KWmLOx6wlO4yQaNh8x8hFvPEKjnGQQLXv691prRRvzHRmvZVA =
-- End rsa private key --

Ca. crt CA root certificate (Public Key), you need to enter the pass phrase from the previous step, and enter the Region, company, name, and other information:

$ Openssl req-new-x509-days 7305-key ca. key-out ca. crt

The generated ca. crt file is in the following format:

-- Begin certificate --
MIIEbTCCA1WgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBhTELMAkGA1UEBhMCQ04x

......

OIjcL41W4PddlVuwdXSK5FG1tmEmH + 70OZ0TjwWeCGvz
-- End certificate --

2. Create a certificate for the website and use the CA signature for authentication.

Assume that the website name is test.flykobe.com and the generated pem file name is test.flykobe.com. pem. During this period, Enter pass phrase for test.flykobe.com. pem, and 123456 is used here.

$ Openssl genrsa-des3-out test.flykobe.com. pem 1024

The format of the generated test.flykobe.com. pem file is:

-- Begin rsa private key --
Proc-Type: 4, ENCRYPTED
DEK-Info: DES-EDE3-CBC, 929238294D9113A7

ZEjMq/queue

......

-- End rsa private key --

During the private key of the decrypted test.flykobe.com certificate, enter the pass phrase in the previous step:

$ Openssl rsa-in test.flykobe.com. pem-out test.flykobe.com. key

The format of the generated test.flykobe.com. key file is:

-- Begin rsa private key --

MIICXAIBAAKBgQCzZNnCXHrT2O/snBw/qk0uURfDhlrYtq7ORSsWz9n3KYlDOmbB

......

Su37j0ywmyhzu7eufuji fsgkqn8ihrtndrc lajywbzvcq =
-- End rsa private key --

To generate a signature request, you must enter the pass phrase of the previous stage and enter information such as the region.

Note:: Fill in the common name field with the website domain name, such as test.flykobe.com. You can also use a wildcard domain name such as * .flykobe.com to generate a website Certificate available for all second-level domain names.

$ Openssl req-new-key test.flykobe.com. pem-out test.flykobe.com. csr

The format of the generated test.flykobe.com. csr file is:

-- Begin certificate request --
MIIB3TCCAUYCAQAwgYUxCzAJBgNVBAYTAkNOMRAwDgYDVQQIEwdCZWlqaW5nMRAw

......

Lg =
-- End certificate request --

Use CA for signature. The configuration file/usr/share/ssl/openssl is used by default. cnf. The default dir configuration path for CA_default is. /demoCA, You need to cp the demoCA directory to the current path from the openssl path:

$ Cp/home/work/local/openssl/ssl/misc/demoCA.-rf

$ Openssl ca-policy policy_anything-days 1460-cert ca. crt-keyfile ca. key-in test.flykobe.com. csr-out test.flykobe.com. crt

The generated test.flykobe.com. crt file contains the Certificate information and the CERTIFICATE string.

If you do not merge crt files, Some browsers may not. :

$ Cat ca. crt> test.flykobe.com. crt

The final file required is: test.flykobe.com. key test.flykobe.com. crt

Configure nginx Server

server {    listen              443;    server_name         test.flykobe.com;    ssl                 on;    ssl_certificate     /path/to/test.flykobe.com.crt;    ssl_certificate_key /path/to/test.flykobe.com.key;

    ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;    ssl_ciphers         HIGH:!aNULL:!MD5;    ...}

Some browsers may not accept this personally generated certificate, available for curl testing, on the local machine: curl "https://test.flykobe.com: 443/"-- cacert/home/work/local/nginx/sslbycy/ca. crt

IP address blocking Attempt

Nginx's limit_req, limit_connect, limit_access, and other blocking modules can also implement custom blocking policies using lua. Here we test the https ban:

    server {        listen 443;        server_name  test.flykobe.com;        ssl on;        ssl_certificate /home/work/local/nginx/sslbycy/test.flykobe.com.crt;        ssl_certificate_key /home/work/local/nginx/sslbycy/test.flykobe.com.key;        location / {            default_type text/html;            content_by_lua '                if (ngx.var.remote_addr == "172.22.178.21") then                    ngx.say("Denied!")                else                    ngx.say("hello, world")                end                ';        }    }

HttpAccessModule is the official module. It is simple to implement deny and allow Based on ip. You can combine the error_page 403 command to customize the rewrite url after deny.

HttpLimitReqModule is the official module that can limit the access Frequency Based on http header variables. The specific restrictions are as follows:

The directive specifies the zone (Zone) And the maximum possible bursts of requests (burst ). if the rate exceeds the demands outlined in the zone, the request is delayed, so that queries are processed at a given speed. excess requests are delayed while their number does not exceed a specified number of bursts. if the number of waiting requests exceed burst, the request is completed with the code 503 "Service Temporarily Unavailable ". by default, the burst is zero.

That is, you can specify the maximum access frequency, for example, 10r/s (10 request/seconds). Once this frequency is exceeded, subsequent requests will be delay. The maximum number of delay queues is burst. If the number of requests exceeds this limit, the system will directly respond to the 503 request.

HttpLimitZoneModule is the official module that can limit the number of concurrent connections based on the http header variable. For requests that exceed the number of concurrent requests, the response is 503. This module is no longer maintained: Deprecated in 1.1.8, use Limit Conn Instead.

HttpLimitConnModule is the official module, which is similar to HttpLimitZoneModule.

Encrypted-session-nginx-module is a third-party module that is not directly used for attack prevention. However, as an encryption and decryption module, it can be used to set cookie values.

Nginx_limit_access_module is a third-party module, which is still in beta stage. From readme, It is a blocking module and can be obtained based on ip addresses and other Nginx variables (any of the variable in Nginx) block, including a POST interface for maintaining the blocking policy, but not for attack feature recognition.

Modsecurity is a third-party module that supports multiple web servers, such as apache, IIS, and Nginx. Its nginx version is still in beta stage. It consists of Trustwave SpiderLabs Research, Microsoft Security Research Center (MSRC ), yandex and community members development. (Some book resources are listed on the document page at http://www.modsecurity.org/documentation/. if there is a small amount of fees .) The specific functions are to be learned.

Naxsi is a third-party module used to prevent Xss & SQL Injection.

Xss-nginx-module is a third-party module and Native cross-site scripting support in nginx.

---------------

Supplement does not rely on ngx_openresty package, install the official nginx1.2.6:

Install lua: (if you install luajit, you do not need to install it)
Cd/home/chengy/src/nginx-1.2.6/3rd/lua-5.1.5
Make install INSTALL_TOP =/home/work/local/lua

Install luaJIT:
Make install PREFIX =/home/work/local/luajit CC =/home/work/local/gcc4/bin/gcc
Ln-sf luajit-2.0.0-beta10/home/work/local/luajit/bin/luajit

Install lua-resty-memcached on which lua depends: (this is the lib library on which lua depends, which is introduced by the lua_package_path and require commands in lua code)

Make install PREFIX =/home/work/local/lua-resty-memcached

Nginx:
Export LUAJIT_LIB =/home/work/local/luajit/lib
Export LUAJIT_INC =/home/work/local/luajit/include/luajit-2.0
. /Configure-prefix =/home/work/local/nginx1.2.6-with-http_ssl_module-add-module =. /3rd/lua-nginx-module-0.6.10-add-module =. /3rd/ngx_devel_kit-0.2.17/-add-module =. /3rd/echo-nginx-module-0.41/-with-pcre =/home/chengy/src/pcre-8.32-with-cc =/home/work/local/gcc4/bin/gcc
Make
Make install

Added/home/work/local/luajit/lib/in vim/etc/ld. so. conf/
Sudo vim/etc/ld. so. conf

 

Refer:

http://nginx.org/cn/docs/http/configuring_https_servers.html

http://www.bkjia.com/Article/201305/207363.html