Nginx實踐 安全公升級

2022-06-01 02:09:07 字數 1340 閱讀 4199

之前寫了一些nginx的東西,這次繼續,主要使用upstream針對proxy_pass**做個處理

一般情況下我們在使用nginx反向**的時候,都是如下配置,

...

location /api

...

這樣就實現了'/api'目錄介面的**。功能是實現了,但是有什麼問題麼?還真有!如果我們可以反向**,如果別人也知道了我們的介面網域名稱也不是可以自己搭乙個nginx伺服器就可以**到我們的介面伺服器上去???是不是感覺很危險,是的。。。對此當時做的時候就加了乙個臨時方案,在介面服務中新增乙個ip白名單,白名單中的ip都是nginx伺服器的ip,然後就專案上線了。這樣也實現了需求,但ip如果被偽造了怎麼辦?於是我們想到了另乙個方案,使用內網ip代替對外開放的網域名稱,這樣在一定程度上就直接攔截了外部的直接訪問,具體實現如下,

upstream apiserver 

...location /api

...

我們使用upstream定義了乙個apiserver的組,將**都指向這裡,這時相當於我們把可能存在的使用者直接訪問介面伺服器的可能給關閉了,也就是途中紅色的那部分危險操作~~

可能你會想upstream的使用純屬多餘,的確當apiserver只有一台機器的時候,這個的確可以不用,但是多台機器的時候,雖然proxy_pass雖然可以定義多條但是太麻煩了。。。使用upstream組統一管理即可,同時使用upstream還有一些優勢比如給多個server設定負載均衡,upstream組中支援通過weight引數來設定當前server在負載均衡中所佔的比重,此外還可以通過設定backup引數指定某些伺服器作為備份機等等。詳細的配置內容還是建議大家參考nginx upstream官方文件。

此外,除了安全性方面,使用內網ip進行介面**也省去了**中的dns重新解析的過程,有利於大幅提公升介面**效率。同時若不想破壞已經做好的slb的話,也可以不使用upstream,直接**到slb伺服器的內網ip應該也是可以的。

綜上,在proxy_pass**中我們使用了兩種方案來對安全性做一些提公升

此處新增乙個修正,最初版原文中在proxy_pass後面我們使用了https+upstream的方式進行**,但是在生產環境上發現使用https出現伺服器502閘道器問題。

...

location /api

...

考慮到內網ip訪問,不需要https,於是我們把https換成了http,問題解決。

nginx平滑公升級

先來說下我今天要實驗nginx平滑公升級的環境,從nginx.1.8.0公升級到nginx1.9.5 大概的流程 nginx的程序分為master主程序和work工作程序,master程序主要管理事件訊號接受和分發,所有的請求處理都由work程序處理並返回結 果,nginx的平滑重啟或過載配置檔案等...

nginx無縫公升級

參考文章 tar zxvf nginx 1.10 1.tar.gz cd nginx 1.10 1.tar.gz configure prefix usr local nginx with stream with cc usr sfw bin gcc make注意 這裡make就行,不要make i...

Nginx平滑公升級

原文 來自nginx官網 如果想要公升級nginx版本 或者在原本版上增加 刪除模組 同時保持服務不間斷,採用如下方式可滿足要求。1.使用新的二進位制檔案替換老的二進位制檔案,這需要注意的是nginx原始碼在執行make編譯後,不要直接make install,否則可能會覆蓋其他配置檔案,命令如下 ...