CentOS 上 Nginx 安装 modSecurity 模块

Web应用防火墙 WAF

Web应用防护系统（Web Application Firewall, 简称：WAF）代表了一类新兴的信息安全技术，用以解决诸如防火墙一类传统设备束手无策的Web应用安全问题。与传统防火墙不同，WAF工作在应用层，因此对Web应用防护具有先天的技术优势。基于对Web应用业务和逻辑的深刻理解，WAF对来自Web应用程序客户端的各类请求进行内容检测和验证，确保其安全性与合法性，对非法的请求予以实时阻断，从而对各类网站站点进行有效防护。

ModSecurity是一个入侵侦测与防护引擎，其目的是为增强Web应用程序的安全性和保护Web应用程序避免遭受来自已知与未知的攻击。

Nginx 安装 modSecurity 模块

  1. 安装依赖
1
2
3
4
su
yum install -y gcc make automake autoconf libtool
yum install -y pcre pcre-devel libxml2 libxml2-devel curl curl-devel httpd-devel

2. 编译 modSecurity

首先到 modSecurity 官网上下载最新版并编译：

1
2
3
4
5
6
7
8
wget https://www.modsecurity.org/tarball/2.9.0/modsecurity-2.9.0.tar.gz
tar -xvpzf modsecurity-2.9.0.tar.gz
cd modsecurity-2.9.0
./autogen.sh
./configure --enable-standalone-module
make

会花1分钟左右的时间去编译。

3. 将 modSecurity 模块打包进 nginx

要从源码层级将 modSecurity 模块编译进 nginx。

1
2
3
4
5
6
7
8
9
cd ~
wget http://nginx.org/download/nginx-1.7.8.tar.gz
tar -xvpzf nginx-1.7.8.tar.gz
cd nginx-1.7.8
./configure --add-module=../modsecurity-2.9.0/nginx/modsecurity/
make
make install
cd /usr/local/nginx/sbin

安装后，nginx 位于 /usr/local/nginx/sbin/nginx。

4. 启用 modSecurity

1
2
cd /usr/local/nginx
vi conf/nginx.conf
1
2
3
4
location / {
	ModSecurityEnabled on;
	ModSecurityConfig modsecurity.conf;
}

上面指定了modSecurity 的配置文件为 modsecurity.conf，下面来创建它：

1
2
3
4
# create am empty modsecurity.conf
touch conf/modsecurity.conf
# test the conf file
sudo ./nginx -t

参考：

 

tech

查看全文 >>

Linux Utilities

network

curl

POST json data:

1
curl -H "Content-Type: application/json" -d '{"username":"xyz","password":"xyz"}' http://foo.com/api/login

Post a file:

1
curl -D - -F key1=value1 -F uploadedFile=@E:\abc.txt http://foo.com/post

For windows, single quotes around json did not work and I ended up escaping double quotes:

1
curl -X POST -H "Content-Type: application/json" -d "{ \"key1\": \"value1\" }" http://foo.com/api/method

text browsers

elinks, lynx, etc.

tech

查看全文 >>

Troubleshooting: POST Data Cannot Be Read From HttpServletRequest

问题

遇到一个奇怪的问题：明明客户端有 POST 数据到服务端，但服务端就是“获取不到”数据。相关的代码如下：

1
2
3
4
5
6
@RequestMapping(value = "goodsOrder", method = RequestMethod.POST)
public String goodsOrder(HttpServletRequest request, @RequestParam(value="page", required=false, defaultValue="1") int page)
	byte[] postBytes = IOUtils.toByteArray(request.getInputStream());
	
	// ...
}

此处，取到的 postBytes 总为空，而不是用户提交的数据。

原因及解决

使用 Spring @RequestParam 来注入参数时，Spring 会去读取 HttpServletRequest request 的值，而request.getInputStream() 只能读取一次，所以就造成第二次去读参数时，获取不到数据了。

注意：ServletRequest.getParameter() 等方法也会隐式地读取请求数据，数据读取一次后得将其保存起来，因为不能再重新获取了。

tech

查看全文 >>

Nginx Configuration

