标签归档：nginx

使用OPNsense来保护内网的服务

发表评论

因为在家里部署了不少应用服务，所以，也想将一些服务暴露到公网上，但是呢，直接暴露的话，会有非常大的风险。全部走vpn也略微有点麻烦，虽然最近看到一些油管的UP主在推荐cloudflare的tunnel服务，但是我都自己托管了，还走cloudflare是不是有点……愚蠢呢。

因为工作的原因有接触过pfSense，然后也尝试过其分支OPNsense，一番测试之后，发现大有可为，不得不说真好使。

安装OPNsense

就是很普通的用iso引导，然后根据屏幕上的说明一路下一步就行。安装完毕之后，顺手更新一下系统。调整一下时区、默认语言等。

安装必要的插件

最主要的插件只有2个，一个是os-acme-client，另外一个是os-nginx。acme负责签署证书，而nginx，则负责做反向代理。

自动注册证书

从侧边栏访问“服务-ACME客户端”，默认的设置页面会报错，这时候，需要切换成英文，就能够正常打开页面了。跑去settings页面，打开启用插件和自动更新，应用。剩下的就可以切换回中文了。

下一步，就是创建一个账号，只要填一下邮箱地址，其他默认就行。

下一步是添加一个“挑战类型”，这里其实翻译成“验证类型”会比较好……

由于国内的环境，80和443端口都不用想了，所以只能走dns，具体用哪一家的dns，就根据对应的服务商的文档来配置就行。

下一步是创建一个自动操作，这里选择重启Nginx，这样证书在续签之后会自动重启nginx，并应用新的证书。

然后就是创建一个证书（申请）

注意这里的域名应该这样设计：一个通用域名（example.com），还有其下的通配符域名（*.example.com）。到时候，example.com应该返回一个404；具体对应的系统，则应该放在子域名来访问，例如nextcloud.example.com。另外，所有的应用都应该使用同一个监听端口，除非是由于某些原因，只能使用”流“（stream）代理。如此，可以最大限度地隐藏服务入口。

最后，自动操作里面选择一下刚创建的重启nginx的操作。保存。

保存之后出来可以手动触发一下证书签署，顺利的话就直接拿到一个可以用的证书了。

配置NGINX

OPNsense使得nginx的配置简单的很多，只要点点点就行，而且附加了很多安全方面的设置，有很多值得学习的内容。

创建错误提示页面

为了误导可能的攻击者，我们需要整点花活，因为默认情况下，被策略拦截之后，会向客户端返回一个页面，提醒被OPNsense上的策略拦截了。这可不行，怎么能让对方知道我们用了什么东西的呢对吧。我们来创建一个错误页面，整一个Nginx默认的500错误页面。并且匹配所有的状态码。

这样，无论是什么错误，用户都只能看到一个500的错误。（邪恶）

创建一个默认的服务器

设计的思路在证书那里已经说过了，首先，创建一个默认的服务器，在访问域名不正确的情况下，所有的访问都会跑到这里来：

位置

首先创建一个位置（HTTP(s)-位置），打开高级模式，修改以下的内容，确认保存：

  • 描述：随便填写
  • 网址格式：/
  • 强制HTTPS：勾选
  • honeypot：勾选

这里解释一下这个honeypot，在打开这个参数之后，如果访问了这个位置，就只会返回一个403，并且源地址将会被记录，然后屏蔽。具体屏蔽的时间，可以在“常规设置”的页面，打开高级选项，就可以自定义屏蔽的时间了。

HTTP服务器

然后创建一个服务器（HTTP(s)-HTTP服务器），修改这些内容：

  • HTTP监听地址：空
  • HTTPS监听地址：0.0.0.0:8443（你应该换个别的端口号）
  • TLS证书：（刚签署的那个）
  • 仅HTTPS：勾选
  • 错误页面：刚创建的糊弄人的默认错误页面

配置好DNS之后就可以测试一下是否生效了。尝试访问一下这个服务器，会得到一个空白页。然后在禁止的页面上就能看到这个ip进入了拦截清单了。

调整防火墙策略

最后一步就是调整防火墙策略，新增一个策略，拦截掉这些坏东西的访问：

  • 操作：阻止
  • 源：nginx_autoblock

这样，那些来源不明的访问就会被拦截。

应用保存之后，一个基本的拦截就做好了，攻击者在不知道你有什么域名的情况下，如果访问了OPNsense，就会被关小黑屋，被防火墙拦截，而被防火墙拦截的情况下，其他的端口也会无法访问。

另外，由于我们签署的证书包含2个域名，一个是example.com，另外一个是*.example.com。所以，即便是通过这次的访问，拿到了SSL证书，也不会知道我们用的是什么域名。这就能最大限度地隐藏访问入口。

添加需要暴露的服务器

基础搭建好了之后，就是增加需要通过nginx反向代理的服务了。一共有4个步骤，简单的说法：

  1. 添加一个“上游服务器”
  2. 添加一个“上游”
  3. 添加一个“位置”
  4. 添加一个“HTTP服务器”

上游服务器

需要填写的一共4项，描述、服务器、端口还有优先级。这里特别说明以下，因为设计上，是有多个后端的，所以必须要填上一个优先级。因为一般只有1个后端，所以……随便填一个数字就行。

上游

这里的话，只要填写描述，然后，服务器条目选择刚创建的上游服务器即可。值得注意的是，如果被反代的服务器是使用https的，则需要勾选上“启用TLS（HTTPS）”

位置

