整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
這篇文章我翻譯自：https://github.com/JonasCz/How-To-Prevent-Scraping，因為最近在看一些反爬的資料，無意間在 Github 發現這篇文章，我覺得寫的很全面，所以想要翻譯一下，順便進行吸收。另外讓我覺得非常贊的是這個文章從服務端和前端的角度都做了分析，我們應該從哪些點去做優化，而且每個點都舉了例子，有些還給出了注意點。雖然文中有些提到的一些點很基礎，也有很多我們目前在業務中也在使用，但是我還是從中吸收到了一些新東西，里面文中外部鏈接有很多，但是公眾號這里不允許外鏈，所以大家可以點擊文末最后的"閱讀原文"到 Github 去查看，Github Markdown 的排版可能也比這里更好 : )。
（最后，有些倉促，可能有些注意不到的措別字，還請多多包涵）
提示：這篇文章是我 Stack Overflow 這個問題回答的擴展，我把它整理在 Github 因為它實在是太長了，超過了 Stack Overflow 的字數限制（最多 3 萬個字，這文章已經超過 4 萬字）
歡迎大家修改、完善還有分享，本文使用 CC-BY-SA 3.0 許可。
不幸的是這挺難的，你需要在防抓和降低真實用戶以及搜索引擎的可訪問性之間做一下權衡。
為了防爬（也稱為網頁抓取、屏幕抓取、網站數據挖掘、網站收割或者網站數據獲取），了解他們的工作原理很重要，這能防止他們能高效爬取，這個就是這篇文章的主要內容。
通常情況下，抓取程序的目的是為了獲取你網站特定的信息，比如文章內容、搜索結果、產品詳情還有網站上藝術家或者相冊信息。他們爬取這些內容用于維護他們自己的網站（甚至通過你的內容賺錢！），或者制作和你網站不一樣的前端界面（比如去做移動 APP），還有一些可能作為個人研究或分析使用。
實際上，有特別多的爬蟲類型，而且他們的爬取方式都不太相同：
以上不同的爬蟲類型有很多相同點，很多爬蟲的行為也很相似，即使他們使用了不同的技術或者方案去爬取你的內容。
這些大多數都是我自己的想法，我在寫爬蟲時也遇到許多困難，還有一些是來源于網絡。
一些常見的檢測和防止爬蟲的方法：
周期性的檢查你的日志，如果發現有異常活動表明是自動爬取（爬蟲），類似某一個相同的 IP 很多相同的行為，那你就可以阻止或限制訪問。
一些常用的方法：
舉個例子，如果某個 IP 請求了你網站很多次，所有的訪問都有相同的 UserAgent 、屏幕尺寸（JavaScript 檢測），還有全都使用同樣的方式和固定的時間間隔點擊同一個按鈕，那它大概是一個屏幕爬蟲；你可以臨時限制相似的請求（比如 只限制來自那個 IP 特定 User-Agent 和 屏幕尺寸的請求），這樣你不會誤傷同樣使用這個 IP 的真實用戶，比如共享網絡鏈接的用戶。
更進一步，當你發現相似的請求，但是來自不同的 IP 地址，表明是分布式爬蟲（使用僵尸網絡或網絡代理的爬蟲）。如果你收到類似大量的請求，但是他們來自不同的 IP 地址，你可以拒絕訪問。再強調一下，小心不經意限制了真實用戶。
這種方法對那種運行 JavaScript 的屏幕爬蟲比較有效，因為你可以獲得他們大量的信息。
Stack Exchange 上關于 Secruity 的相關問題：
How to uniquely identify users with the same external IP address?
Why do people use IP address bans when IP addresses often change? 關于僅使用 IP 的其他限制
如果可行，要求創建用戶才可以查看你的內容。這個可以很好的遏制爬蟲，但很容易遏制真實用戶：
為了防止爬蟲創建大量的用戶，你應該：
要求注冊用戶對用戶和搜索引擎來說不友好；如果你要求必須注冊才可以看文章，那用戶也可能直接離開。
有時爬蟲會被運行在云服務商，比如 Amazon Web Services 或 Google App Engine，或者其他 VPS。限制這些來自云服務商的 IP 地址訪問你的網站（或出驗證碼）。你可以可以直接對來自爬取服務的 IP 地址限制訪問。
類似的，你也可以限制來自代理或 VPN 的 IP 地址，因為很多爬蟲會使用它們來防止被檢測到。
但是要知道限制來自代理服務器或 VPN 的 IP，也很容易影響到真實用戶。
如果你要封禁或限制訪問，你應該確保不要把導致封禁的原因告訴爬蟲，他們會根據提示修改自己的爬蟲程序。所以下面的這些錯誤最好不要出現：
想法的，展示一些不包含原因的友好信息會更好，比如下面的信息會更好：
如果真實用戶看到這個錯誤頁面，這個對真實用戶來說也十分友好。在后續訪問中，你也可以考慮展示驗證碼而不是直接封禁，如果真實用戶看到這個錯誤信息，對于合法用戶也會聯系你。
驗證碼（Captcha，“Completely Automated Test to Tell Computers and Humans Apart”)對于防爬十分有效。不幸的是，它也很容易惹惱用戶。
因此，如果你發現疑似爬蟲，而且想要阻止它的爬取行為，而不是封禁它以免它是真實用戶。你可以考慮顯示驗證碼在你再次允許訪問之前。
使用驗證碼的注意事項：
你可以在服務端將文字渲染成圖片顯示，他將防止簡單的爬蟲去獲取文字內容。
然而，這個對于屏幕閱讀器、搜索引擎、性能還有一些其他一些事情都不太好。這個在某些方面也是不違法的（源于訪問性問題，eg. the Americans with Disabilities Act），而且對于一些 OCR 爬蟲也能非常簡單的規避，所以不要采用這種方式。
你也可以用 CSS sprites 做類似的事情，但是也有相同的問題。
如果可以的話，不要讓腳本/爬蟲能獲取你所有的數據。舉個例子：你有一個新聞站，有大量的個人文章。你應該確保文章只能通過你自己網站的搜索到，如果你網站不是到處都有你的文章還有鏈接，那么確保它們只能被搜索功能訪問到。這意味著如果一個腳本想要獲取你網站的所有文章，就必須通過你站點文章中所有可能的短語去進行搜索，從而獲取所有的文章列表，但是這個會非常耗時，而且低效，從而讓爬蟲放棄。
以下操作會讓你完全暴露：
確保你不會暴露你的任何 API，很多時候都是無意間暴露。舉個例子，如果你正在使用 AJAX 或 Adobe Flash 的網絡請求 或 Java Applet（千萬不要用！）來加載你的數據，從這些網絡請求中找到要請求的 API 十分簡單，比如可以進行反編譯然后在爬蟲程序中使用這些接口。確保你混淆了你的 API 并且其他人要用它會非常難破解。
由于 HTML 解析器是通過分析頁面特定結構去獲取內容，我們可以故意修改這些結構來阻止這類爬蟲，甚至從根本上他們獲取內容。下面大多數做法對其他類型爬蟲如搜索引擎蜘蛛、屏幕爬蟲也有效。
處理 HTML 的爬蟲通過分析特定可識別的部分來處理 HTML。舉個例子：如果你所有的頁面都有 id 為 article-content 的 div 結構，然后里面有你的文章內容，那要獲取你站點所有文章內容是十分簡單的，只要解析那個 article-content 那個 div 就可以了，然后有這個結構的爬蟲就可以把你的文章隨便用在什么地方。
如果你常常修改 HTML 還有你頁面的結構， 那這類爬蟲就不能一直使用。
本質上來說，就是確保爬蟲從相似頁面獲取想要的內容變得不那么容易。
可以參考這個 PHP 的實現：How to prevent crawlers depending on XPath from getting page contents
這個和前一個類似。如果你根據不同用戶的位置/國家（根據 IP 獲取）來提供不同的 HTML，這個可能會破壞將站點 HTML 給用戶的爬蟲。比如，如果有人寫了一個移動 APP 來抓取你的站點，一開始可以用，但是對于不同地區的用戶就不起作用了，因為他們會獲取到不同的 HTML 結構，嵌入式的 HTML 將不不能正常使用。
舉個例子：你有一個包含搜索功能的網站， example.com/search?query=somesearchquery 的搜索結果是下面的 HTML 結構：
<div class="search-result">
<h3 class="search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
<p class="search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
<a class"search-result-link" href="/stories/stack-overflow-has-become-the-most-popular">Read more</a>
</div>
(And so on, lots more identically structured divs with search results)
你可以猜到這個非常容易爬取：一個爬蟲需要做的就只是訪問搜索鏈接，然后從返回的 HTML 分析想要的數據。除了定期修改上面 HTML 的內容，你也可以 保留舊結構的 id 和 class，然后使用 CSS 進行隱藏，并使用假數據進行填充，從而給爬蟲投毒 。比如像下面這樣：
<div class="the-real-search-result">
<h3 class="the-real-search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
<p class="the-real-search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
<a class"the-real-search-result-link" href="/stories/stack-overflow-has-become-the-most-popular">Read more</a>
</div>
<div class="search-result" style="display:none">
<h3 class="search-result-title">Visit example.com now, for all the latest Stack Overflow related news !</h3>
<p class="search-result-excerpt">EXAMPLE.COM IS SO AWESOME, VISIT NOW! (Real users of your site will never see this, only the scrapers will.)</p>
<a class"search-result-link" href="http://example.com/">Visit Now !</a>
</div>
(More real search results follow)
這意味著基于 id 或 class 獲取特定數據的爬蟲仍然能繼續工作，但是他們將會獲取假數據甚至廣告，而這些數據真實用戶是看不到的，因為他們被 CSS 隱藏了。
對上個例子進行補充，你可以在你的 HTML 里面增加不可見的蜜罐數據來抓住爬蟲。下面的例子來補充之前說的搜索結果：
<div class="search-result" style="display:none">
<h3 class="search-result-title">This search result is here to prevent scraping</h3>
<p class="search-result-excerpt">If you're a human and see this, please ignore it. If you're a scraper, please click the link below :-)
Note that clicking the link below will block access to this site for 24 hours.</p>
<a class"search-result-link" href="/scrapertrap/scrapertrap.php">I'm a scraper !</a>
</div>
(The actual, real, search results follow.)
一個來獲取所有內容的爬蟲將會被找到，就像獲取其他結果一樣，訪問鏈接，查找想要的內容。一個真人將不會看到（因為使用 CSS 隱藏），而且更不會訪問這個鏈接。而正規或者期望的蜘蛛比如谷歌的蜘蛛將不會訪問這個鏈接，因為你可以將 /scrapertrap/ 加入你的 robots.txt 中（不要忘記增加）
你可以讓你的 scrapertrap.php 做一些比如限制這個 IP 訪問的事情，或者強制這個 IP 之后的請求出驗證碼。
如果你確定某個訪問是爬蟲，你可以提供假的或者無用的數據；這將破壞爬蟲從你網站獲取的數據。你還應該把它和真實數據進行混淆，這樣爬蟲就不知道他們獲取的到底是真的還是假的數據。
舉個例子：如果你有一個新聞站，你檢測到了一個爬蟲，不要去直接封禁它，而是提供假的或者隨機生成的文章，那爬蟲獲取的數據將會被破壞。如果你將假數據和真實的數據進行混淆，那爬蟲很難獲取到他們想要的真實文章。
很多懶惰的程序員不會在他們的爬蟲發請求時帶上 UserAgent，而所有的瀏覽器包括搜索引擎蜘蛛都會攜帶。
如果請求你時沒有攜帶 UserAgent header 頭，你可以展示驗證碼，或者直接封禁或者限制訪問（或者像上面說的提供假數據或者其他的）
這個非常簡單去避免，但是作為一種針對書寫不當的爬蟲，是值得去做的。
很多情況下，爬蟲將會使用真實瀏覽器或搜索引擎爬蟲絕對不會使用的 UserAgent，比如：
如果你發現一些爬蟲使用真實瀏覽器或合法蜘蛛絕對不會使用的 UserAgent，你可以將其添加到你的黑名單中。
對上一章節的補充，你也可以檢查 [Referer] (https://en.wikipedia.org/wiki/HTTP_referer header) （是的，它是 Referer，而不是 Referrer），一些懶惰的爬蟲可能不會攜帶的這個，或者只是每次都攜帶一樣的（有時候是 “google.com”）。舉個例子，如果用戶是從站內搜索結果頁點擊進入文章詳情的，那要檢查 Referer 這個 header 頭是否存在還要看搜索結果頁的打點。
注意：
還是，作為一種防止簡單爬蟲的方法，也值得去實現。
一個真實瀏覽器（通常）會請求和下載資源比如 CSS 和 圖片。HTML 解析器和爬取器可能只關心特定的頁面和內容。
你可以基于訪問你資源的日志，如果你看到很多請求只請求 HTML，那它可能就是爬蟲。
注意搜索引擎蜘蛛、舊的移動設備、屏幕閱讀器和設置錯誤的設備可能也不會請求資源。
訪問你網站時，你可以要求 cookie 必須開啟。這個能識別沒有經驗和爬蟲新手，然而爬蟲要攜帶 Cookie 也十分簡單。如果你要求開啟 Cookie，你能使用它們來追蹤用戶和爬蟲的行為，然后基于此來實現頻率限制、封禁、或者顯示驗證碼而不僅僅依賴 IP 地址。
舉個例子：當用戶進行搜索時，設置一個唯一的 Cookie。當搜索結果加載出來之后，驗證這個 Cookie。如果一個用戶打開了所有的搜索結果（可以從 Cookie 中得知），那很可能就是爬蟲
使用 Cookie 可能是低效的，因為爬蟲也可以攜帶 Cookie 發送請求，也可以根據需要丟棄。如果你的網站只能在開啟 Cookie 時使用，你也不能給關閉 Cookie 的用戶提供服務。
要注意如果你使用 JavaScript 去設置和檢測 Cookie，你能封禁那些沒有運行 JavaScript 的爬蟲，因為它們沒辦法獲取和發送 Cookie。
你可以在頁面加載完成之后，使用 JavaScript + AJAX 來加載你的內容。這個對于那些沒有運行 JavaScript 的 HTML 分析器來說將無法取得數據。這個對于沒有經驗或者新手程序員寫的爬蟲非常有效。
注意：
如果你用 Ajax 和 JavaScript 加載你的數據，在傳輸的時候要混淆一下。比如，你可以在服務器端 encode 你的數據（比如簡單的使用 base64 或 負載一些的多次混淆、位偏移或者是進行加密），然后在客戶端在 Ajax 獲取數據之后再進行 decode。這意味著如果有人要抓包獲取你的請求就不能直接看到你頁面如何加載數據，而且那些人也不能直接通過 API 獲得你的數據，如果想要獲取數據，就必須要去解密你的算法。
下面是一些這個方式的缺點：
比如，CloudFlare 提供反蜘蛛和反爬蟲的防御，你只需要直接啟用它就可以了，另外 AWS 也提供類似服務。而且 Apache 的 mod_evasive 模塊也能讓你很輕松地實現頻率限制。
你應該直接告訴人們不要抓取你的網站，比如，在你的服務條款中表明。有些人確實會尊重它，而且不在你允許的情況下不會再去抓取數據。
律師們知道如何處理侵犯版權的事情，而且他們可以發送律師函。DMCA（譯者注：Digital Millennium Copyright Act，數字千年版權法案，是一個美國版權法律） 也能提供援助。
這看起來適得其反，但是你可以要求標明來源并包含返回你站點的鏈接。甚至也可以售賣你的 API 而賺取費用。
還有就是，Stack Exchange 提供了 API，但是必須要標明來源。
以我自己寫和幫忙別人寫爬蟲的經驗，我認為最有效的方法是：
擴展閱讀：
作者:h1z3y3
來源:微信公眾號: 360搜索技術團隊
出處:https://mp.weixin.qq.com/s?__biz=MzA5ODIxODE2Ng==&mid=2651137205&idx=1&sn=664a46d66f132c96780750d4e9b206eb
"防火墻"這個詞大家應該都聽說過或者應用過，每個人的電腦、手機幾乎都會安裝一些的主流的防火墻軟件，工作的企事業單位網絡里都會安裝硬件防火墻。那么這些防火墻能阻擋住黑客的攻擊嗎？今天我就和大家分享一下這個話題！
一、首先我們需要知道防火墻的原理或者說主要功能
1、什么是防火墻？
官方定義：防火墻也被稱為防護墻，它是一種位于內部網絡與外部網絡之間的網絡安全系統，可以將內部網絡和外部網絡隔離。通常，防火墻可以保護內部/私有局域網免受外部攻擊，并防止重要數據泄露。在沒有防火墻的情況下，路由器會在內部網絡和外部網絡之間盲目傳遞流量且沒有過濾機制，而防火墻不僅能夠監控流量，還能夠阻止未經授權的流量。
簡單理解：防火墻是由軟件或者軟件和硬件組成的系統，它處于安全的網絡（通常是內部局域網）和不安全的網絡之間，根據由系統管理員設置的訪問控制規則，對數據流進行過濾。
2、防火墻基本分類和工作原理
1) 包過濾防火墻
這是第一代防火墻，又稱為網絡層防火墻，在每一個數據包傳送到源主機時都會在網絡層進行過濾，對于不合法的數據訪問，防火墻會選擇阻攔以及丟棄。這 種防火墻的連接可以通過一個網卡即一張網卡由內網的IP地址，又有公網的IP地址和兩個網卡一個網卡上有私有網絡的IP地址，另一個網卡有外部網絡的IP 地址。
第一代防火墻和最基本形式防火墻檢查每一個通過的網絡包，或者丟棄，或者放行，取決于所建立的一套規則。這稱為包過濾防火墻。
本質上，包過濾防火墻是多址的，表明它有兩個或兩個以上網絡適配器或接口。例如，作為防火墻的設備可能有兩塊網卡(NIC)，一塊連到內部網絡，一塊連到公共的Internet。防火墻的任務，就是作為"通信警察"，指引包和截住那些有危害的包。
包過濾防火墻檢查每一個傳入包，查看包中可用的基本信息（源地址和目的地址、端口號、協議等）。然后，將這些信息與設立的規則相比較。如果已經設立了阻斷telnet連接，而包的目的端口是23的話，那么該包就會被丟棄。如果允許傳入Web連接，而目的端口為80，則包就會被放行。
多個復雜規則的組合也是可行的。如果允許Web連接，但只針對特定的服務器，目的端口和目的地址二者必須與規則相匹配，才可以讓該包通過。
最后，可以確定當一個包到達時，如果對該包沒有規則被定義，接下來將會發生什么事情了。通常，為了安全起見，與傳入規則不匹配的包就被丟棄了。如果有理由讓該包通過，就要建立規則來處理它。
建立包過濾防火墻規則的例子如下：
對來自專用網絡的包，只允許來自內部地址的包通過，因為其他包包含不正確的包頭部信息。這條規則可以防止網絡內部的任何人通過欺騙性的源地址發起攻擊。而且，如果黑客對專用網絡內部的機器具有了不知從何得來的訪問權，這種過濾方式可以阻止黑客從網絡內部發起攻擊。
在公共網絡，只允許目的地址為80端口的包通過。這條規則只允許傳入的連接為Web連接。這條規則也允許與Web連接使用相同端口的連接，所以它并不是十分安全。
丟棄從公共網絡傳入的包，而這些包都有你的網絡內的源地址，從而減少IP欺騙性的攻擊。
丟棄包含源路由信息的包，以減少源路由攻擊。要記住，在源路由攻擊中，傳入的包包含路由信息，它覆蓋了包通過網絡應采取得正常路由，可能會繞過已有的安全程序。
2) 狀態/動態檢測防火墻
狀態/動態檢測防火墻，試圖跟蹤通過防火墻的網絡連接和包，這樣防火墻就可以使用一組附加的標準，以確定是否允許和拒絕通信。它是在使用了基本包過濾防火墻的通信上應用一些技術來做到這點的。
當包過濾防火墻見到一個網絡包，包是孤立存在的。它沒有防火墻所關心的歷史或未來。允許和拒絕包的決定完全取決于包自身所包含的信息，如源地址、目的地址、端口號等。包中沒有包含任何描述它在信息流中的位置的信息，則該包被認為是無狀態的；它僅是存在而已。
一個有狀態包檢查防火墻跟蹤的不僅是包中包含的信息。為了跟蹤包的狀態，防火墻還記錄有用的信息以幫助識別包，例如已有的網絡連接、數據的傳出請求等。
例如，如果傳入的包包含視頻數據流，而防火墻可能已經記錄了有關信息，是關于位于特定IP地址的應用程序最近向發出包的源地址請求視頻信號的信息。如果傳入的包是要傳給發出請求的相同系統，防火墻進行匹配，包就可以被允許通過。
一個狀態/動態檢測防火墻可截斷所有傳入的通信，而允許所有傳出的通信。因為防火墻跟蹤內部出去的請求，所有按要求傳入的數據被允許通過，直到連接被關閉為止。只有未被請求的傳入通信被截斷。
如果在防火墻內正運行一臺服務器，配置就會變得稍微復雜一些，但狀態包檢查是很有力和適應性的技術。例如，可以將防火墻配置成只允許從特定端口進入的通信，只可傳到特定服務器。如果正在運行Web服務器，防火墻只將80端口傳入的通信發到指定的Web服務器。
狀態/動態檢測防火墻可提供的其他一些額外的服務有：
將某些類型的連接重定向到審核服務中去。例如，到專用Web服務器的連接，在Web服務器連接被允許之前，可能被發到SecutID服務器（用一次性口令來使用）。
拒絕攜帶某些數據的網絡通信，如帶有附加可執行程序的傳入電子消息，或包含ActiveX程序的Web頁面。
跟蹤連接狀態的方式取決于包通過防火墻的類型：
TCP包。當建立起一個TCP連接時，通過的第一個包被標有包的SYN標志。通常情況下，防火墻丟棄所有外部的連接企圖，除非已經建立起某條特定規則來處理它們。對內部的連接試圖連到外部主機，防火墻注明連接包，允許響應及隨后再兩個系統之間的包，直到連接結束為止。在這種方式下，傳入的包只有在它是響應一個已建立的連接時，才會被允許通過。
UDP包。UDP包比TCP包簡單，因為它們不包含任何連接或序列信息。它們只包含源地址、目的地址、校驗和攜帶的數據。這種信息的缺乏使得防火墻確定包的合法性很困難，因為沒有打開的連接可利用，以測試傳入的包是否應被允許通過。可是，如果防火墻跟蹤包的狀態，就可以確定。對傳入的包，若它所使用的地址和UDP包攜帶的協議與傳出的連接請求匹配，該包就被允許通過。和TCP包一樣，沒有傳入的UDP包會被允許通過，除非它是響應傳出的請求或已經建立了指定的規則來處理它。對其他種類的包，情況和UDP包類似。防火墻仔細地跟蹤傳出的請求，記錄下所使用的地址、協議和包的類型，然后對照保存過的信息核對傳入的包，以確保這些包是被請求的。
3) 應用程序代理防火墻
應用程序代理防火墻實際上并不允許在它連接的網絡之間直接通信。相反，它是接受來自內部網絡特定用戶應用程序的通信，然后建立于公共網絡服務器單獨的連接。網絡內部的用戶不直接與外部的服務器通信，所以服務器不能直接訪問內部網的任何一部分。
另外，如果不為特定的應用程序安裝代理程序代碼，這種服務是不會被支持的，不能建立任何連接。這種建立方式拒絕任何沒有明確配置的連接，從而提供了額外的安全性和控制性。
例如，一個用戶的Web瀏覽器可能在80端口，但也經常可能是在1080端口，連接到了內部網絡的HTTP代理防火墻。防火墻然后會接受這個連接請求，并把它轉到所請求的Web服務器。
這種連接和轉移對該用戶來說是透明的，因為它完全是由代理防火墻自動處理的。
代理防火墻通常支持的一些常見的應用程序協議有：
HTTP
HTTPS/SSL
SMTP
POP3
IMAP
NNTP
TELNET
FTP
IRC
應用程序代理防火墻可以配置成允許來自內部網絡的任何連接，它也可以配置成要求用戶認證后才建立連接。要求認證的方式由只為已知的用戶建立連接的這種限制，為安全性提供了額外的保證。如果網絡受到危害，這個特征使得從內部發動攻擊的可能性大大減少。
4) NAT
討論到防火墻的主題，就一定要提到有一種路由器，盡管從技術上講它根本不是防火墻。網絡地址轉換(NAT)協議將內部網絡的多個IP地址轉換到一個公共地址發到Internet上。
NAT經常用于小型辦公室、家庭等網絡，多個用戶分享單一的IP地址，并為Internet連接提供一些安全機制。
當內部用戶與一個公共主機通信時，NAT追蹤是哪一個用戶作的請求，修改傳出的包，這樣包就像是來自單一的公共IP地址，然后再打開連接。一旦建立了連接，在內部計算機和Web站點之間來回流動的通信就都是透明的了。
當從公共網絡傳來一個未經請求的傳入連接時，NAT有一套規則來決定如何處理它。如果沒有事先定義好的規則，NAT只是簡單的丟棄所有未經請求的傳入連接，就像包過濾防火墻所做的那樣。
可是，就像對包過濾防火墻一樣，你可以將NAT配置為接受某些特定端口傳來的傳入連接，并將它們送到一個特定的主機地址。
5) 個人主機防火墻
現在網絡上流傳著很多的個人防火墻軟件，它是應用程序級的。主機防火墻是一種能夠保護個人計算機系統安全的軟件，它可以直接在用戶的計算機上運行，使用與狀態/動態檢測防火墻相同的方式，保護一臺計算機免受攻擊。通常，這些防火墻是安裝在計算機網絡接口的較低級別上，使得它們可以監視傳入傳出網卡的所有網絡通信。
一旦安裝上個人防火墻，就可以把它設置成"學習模式"，這樣的話，對遇到的每一種新的網絡通信，個人防火墻都會提示用戶一次，詢問如何處理那種通信。然后個人防火墻便記住響應方式，并應用于以后遇到的相同那種網絡通信。
例如，如果用戶已經安裝了一臺個人Web服務器，個人防火墻可能將第一個傳入的Web連接作上標志，并詢問用戶是否允許它通過。用戶可能允許所有的Web連接、來自某些特定IP地址范圍的連接等，個人防火墻然后把這條規則應用于所有傳入的Web連接。
基本上，你可以將個人防火墻想象成在用戶計算機上建立了一個虛擬網絡接口。不再是計算機的操作系統直接通過網卡進行通信，而是以操作系統通過和個人防火墻對話，仔細檢查網絡通信，然后再通過網卡通信。
6) Web應用防火墻
Web應用防火墻是通過執行一系列針對HTTP/HTTPS的來專門為Web應用提供保護的一款產品，當WEB應用越來越為豐富的同時，WEB 服務器以其強大的計算能力、處理性能及蘊含的較高價值逐漸成為主要攻擊目標。SQL注入、網頁篡改、網頁掛馬等安全事件，頻繁發生。因此誕生了針對這一些安全隱患的防火墻，與上述防火墻不同，WAF工作在應用層，因此對Web應用防護具有先天的技術優勢。基于對Web應用業務和邏輯的深刻理解，WAF對來自Web應用程序客戶端的各類請求進行內容檢測和驗證，確保其安全性與合法性，對非法的請求予以實時阻斷，從而對各類網站站點進行有效防護。
主要特點：
WAF不僅僅只是防御Web的http訪問，可以對Web應用做到全方位的立體防護。可以防范：
· 常見的命令注入攻擊，利用網頁漏洞將含有操作系統或軟件平臺命令注入到網頁訪問語句中以盜取數據或后端服務器的控制權
· SQL 注入，找到數據查詢語句漏洞，通過數據庫查詢代碼竊取或修改數據庫中的數據
· 跨站腳本攻擊，利用網站漏洞攻擊訪問該站點的用戶，用戶登陸或認證信息；
· 各種HTTP 協議攻擊，利用http的協議漏洞進行攻擊；
· 機器人、 爬蟲和掃描，通過機器人，爬蟲，和掃描工具自動抓取網站數據以及對網站進行自動攻擊；
· 常見的應用程序配置錯誤 （如 Apache、 IIS 等），利用Web發布程序的配置漏洞或者已知bug進行攻擊
主要功能：
①防攻擊：功能主要關注Web應用并試圖入侵網絡服務器的攻擊事件過程。可以覆蓋OWASP TOP 10、WASC、PCI DSS等標準，包括、、攻擊等。
②防漏洞：可對網站中的敏感信息、服務器信息進行屏蔽或偽裝，達到避免數據泄露的隱患。成功的攻擊往往需要利用服務器的IP、操作系統信息、應用信息、服務器出錯信息、數據庫出錯信息，KS-WAF接管所有返回給客戶端的信息，并可中止會話，避免黑客利用敏感信息及服務器信息發動攻擊、各類黑客入侵攻擊。
③防掛馬：隨著監管部門的打擊力度逐漸加強，掛馬攻擊的數量越來越少，與此同時，地下逐漸轉向了。為了應對這個情況，KS-WAF系統內置了針對當前流行的暗鏈攻擊建立的惡意指紋庫，在服務器端已被植入暗鏈的情況下可準確識別并進行報警，協助管理員清除暗鏈代碼。
④URL檢測：通過實現URL級別的，對客戶端請求進行檢測，如果發現圖片、文件等資源信息的來自于其它網站，則阻止請求，節省因盜用資源鏈接而消耗的帶寬和性能。
⑤防爬蟲：將爬蟲行為分為搜索引擎爬蟲及掃描程序爬蟲，可屏蔽特定的搜索引擎爬蟲節省帶寬和性能，也可屏蔽掃描程序爬蟲，避免網站被惡意抓取頁面。
⑥防掛馬：通過檢查HTML頁面中特征、用戶提交數據，查看是否出現、Javascript引用掛馬源URL及其他掛馬特征以決定是否攔截請求。
⑦抗DDos：支持TCP Flood和HTTP Flood類型的拒絕服務攻擊，通過簡單有效的方式緩解拒絕服務攻擊。
⑨攻擊源定位：通過記錄攻擊者的源IP，進行分析和定位后，通過進行定位展現，幫助運維攻擊來源。
7) 下一代防火墻
上面所述的幾乎都是傳統意義的防火墻，下一代是一款可以全面應對應用層威脅的高性能。通過深入洞察網絡流量中的用戶、應用和內容，并借助全新的高性能單路徑異構并行處理，能夠為用戶提供有效的應用層一體化安全防護，幫助用戶安全地開展業務并簡化用戶的架構。
下一代防火墻和傳統防火墻的區別：
下一代防火墻是一款可以全面應對應用層威脅的高性能防火墻。通過深入洞察網絡流量中的用戶、應用和內容，并借助全新的高性能單路徑異構并行處理引擎，能夠為用戶提供有效的應用層一體化安全防護，幫助用戶安全地開展業務并簡化用戶的網絡安全架構。
傳統防火墻功能：具有數據包過濾、網絡地址轉換（NAT）、協議狀態檢查以及VPN功能等功能。相對而言，下一代防火墻檢測更加細。
下一代防火墻自身屬性：
(1) 標準的第一代防火墻功能：具有、（NAT）、協議狀態檢查以及VPN功能等。
(2) 集成式而非托管式網絡入侵防御：支持基于漏洞的簽名與基于威脅的簽名。IPS與防火墻間的協作所獲得的性能要遠高于部件的疊加，如：提供推薦防火墻規則，以阻止持續某一載入IPS及有害流量的地址。這就證明，在下一代防火墻中，互相關聯作用的是防火墻而非由操作人員在控制臺制定與執行各種解決方案。高質量的集成式IPS引擎與簽名也是下一代防火墻的主要特性。所謂集成可將諸多特性集合在一起，如：根據針對注入惡意軟件網站的IPS檢測向防火墻提供推薦阻止的地址。
(3) 業務識別與全棧可視性：采用非端口與協議vs僅端口、協議與服務的方式，識別應用程序并在執行網絡安全策略。
(4) 超級智能的防火墻: 可收集防火墻外的各類信息，用于改進阻止決策，或作為優化阻止規則的基礎。范例中還包括利用目錄集成來強化根據用戶身份實施的阻止或根據地址編制黑名單與白名單。
(5) 支持新信息流與新技術的集成路徑升級，以應對未來出現的各種威脅。
下一代防火墻工作流程：
數據包入站處理階段
入站主要完成數據包的接收及L2-L4層的數據包解析過程，并且根據解析結果決定是否需要進入處理流程，否則該數據包就會被丟棄。在這個過程中還會判斷是否經過VPN，如果是，則會先進行解密后再做進一步解析。
主引擎處理階段
主引擎處理大致會經歷三個過程：策略匹配及創建會話、應用識別、內容檢測。 創建會話信息。當數據包進入主引擎后，首先會進行會話查找，看是否存在該數據包相關的會話。如果存在，則會依據已經設定的策略進行匹配和對應。否則就需要創建會話。具體步驟簡述為：進行轉發相關的信息查找;而后進行NAT相關的查找;最后進行防火墻的策略查找，檢查策略是否允許。如果允許則按照之前的建立對應的會話，如果不允許則丟棄該數據包。
應用識別
數據包進行完初始的防火墻匹配并創建對應會話信息后，會進行應用識別檢測和處理，如果該應用為已經可識別的應用，則對此應用進行識別和標記并直接進入下一個處理流程。如果該應用為未識別應用，則需要進行應用識別子流程，對應用進行特征匹配，協議解碼，行為分析等處理從而標記該應用。應用標記完成后，會查找對應的應用，如果策略允許則準備下一階段流程;如果策略不允許，則直接丟棄。
內容檢測
主引擎工作的最后一個流程為內容檢測流程，主要是需要對數據包進行深層次的協議解碼、內容解析、等操作，實現對數據包內容的完全解析;然后通過查找相對應的內容安全策略進行匹配，最后依據安全策略執行諸如：丟棄、報警、記錄日志等動作。
數據包出站處理階段
當數據包經過內容檢測模塊后，會進入出站處理流程。首先系統會路由等信息查找，然后執行QOS，IP數據包分片的操作，如果該數據走VPN通道的話，還需要通過VPN加密，最后進行數據轉發。
與統一策略的關系
統一策略實際上是通過同一套安全策略將處于不同層級的安全模塊有效地整合在一起，在策略匹配順序及層次上實現系統智能匹配，其主要的目的是為了提供更好的。舉個例子：有些產品HTTP的檢測，URL過濾是通過代理模塊做的，而其他協議的是用另外的引擎。 用戶必須明白這些模塊間的依賴關系，分別做出正確的購置才能達到需要的功能，而統一策略可以有效的解決上述問題。
二、防火墻是否能阻擋住黑客攻擊？
答案：是否定的
下面我就說說原由！！！
首先傳統防火墻的缺陷：
1.傳統防火墻的并發連接數限制容易導致擁塞或者溢出
由于要判斷、處理流經防火墻的每一個包，因此防火墻在某些流量大、并發請求多的情況下，很容易導致擁塞，成為整個網絡的瓶頸影響性能。而當防火墻溢出的時候，整個防線就如同虛設，原本被禁止的連接也能從容通過了。
2.傳統防火墻對服務器合法開放的端口的攻擊大多無法阻止
某些情況下，攻擊者利用服務器提供的服務進行缺陷攻擊。例如利用開放了3389端口取得沒打過sp補丁的win2k的超級權限、利用asp程序進行腳本攻擊等。由于其行為在防火墻一級看來是"合理"和"合法"的，因此就被簡單地放行了。
3.傳統防火墻對待內部主動發起連接的攻擊一般無法阻止
"外緊內松"是一般局域網絡的特點。或許一道嚴密防守的防火墻內部的網絡是一片混亂也有可能。通過社會工程學發送帶木馬的郵件、帶木馬的URL等方式，然后由中木馬的機器主動對攻擊者連接，將鐵壁一樣的防火墻瞬間破壞掉。另外，防火墻內部各主機間的攻擊行為，防火墻也只有如旁觀者一樣冷視而愛莫能助。
4.傳統防火墻不處理病毒
不管是funlove病毒也好，還是CIH也好。在內部網絡用戶下載外網的帶毒文件的時候，防火墻是不為所動的（這里的防火墻不是指單機/企業級的殺毒軟件中的實時監控功能，雖然它們不少都叫"病毒防火墻"）。
下一代防火墻：
1.可以阻斷網絡攻擊，但不能消滅攻擊源。
防火墻能夠阻擋一定的網絡攻擊，但是無法清除攻擊源。即使防火墻進行了良好的設置，使得攻擊無法穿透防火墻，但各種攻擊仍然會源源不斷地向防火墻發出嘗試。例如接主干網10M網絡帶寬的某站點，其日常流量中平均有512K左右是攻擊行為。那么，即使成功設置了防火墻后，這512K的攻擊流量依然不會有絲毫減少。
2.不能抵抗最新的未設置策略的攻擊漏洞
就如殺毒軟件與病毒一樣，總是先出現病毒，殺毒軟件經過分析出特征碼后加入到病毒庫內才能查殺。防火墻的各種策略，也是在該攻擊方式經過專家分析后給出其特征進而設置的。如果世界上新發現某個主機漏洞的cracker的把第一個攻擊對象選中了您的網絡，那么防火墻也沒有辦法幫到您的。
3.本身也會出現問題和受到攻擊
防火墻也是一個os，也有著其硬件系統和軟件，因此依然有著漏洞和bug。所以其本身也可能受到攻擊和出現軟/硬件方面的故障。
4.同樣對待內網攻擊也是無法完全抵御
介紹了這么多，我相信大家應該也理解了，防火墻是入侵者進入的第一道安全防線，主要解決了經過防火墻的網絡傳播途徑的部分入侵攻擊問題，而通過物理傳播途徑，內網傳播途徑的攻擊就會很難解決，因此本篇文章希望通過我的介紹讓大家多了解防火墻這門安全技術和安全知識，提高咱們自身的信息安全意識，任何技術都有漏洞，有了漏洞必然就有機會攻克。所以我們需要擁有掌握技術的同時，更應該提高自身信息安全意識。
比Python，JavaScript才是更適合寫爬蟲的語言。原因有如下三個方面：
一、任務：爬取用戶在Github上的repo信息
通過實例的方式學習爬蟲是最好的方法，先定一個小目標：爬取github repo信息。入口URL如下，我們只需要一直點擊next按鈕就能夠遍歷到用戶的所有repo。
https://github.com/{{username}}?tab=repositories
獲取repo之后，可以做什么？
二、爬蟲雙股劍：axios和jQuery
axios是JavaScript中很常用的異步網絡請求庫，相比jQuery，它更輕量、更專業。既能夠用于瀏覽器端，也可以用于Node。它的語法風格是promise形式的。在本任務中，只需要了解如下用法就足夠了：
axios.get(url).then((resp) => {
請求成功，處理resp.data中的html數據
}).catch((err) => {
請求失敗，錯誤處理
})
請求之后需要處理回復結果，處理回復結果的庫當然是用jQuery。實際上，我們有更好的選擇：cheerio。
在node下，使用jQuery，需要使用jsdom庫模擬一個window對象，這種方法效率較低，四個字形容就是：笨重穩妥。
如下代碼使用jQuery解析haha.html文件
fs = require("fs")
jquery=require('jquery')
jsdom=require('jsdom') //fs.readFileSync()返回結果是一個buffer，相當于byte[]
html = fs.readFileSync('haha.html').toString('utf8')
dom= new jsdom.JSDOM(html)
$=jquery(dom.window) console.log($('h1'))
cheerio只實現了jQuery中的DOM部分，相當于jQuery的一個子集。cheerio的語法和jQuery完全一致，在使用cheerio時，幾乎感覺不到它和jQuery的差異。在解析HTML方面，毫無疑問，cheerio是更好的選擇。如下代碼使用cheerio解析haha.html文件。
cheerio=require('cheerio')
html=require('fs').readFileSync("haha.html").toString('utf8')
$=cheerio.load(html)
console.log($('h1'))
只需20余行，便可實現簡單的github爬蟲，此爬蟲只爬取了一頁repo列表。
var axios = require("axios")
var cheerio = require("cheerio")
axios.get("https://github.com/weiyinfu?tab=repositories").then(resp => {
var $ = cheerio.load(resp.data)
var lis = $("#user-repositories-list li")
var repos = []
for (var i = 0; i < lis.length; i++) {
var li = lis.eq(i)
var repo = {
repoName: li.find("h3").text().trim(),
repoUrl: li.find("h3 a").attr("href").trim(),
repoDesc: li.find("p").text().trim(),
language: li.find("[itemprop=programmingLanguage]").text().trim(),
star: li.find(".muted-link.mr-3").eq(0).text().trim(),
fork: li.find(".muted-link.mr-3").eq(1).text().trim(),
forkedFrom: li.find(".f6.text-gray.mb-1 a").text().trim()
}
repos.push(repo)
}
console.log(repos)
})
三、更豐富的功能
爬蟲不是目的，而是達成目的的一種手段。獲取數據也不是目的，從數據中提取統計信息并呈現給人才是最終目的。
在github爬蟲的基礎上，我們可以擴展出更加豐富的功能：使用echarts等圖表展示結果。
要想讓更多人使用此爬蟲工具獲取自己的github統計信息，就需要將做成一個網站的形式，通過搜索頁面輸入用戶名，啟動爬蟲立即爬取github信息，然后使用echarts進行統計展示。網站肯定也要用js作為后端，這樣才能和js爬蟲無縫銜接，不然還要考慮跨語言調用。js后端有兩大web框架express和koa，二者API非常相似，并無優劣之分，但express更加流行。
如上設計有一處用戶體驗不佳的地方：當啟動爬蟲爬取github信息時，用戶可能需要等待好幾秒，這個過程不能讓用戶干等著。一種解決思路是：讓用戶看到爬蟲爬取的進度或者爬取過程。可以通過websocket向用戶推送爬取過程信息并在前端進行展示。展示時，使用類似控制臺的界面進行展示。
如何存儲爬取到的數據呢？使用MongoDB或者文件都可以，最好實現兩種存儲方式，讓系統的存儲方式變得可配置。使用MongoDB時，用到js中的連接池框架generic-pool。
整個項目用到的庫包括：
試用地址：
https://weiyinfu.cn/githubstatistic/search.html?
案例地址：https://github.com/weiyinfu/GithubStatistic
原文鏈接：https://zhuanlan.zhihu.com/p/53763115
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