Part of configurations in nginx.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
http {
	# Enable GZip compression
	gzip                on;
	gzip_http_version   1.1;
	gzip_min_length     1000;
	gzip_buffers        16 8k;
	gzip_disable        "MSIE [1-6] \.";
	gzip_types          text/html text/css text/xml application/x-javascript application/atom+xml text/plain
	gzip_vary           on;
	# Set proxy cache path
	proxy_cache_path /var/nginx/cache keys_zone=one:10m;
	upstream tomcat_cluster {
		ip_hash;
		server ws1:12130;
		server ws2:12130;
	}
	server {
		listen       80;
		server_name  localhost;
		
		location /portal/static/ {
			root D:/anyfish_web/nginx/;
			expires 30d;
			proxy_cache_valid 200 1d;
			proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_504;
		}
		
		location /manager {
			allow 192.168.1.1/24;
			allow 127.0.0.1;
			deny all;
		}
		location / {
			proxy_pass http://tomcat_cluster;
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "upgrade";
			proxy_set_header Host $host:$server_port;
			proxy_set_header  X-Real-IP  $remote_addr;
        }
	}
}

Notes

GZip compression

1
2
3
4
5
6
7
gzip                on;
gzip_http_version   1.1;
gzip_min_length     1000;
gzip_buffers        16 8k;
gzip_disable        "MSIE [1-6] \.";
gzip_types          text/html text/css text/xml application/x-javascript application/atom+xml text/plain
gzip_vary           on;

Session persistence

Set ip_hash for session persistence.

Serving static content

1
2
3
4
5
6
location /portal/static/ {
	root D:/anyfish_web/nginx/;
	expires 30d;
	proxy_cache_valid 200 1d;
	proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_504;
}

Change the root for URL starting with “/portal/static/“, letting it the serve the request with local static files.

Server cluster/rack

1
2
3
4
5
6
7
8
9
10
11
upstream tomcat_cluster {
	ip_hash;
	server ws1:12130;
	server ws2:12130;
}
server {
	location / {
		proxy_pass http://tomcat_cluster;
	}
}

upstream is used for proxying requests to other servers.

Conf for websocket:

1
2
3
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

The first line tells Nginx to use HTTP/1.1 when communicating to the Node backend, which is required for WebSockets. The next two tell Nginx to respond to the Upgrade request which is initiated over HTTP by the browser when it wants to use a WebSocket.

If the listening port is not 80:

1
proxy_set_header Host $host:$server_port;

Note the $server_port part shoud be present. Without it, the redirection will jump to $host:80, rather than the specified port!

Restrict access to the management pages by IP:

1
2
3
4
5
location /manager {
	allow 192.168.1.1/24;
	allow 127.0.0.1;
	deny all;
}

Virtual Host

Each server block represent the one virtual host with its own server_name. Each server blocks looks like:

1
2
3
4
5
6
7
8
server {
	listen       80;
	server_name  blog.server1.com;
	location / {
		proxy_pass http://127.0.0.1:8282;
	}
}

here each server blocks bind (listen) the port 80, and this server block is only resonds when the server_name value (here blog.server1.com) is matched the HTTP header Host field

location syntax

1
location [ = | ~ | ~* | ^~ ] uri { ... }

Here,

"~" - case sensitive matching
"~*" - case insensitive matching
"=" - forces a literal match between the request URI and the location parameter.

Scripting

Check the great presentation here Introduction to nginx.conf scripting.

tech

查看全文 >>

[转]常见的Web应用漏洞及其解决方法

在 五个常见的Web应用漏洞及其解决方法 提到了几种常见的 Web 攻击方式及防范。

常见的Web应用漏洞及其解决方法

开放Web应用安全项目(OWASP)很快会发布今年的10大Web应用安全漏洞清单。这个清单与去年并没有太大差别，这表明负责应用设计与开发的人仍然没能解决以前那些显而易见的错误。许多最常见的Web应用漏洞仍然广泛存在，许多恶意软件搜索和攻击这些漏洞，连黑客新手都能轻松做到。
本文介绍了5个最常见的Web应用漏洞，以及企业该如何修复初级问题，对抗那些针对这些漏洞的攻击。

注入攻击和跨站脚本攻击