位置的话，刚才在创建一个默认的服务器的时候已经讲过了，这次稍有不同的地方，就是有一个额外的选项需要选择，就是“上游服务器”，这里选择刚才创建的“上游”即可。

HTTP服务器

可以参考上面的创建http服务器，和之前的主要差别，只有1个，那就是需要指定一个你自己才知道的属于*.example.com的子域名。由于证书是泛域名证书，所以所有子域名都能够使用。

应用配置

一切搞定之后，点击应用，保存并生效。

最后，在调整完dns之后，你就能用https://private.example.com:8443/来访问你需要暴露的服务了。有多个应用的情况下，重复创建上游服务器、上游、位置、http服务器，即可。

在Nginx中使用客户端证书认证

发表评论

其实这个东西很久以前就想搞的了，一直没动手，直到最近总在外面跑，有时候就考虑连回家里，于是稍微动了一下手。

选nginx是因为这个服务器够轻型，做前端最好了，而且做前端的话以前也做过，有经验。

上连接：

http://blog.csdn.net/kunoy/article/details/8239653



http://blog.csdn.net/jinhill/article/details/2573777
签证书什么的感觉略微有点麻烦了，于是果断的用了openvpn的easyrsa，这套脚本帮我很轻松的完成了证书的签署。主要用到了build-ca build-key-server build-key，根据名字就看出来了，生成ca证书，生成服务器证书，生成私有证书。这部分根据不用的系统，生成的证书在不同的位置，详情再自行Google之。我是在openwrt上做的，签好的证书在/etc/easyrsa/keys下。

如果真心想认真学习签证书的话还是去做多点的Google吧。

证书和密钥到手，这时候比较推荐导出一下客户端证书，使用以下命令

openssl pkcs12 -export -inkey client.key -in client.crt -CAfile ca.crt -chain -out client.pfx

就能得到一份可以导入的私有证书了。（暂时我只找到这种笨办法）

 

证书都准备好之后就是服务器的配置了。

先要处理一下openssl.conf，主要是这几行

dir            = /etc/easy-rsa/keys         # top dir  
database       = $dir/index.txt          # index file.  
new_certs_dir  = $dir/newcerts           # new certs dir  

certificate    = $dir/ca.crt         # The CA cert  
serial         = $dir/serial             # serial no file  
private_key    = $dir/ca.key  # CA private key  
RANDFILE       = $dir/.rand      # random number file 

countryName = match  
stateOrProvinceName = match  
organizationName = match  
organizationalUnitName = match  
localityName            = optional  
commonName              = supplied  
emailAddress            = optional

上半部分是证书文件的位置，下半部分是认证哪些内容是相同，自己看着修改。

openssl弄好之后就是重头戏了，nginx本身的配置。

默认的配置文件里有https服务器的实例，参照着就能弄好一个认证服务器端证书的，只要稍微加上几行就能加上私有证书的认证了。

    # HTTPS server

    server {
        listen       443;
        server_name  Router;

	charset utf8;

        ssl                  on;
        ssl_certificate      /etc/easy-rsa/keys/ferrets.imzone.in.crt;
        ssl_certificate_key  /etc/easy-rsa/keys/ferrets.imzone.in.key;

	ssl_client_certificate /etc/easy-rsa/keys/ca.crt; #客户端证书认证所需要的ca证书

        ssl_session_timeout  5m;
        ssl_protocols  SSLv2 SSLv3 TLSv1;
        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers   on;
	ssl_verify_client on; #启用客户端证书认证

        location / {
            proxy_pass ;
		proxy_redirect default;
        }
		location /transmission {
			proxy_pass ;
			proxy_redirect default;
		}
    }

嗯，像上面一样的配置文件我就是做的代理服务器，转发到192.168.1.1和192.168.1.1:9091，方便远程管理路由和transmission。

感觉一下子强力了好多啊。

启用了Nginx作Luci的SSL前台

4条回复

最近自己重新做固件嗯，因为某些癖好（算是吧，因为太钟爱于https了），一直在启用luci的https，可是不知道为什么，uhttpd的TLS插件无法启用，于是蛋疼了，我擦嘞，不了个是吧，不带这样玩啊…

于是只能启用不安全的uhttpd，让我一阵纠结，心里总是没有安全感…

一晃打开了transmission-web，突然想起了以前看到过的一个老外写的blog，说想远程管理transmission，但是transmission又没有密码保护（现在的版本好像有了），于是就用个nginx做前端，加上密码认证，就可以避免别人过来搞东搞西了。

这给了我启发，为什么不用nginx做SSL的前端呢？效果是一样的啊，顺带transmission的远端管理也可以做了，一举双得。

于是我动手了

首先是重新编译了一次nginx，因为官方编译的nginx没有包含ssl支持

然后启动了普通版的uhttpd，开始监听之后，修改nginx的配置，打开ssl支持，加上证书个密钥（因为用的是以前的证书，所以不用重新签），再写个proxy_pass（这个似乎有点问题，如果写到了location /path/ 中之后出现了问题，似乎是东西显示不完全，格式有点乱，后来写到 location / 中就没有问题了）

顺便把transmission的web管理加上，reload一次之后就完全没问题了。除了载入速度略有下降（transmission的web管理速度慢了稍微有点多）

附上一下配置文件

server {
listen 443;
server_name Router;

charset utf8;

ssl on;
ssl_certificate /etc/ssl/CA/keys/luci_school.crt;
ssl_certificate_key /etc/ssl/CA/keys/luci.key;

ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

location / {
proxy_pass ;
proxy_redirect default;
}
location /transmission {
proxy_pass ;
proxy_redirect default;
}
}