主要介紹了一些各品牌防火牆配置自動化生成的思路，功能包括核查現有配置，判斷是否需要新增配置，以及自動生成新增配置命令。並且在新增配置中，如何有效結合調用現有配置，避免在自動化生成的過程中引起防火牆配置量的野蠻增長，產生大量冗余配置。
1，ACL配置命名規范
自動化執行一個ACL需求時，需要輸入一個唯一的編號（可以跟隨需求單），命名過程中會使用到，太長的話，天融信防火牆命名可能會報錯，推薦字母+六位數字，例如A000001
為了不影響存量配置，建議所有自動化的匹配規則全部都在規范命名后的地址組/端口組/ACL組內開展
防火牆自動化之前，必須要明確ACL命名的規范性，否則自動化無從談起，甚至還會影響生產
以下面需求為例：
需求單A000001： 源地址（10.10.10.1, 10.10.10.2）；目標地址（20.20.20.1, 20.20.20.2）；目標端口（TCP: 80，443）；
需求單A000002： 源地址（10.10.10.3, 10.10.10.4）；目標地址（20.20.20.1, 20.20.20.2）；目標端口（TCP: 80，443）；
需求單A000003： 源地址（10.10.10.5, 10.10.10.6）；目標地址（20.20.20.1, 20.20.20.2）；目標端口（TCP: 80，443）；
需求單A000004： 源地址（10.10.10.1, 10.10.10.2）；目標地址（20.20.20.1, 20.20.20.2）；目標端口（TCP: 80，443，8443）；
需求單A000005： 源地址（10.10.10.3, 10.10.10.4）；目標地址（20.20.20.1, 20.20.20.2）；目標端口（TCP: 80，443，8443）；
需求單A000006： 源地址（10.10.10.5, 10.10.10.6）；目標地址（20.20.20.1, 20.20.20.2）；目標端口（TCP: 80，443，8443）；
需求單A000007： 源地址（20.20.20.1, 20.20.20.2）；目標地址（10.10.10.1, 10.10.10.2）；目標端口（TCP: 80，443）；
假設源地址接口是outside，目標地址接口是inside
怎么建地址組/端口組合適呢？
1.1，端口組
cisco：如果是訪問一個端口，不用創建端口組，直接eq ...。如果是開通多個端口，必須建立端口組，才能被ACL調用。
juniper/華為/天融信：可以在ACL中直接調用端口，因此建議不用建端口組了。自動化時直接在ACL中羅列開通端口即可，其中juniper/天融信需要事先為端口自定義一個名稱，華為連名稱都不用定義。
cisco多個端口需要定義端口組，但是處理也比較簡單，不用和本次開通單號做關聯，可以搜索現有的自動化端口組名稱（不建議調用非規范命名的端口組），有則調用，沒有則新建。
以A需求為例，如果不存在包含80，443端口的TCP端口組，則新建端口組：pg_A000001。(如果是UDP可以建pgu_A000001)
后續如果是開通TCP80，TCP443的，可以直接調用端口組pg_A000001
后續如果是開通TCP80，TCP443，TCP8443的，不允許往pg_A000001中添加8443，然后再調用pg_A000001。而應當根據需求單號，新建一個地址組。
不允許往現有規范命名的端口組內加成員！！！
1.2，地址組
需求單A000001： 源地址（10.10.10.1, 10.10.10.2）；目標地址（20.20.20.1, 20.20.20.2）；目標端口（TCP: 80，443）
假設根據開通單號A000001，命名為：
A000001_src（10.10.10.1, 10.10.10.2）
A000001_dst（20.20.20.1, 20.20.20.2）
pg_A000001（80, 443）
access-list outside extended permit tcp object-group A000001_src object-group A000001_dst object-group pg_A000001
需求單A000002：
需求單A000002： 源地址（10.10.10.3, 10.10.10.4）；目標地址（20.20.20.1）；目標端口（TCP: 80，443）
需求單A000002和需求單A000001的目標地址/目標端口完全一樣
根據1.1，端口組可以直接調用現有的pg_A000001
地址組如果不考慮融合現有策略，完全新建：
A000002_src（10.10.10.1, 10.10.10.2）
A000002_dst（20.20.20.1, 20.20.20.2）
pg_A000001（80, 443）
這樣，配置量增長會非常快，如果有100個需求單都是訪問20.20.20.1, 20.20.20.2的80和443端口，源地址/目的地址/acl都會被重復創建100遍。但其實這100條ACL完全可以融合成1條ACL。
那如果選擇融合，直接將需求單B的源地址（10.10.10.1, 10.10.10.2）加到A000001_src，這樣可行嗎？
可能存在如下問題：
1）如果該源地址組被其他ACL調用，則可能擴大了其他ACL的訪問范圍， 假如存在10.10.10.1, 10.10.10.2訪問100.100.100.1的需求，其中10.10.10.1, 10.10.10.2地址組名稱用的也是A000001_src
2）更糟糕的是如果被反方向deny調用，則可能影響現有系統的訪問，例如存在deny 某些地址(inside) 訪問 A000001_src(outside) 的ACL
因此：
地址組名稱可以被反復調用和地址組名稱可以添加成員是一對矛盾
可以被反復調用就不允許添加成員，可以添加成員就應該禁止被反復調用
指定如下地址組命名規范:
目的地址組名稱: 所在防火牆接口_開通工單， 可以被其他"同方向"ACL調用但禁止添加成員（"同方向"，意味着只能作為目的地址被調用）
源地址組名稱: to_目的地址組名稱_開通工單， 禁止被其他ACL調用但可以往里面添加成員
1.3，規范后的開通單案例
根據1.1-1.2，前述需求單A000001-A000002可以做如下命名：
需求單A000001：新建源地址組 to_inside_A000001_A000001，新建目的地址組inside_A000001，新建端口組pg_A000001
需求單A000002：將10.10.10.3, 10.10.10.4添加至to_inside_A000001_A000001
需求單A000003：將10.10.10.5, 10.10.10.6添加至to_inside_A000001_A000001
需求單A000004：新建源地址組to_inside_A000001_A000004，新建端口組pg_A000004
需求單A000005：將10.10.10.3, 10.10.10.4添加至to_inside_A000001_A000004
需求單A000006：將10.10.10.5, 10.10.10.6添加至to_inside_A000001_A000004
需求單A000007：新建源地址組to_outside_A000007_A000007，目的地址組outside_A000007
注意
需求單4：由於目的地址組inside_A000001已經創建過，可以直接調用，但是端口組和源地址組需要新建
需求單7：即使20.20.20.1, 20.20.20.2和10.10.10.1, 10.10.10.2都已經被創建過，但是方向不同，都不能拿來調用，需要全部新建
實際上：就是把 "接口+目標服務器+端口" 綁定起來看作一種"服務"，后續需求單如果是訪問已有的"服務"，就可以往該"服務"的"客戶端(即源地址)"內添加。如果該服務不存在，就需要新建。
這樣可以在 "完全不融合導致配置野蠻增長" 和 "融合太緊密導致放寬策略或者出現問題" 做個折中
1.4，存在PAT時的命名
PAT策略的地址組名稱，不應該調用ACL組名稱
2，ACL配置自動化的思路
主要涉及模塊：
1）配置采集
2）配置解析
3）策略分析，策略分析又包含路徑分析，策略核查，配置生成模塊
3，配置采集
配置采集通過paramiko定制腳本，獲取防火牆配置文件。
4，配置解析
對各品牌防火牆（思科、天融信、juniper、華為）不同版本的防火牆配置文件進行解析，轉換為三張表格：
表格一：地址表，記錄地址組名稱和地址組成員的對應關系
表格二：端口表，記錄端口組名稱和端口組成員的對應關系
表格三：ACL策略表，記錄ACL主要信息
備注:
不同品牌防火牆記錄信息會有差異，例如地址表中juniper需要記錄區域信息
主要采用正則表達式 + pandas每天定時對防火牆配置進行讀取和解析，供后續模塊調用
返回的類型是表格， 可以通過excel， json， 數據庫保存。數據庫有點大材小用，excel表格單元格內數據量太大無法保存(例如地址組中有conf列會記錄該地址組相關配置，如果成員數量過多就無法顯示)，推薦用json，后續模塊調用時可以直接將json轉pandas。
5，策略分析
5.1，路徑生成模塊（需要結合公司實際場景定制）
直接調用配置生成模塊，不僅需要提供防火牆名稱，防火牆端口等信息，如果涉及多個防火牆，還需要逐一羅列，對運維人員交互不友好
因此還需要結合公司實際網絡環境，定制各網段間訪問的關系，例如A網段訪問B網段經過哪幾個防火牆，以及分別是涉及防火牆的哪幾個接口，思科防火牆的入向策略名等等
如果網絡環境比較復雜可能全部羅列比較困難
對於HUB-SPOKEN有環形網的場景，可以通過記錄每個網段到環形網經過的防火牆(以及相應接口)，這樣所有通過環形網互相訪問的網段就無需逐一羅列，同時再補充一張不經過環形網的特殊訪問表即可
5.2，策略核查模塊
策略核查模塊針對輸入的ACL訪問需求，做如下核查:
1)檢查源地址、目的地址、目的端口， 三元素完全一致的ACL，返回所有命中的ACL(包括)
2)檢查目的地址、目的端口，兩個元素完全一致的ACL，並且目的地址組命名符合第一章的命名規范的(添加源地址時避免影響存量不規范配置)，返回該ACL所有信息
備注：這里只是做最簡單的描述，實際實現時，還涉及到協議tcp/udp，而且不同防火牆需要的acl字段也有差異，思科只需要傳策略名，其他品牌防火牆還有源區域和目的區域等等。
5.3， 配置生成模塊
這塊比較簡單，主要是結合策略核查模塊的結果，以及各品牌防火牆的配置命令，做如下三步：
1)三元素完全一致的ACL，並且第一條是permit的，直接反饋現有配置，無需新增配置
2)三元素中有目的地址、目的端口，兩個元素完全一致的ACL，直接將需求中的源地址往現有源地址組名稱中添加
3)根據本次工單號，依據命名規范，新增配置。新增配置時需要考慮是否有現有的目的地址組，端口組(思科)可以調用
后續會逐一對各模塊實現細節和相應代碼進行展開分析