Web应用主要有2种最常见的严重缺陷。首先是各种形式的注入攻击，其中包括SQL、操作系统、电子邮件和LDAP注入，它们的攻击方式都是在发给应用的命令或查询中夹带恶意数据。别有用心的数据可以让应用执行一些恶意命令或访问未授权数据。如果网站使用用户数据生成SQL查询，而不检查用户数据的合法性，那么攻击者就可能执行SQL注入。这样攻击者就可以直接向数据库提交恶意SQL查询和传输命令。举例来说，索尼的PlayStation数据库就曾经遭遇过SQL注入攻击，并植入未授权代码。

跨站脚本(XSS)攻击会将客户端脚本代码(如JavaScript)注入到Web应用的输出中，从而攻击应用的用户。只要访问受攻击的输出或页面，浏览器就会执行代码，让攻击者劫持用户会话，将用户重定向到一个恶意站点或者破坏网页显示效果。XSS攻击很可能出现在动态生成的页面内容中，通常应用会接受用户提供的数据而没有正确验证或转码。
为了防御注入攻击和XSS攻击，应用程序应该配置为假定所有数据——无论是来自表单、URL、Cookie或应用的数据库，都是不可信来源。要检查所有处理用户提供数据的代码，保证它是有效的。验证函数需要清理所有可能有恶意作用的字符或字符串，然后再将它传给脚本和数据库。要检查输入数据的类型、长度、格式和范围。开发者应该使用现有的安全控制库，如OWASP的企业安全API或微软的反跨站脚本攻击库，而不要自行编写验证代码。此外，一定要检查所有从客户端接受的值，进行过滤和编码，然后再传回给用户。

身份验证和会话管理被攻破

Web应用程序必须处理用户验证，并建立会话跟踪每一个用户请求，因为HTTP本身不具备这个功能。除非任何时候所有的身份验证信息和会话身份标识都进行加密，保证不受其他缺陷(如XSS)的攻击，否则攻击者就有可能劫持一个激活的会话，伪装成某个用户的身份。如果一个攻击者发现某个原始用户未注销的会话(路过攻击)，那么所有帐号管理功能和事务都必须重新验证，即使用户有一个有效的会话ID。此外，在重要的事务中还应该考虑使用双因子身份验证。

为了发现身份验证和会话管理问题，企业要以执行代码检查和渗透测试。开发者可以使用自动化代码和漏洞扫描程序，发现潜在的安全问题。有一些地方通常需要特别注意，其中包括会话身份标识的处理方式和用户修改用户身份信息的方法。如果没有预算购买商业版本，那么也可以使用许多开源和简化版本软件，它们可以发现一些需要更仔细检查的代码或进程。

不安全的直接对象引用

这是应用设计不当引起的另一个缺陷，它的根源是错误地假定用户总是会遵循应用程序的规则。例如，如果用户的帐号ID显示在页面的URL或隐藏域中，恶意用户可能会猜测其他用户的ID，然后再次提交请求访问他们的数据，特别是当ID值是可以猜测的时候。防止这种漏洞的最佳方法是使用随机、不可猜测的ID、文件名和对象名，而且不要暴露对象的真实名称。常见的错误暴露数据的位置是URL和超链接、隐藏表单域、ASP.NET的未保护视图状态、直接列表框、JavaScript代码和客户端对象(如Java Applet)。每次访问敏感文件或内容时，都要验证访问数据的用户已获得授权。

安全性配置不当

支持Web应用程序的基础架构包含各种各样的设备和软件——服务器、防火墙、数据库、操作系统和应用软件。所有这些元素都必须正确配置和保证安全，应用程序只是运行在最低权限配置上，但是许多系统本身还不够安全。系统管理不当的一个主要原因是Web应用程序管理人员和基础架构支持人员从未接受过必要的培训。

为执行日常网络应用管理的人员提供足够的培训和资源，这是在开发过程中所有阶段保证安全性和保密性的重要条件。最后，要为Web应用程序安排一个渗透测试，处理所有敏感数据。这是一种主动评估应用抵抗攻击能力的方法，可以在受到攻击前发现系统漏洞。

下篇： nginx 安装 modSecurity

tech

查看全文 >>

Team Management

情绪与效率

这在 技术团队的情绪与效率 中已经讲得很好了：

  • 在 GTD（Get Things Done）中对此有阐述『压力不是来自于任务本身，而是任务在大脑中的堵塞，带来的焦虑和心理的抵触』。当一件任务还没有完成时，持续到来的新任务会带来很大的心理压力，意志不够强大时，很容易导致执行力崩溃，进入一种任务怎么做都做不完的绝望状态。

  • 一个健康的团队需要维持开发的节奏，具体操作可以是 每1-2周为一个周期，进行大的项目规划，研发任务占用时间最好不高于80%，之后每个人能有休息/自我充电的时间，在下个周期开始时，团队又能进入满体力值的状态。
    情绪的影响因素很多，简单列举几个很常见的：

    1. 研发节奏过于紧凑：在上一节中提到当开发的情绪体力持续透支时，会有恶劣的情绪问题。 这个在开发团队中并不少见。当开发节奏太过紧凑，团队不注意休整时，团队很容易负面情绪弥漫，而情绪一旦形成印象，便不会那么好消散。
    2. 薪酬倒挂：这个也是大家诟病 HR/Leader的重要原因，当一个团队薪酬内部增长太乏力时，内部人员会有流出，团队需要再招聘新人，而市场上平均待遇已经和之前不同，所以新招来的人员待遇往往也会水涨船高。 这个是很致命而且不好消解的。HR 太过节约成本，往往会对团队有致命的伤害。
    3. 与 Leader 理念/习惯 不合。
    4. 工作内容安排不当，太困难或太简单，或者与职业发展规划不符。
    5. 纯粹发泄。
    6. ……

去年的主要问题在于公司里的加班情况过于严重，导致中后期的效率不高，总体工作完成量跟正常上班时间做的差不多，甚或更少。幸好管理层也有意识到这个问题，着手制定规范一些的流程。规范与近期效果是相对矛盾的，但为了后期的维护及长期的团队管理，取一个平衡点。开发流程可依实际情况引入敏捷开发模式。

坚持做的与不足之处

坚持做下来的：

  • 组里即时通讯群中的技术、生活分享
  • 与各个组员私交不错，所以工作好开展。
  • GTD： 现使用 ToDoList （官网需要翻墙才能访问 -_-! 不过国内各大下载站都可以下载得到）做个人时间管理；团队里用 redmine 做 Bug Tracking, Task assignment, Knowledge Management 等。
    • 之前在 CentOS 中装 redmine，依赖的包比较多，安装过程并不顺序，现在用的是 bitnami 的版本。

几点做得不好的：

  • 之前在上海、苏州公司时，一两周有一次会有分享会议，技术的、生活的，甚至音乐、哲学方面的。现在几乎没有。虽说任务较重，但时间总是挤出来的。
mgmt

查看全文 >>

Which FOSS To Use

关于开源软件

开源之殇 中提到

使用开源有风险
前提：这里的开源产品，特指业务关联度高的中间件产品（比如分布式文件系统，消息队列中间件，即时通讯服务器，任务调度中间件，检索系统等）。
最大的风险来自两方面：

  1. 使用过程中发现后续需求不满足
  2. 线上遇到BUG或者问题
  3. 使用过程中发现后续需求不满足

选择开源要谨慎
基本使用开源中间件的公司在产品做到一定规模一定会遇到上面提到的风险和问题，大多数公司的选择也是一样，推倒重来，重新开发适合自己的中间件。比如淘宝，比如新浪，比如TWITER。相同的功能大家做了又做，不是炫耀自己有多牛，而是逼不得己。
但并不是所有的开源都是洪水猛兽似的，通用性工具类的，特别是经过了大公司长时间验证过的通用性工具，是可以选用的，比如MYSQL, ZOOKEEPER, NGINX, HAPROXY, OPENFIRE, SOLR, KEEPALIVED, LIBEVENT, MINA, NETTY, TOMCAT, APACHE, LUCENE, REDIS, MONGODB, MEMCACHED 等等等等，是可以放心去选用的，前提是要对这些产品的配置和优化有充分的理解。

使用的开源软件

  • NGiNX + Tomcat 作为 web server
  • Spring, SpringMVC
  • Zookeeper 来做注册服务中心的管理者
  • Netty 与 Mina 师出同源，但前者的网络性能更佳、API接口更规范
  • 简单的队列系统使用 Redis
tech

查看全文 >>

tag:

    缺失模块。
    1、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    2、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: true
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

Hello, I'm Fouding based in Xiamen, China. <br>This is my blog about life, career and technologies.