Dumbcat's Note

GitHub在今年推出了基於GitHub Security Advisory API 的Dependabot，幫助使用者追蹤模組依賴關係、監控程式的安全性，並透過自動建立Pull Request來修正程式漏洞；以Python來舉例，使用者經常會使用requirements.txt來管理pip的模組，Dependabot可以自動偵測requirements.txt中具有安全性疑慮的模組版本，並通知使用者，以及自動建立Pull Request來協助使用者更新。 使用GitHub管理程式的人應該都有收過類似下面的信件，告知程式中有安全性漏洞並請使用者更新；因為我自己有些程式並不是完整的程式，可能只是一些功能的Demo，或者一些寫到一半的Memo，也或者某些模組更新後必須修改程式，所以我很懶得把程式Pull下來、更新漏洞、再Push回去，這些漏洞就會一直被放著，通知信件也會一直寄來。 所以GitHub很貼心的除了通知使用者之外，現在還可以幫助使用者直接線上修正，只需要點擊幾個按鈕；以下圖為例，如果程式中有漏洞，在進入Repository的頁面時，會看到一個安全性警告。 按下View security alert或者點選上方的Security頁籤都可以切換到安全性頁面，查詢安全性漏洞的詳細資訊；左上角會有一個Automated security fixes啟用或停用的選單，啟用的話Dependabot會自動幫你建立Pull Request，停用的話就要自己在每個Security Alert中手動建立。 這邊要補充一下， 在使用者的Setting下的Security可以開啟或關閉Automated security fixes，預設應該是開啟的(未勾選)， 但是在我的一些Repository中Automated security fixes還是關閉(Off)的，可能是因為Beta版本或者其他因素，使用者最好依照需求自己逐一檢查每個Repository是否有開啟。 回到Security Alert，這時候使用者可以點擊任意條通知查詢詳細內容，裡面會說明要更新那些東西、為何要更新等等，這時候我遇過三種可能的狀況。 成功自動修正漏洞 如果Dependabot成功的幫你自動修正了，在Security Alert中會出現提示，同時也會建立一個新的Pull

Introduction to NAT NAT(Network Address Translation)可以覆寫封包中來源或目的端的IP位址，通常出現在Layer 3的網路設備上，如路由器、防火牆、或者獨立的NAT伺服器；NAT初期是作為解決IPv4位址不足的問題而發展起來，在網際網路協定中，所有的設備必須要有自己的IP位址，通常也被稱做Public IP，但是整個IPv4的協定中只能提供約43億個Public IP，對於全世界的使用需求是遠遠不足的；所以IETF(Internet Engineering Task Force)組織推出了許多技術試圖盡量推遲這個狀況的發生，其中就包括了NAT技術，讓多個Private IP可以透過一個Public IP連接網際網路；雖然IPv4的耗盡對一般人來說似乎影響不大，但NAT技術發展至今已經成為一個廣泛使用的技術，不在只限於當初的目的， 透過封包偽裝、封包過濾提高資訊安全，或者透過負載平衡提高系統效能等。 基本的NAT分類可以分為1 to 1 NAT與N to 1 NAT，1 to 1 NAT是將一個Private IP轉換為一個Public IP，N to 1 NAT則是將多個Private IP轉換為一個Public IP；依據轉換的方式又可以分為Full-cone NAT、(Address)-restricted cone NAT、Port-restricted cone NAT、與Symmetric NAT，或者分為Static Translation、Dynamic Translation、與PAT (Port Address Translation)；總之在不同的設備或者服務中，NAT可能會有許多的分類方式，這就必須依靠使用者閱讀手冊去理解這些名稱了。 而我在工業領域的經驗中，對於將工廠設備連接網際網路，台灣大部份的工廠依舊是比較保守的，中小企業對於這樣的需求沒有太大的需要、大型企業則有資安上與架構變更上的疑慮在，所以目前會使用到NAT的情況，大多是用於工廠的第一層區域網路與第二層子區域網路之間的轉換，以解決第一層區域網路IP位址不足的問題。 在開始說明MOXA EDR Series NAT的應用與設定之前，有幾個重要的名詞與概念必須要先建立。 Inside與Outside 在一般的使用情況下，

MOXA MRC包含MRC Server、MRC Gateway、與MRC Clinet三部分，其餘兩部分說明請參考: [MRC] Moxa Remote Connect Server介紹與設定說明 [MRC] Moxa Remote Connect Gateway介紹與設定說明 MRC Client Software MRC Clinet software可以在MOXA官方網站下載最新版本，安裝完成後開啟MRC Clinet software，在Import activation file輸入從MRC Server下載的用戶金鑰檔，之後按下Apply。 套用檔案之後，下方應該會帶出用戶帳號資訊，之後可用Test Connection測試連線或Sign in登入MRC Server，下方的Signed In變為綠色表示成功登入MRC Server；Windows系統的使用者需用系統管理者的身分開啟MRC Client software，否則會因為權限不足無法驅動虛擬網路介面進行連線。 連線完成之後點選上方的Device Pool，可以看到目前在同Device Group中的MRC Gateway，並且以樹狀結構顯示透過該Gateway連線的網路設備；同時也可以看到這些設備的狀態，Status會顯示這些設備是否上線中，Tunnel用於連線到指定的設備，如果有啟用Auto IP Mapping，會顯示設備的虛擬IP，最後是設備的本地IP或MAC。 當使用者要連線某個設備時，點選該設備的Tunnel按鈕，當按鈕由紅色變為綠色，就表示該設備的通道已經建立，使用者可以依照MRC Gateway的模式透過虛擬IP或本地IP存取到設備。

MOXA MRC包含MRC Server、MRC Gateway、與MRC Clinet三部分，其餘兩部分說明請參考: [MRC] Moxa Remote Connect Server介紹與設定說明 [MRC] Moxa Remote Connect Client使用說明 MRC Gateway 有了從MRC Server下載的認證金鑰後，可以選擇三種方式設定Gateway，第一種是輸入金鑰文字，第二種是將金鑰檔案儲存在USB中，將USB插在MRC Gateway上，第三種方式是手動設定MRC Gateway；推薦使用第一種與第二種方式，但需要注意的是， 若使用USB儲存金鑰，一旦USB拔出MRC Gateway，連線會隨之中斷； 第三種方式因為設定選項基本上與在 MRC Server 上設定MRC Gateway相同，所以建議透過MRC Server設定即可，再透過金鑰將設定檔載入MRC Gateway。 設定完成金鑰後，需要對MRC Gateway設定所在地的時區。 如果透過金鑰設定MRC Gateway，就只需要這兩個步驟，完成之後金鑰會自動將設定載入MRC Gateway中，等設備重新啟動完畢之後，便可將MRC Gateway直接安裝於現場。 MRC Gateway上線之後，可以觀察面板前方LED得知MRC Gateway是否正常運作，一般版本的MRC Gateway由左上開始為USB狀態、電源狀態、網際網路狀態、雲端服務狀態、啟動金鑰狀態，右上為VPN連線狀態；LTE版本的MRC Gateway右邊會多SIM卡狀態、LTE信號強度；正常狀況下，所有燈號(除LTE信號強度)在正常狀態下應該都維持恆亮。

MOXA MRC包含MRC Server、MRC Gateway、與MRC Clinet三部分，其餘兩部分說明請參考: [MRC] Moxa Remote Connect Client使用說明 [MRC] Moxa Remote Connect Gateway介紹與設定說明 Moxa Remote Connect 過去對於現場的網路設備，設備工程師都必須連上現場網路之後，才可以進行維護、除錯、狀態檢測等工作；對於緊急的設備異常狀況，很難在第一時間了解狀況，進行排除； Moxa Remote Connect(簡稱MRC)提供了一種使用簡單、安全性高、且適用各種狀況的網路解決方案，針對工業應用的特性，使工程師無須抵達現場，就可以連接設備進行維護作業。 MRC結合了MRC Server、MRC Gateway、MRC Client三方面；MRC Gateway提供了高安全性的閘道機制，將乙太網路設備連接到網際網路上的MRC Server；MRC Client是一個輕便的軟體，可以將工程師的電腦連接到MRC Server；MRC Server則會負責安全的管理這之間所有的連線，透過MRC Server，工程師便如同在現場一般連線到網路設備當中進行檢修。 MRC的架構提供了諸多優點，諸如利用VPN的技術，打破過去網際網路與資安的對立，而且隨插即用的便利性使現場人員與工程師不需要VPN的專業知識就可以使用；同時也減少IT人員負擔，MRC不需要更改網路安全策略，且內嵌的防火牆可以設定允許遠端存取的白名單，既有的網路配置也不需要任何的更動，透過虛擬IP的映射技術，使所有被納管的設備都可以安全地被遠端存取。 MRC Server MRC Server提供了三層的管理架構，分別為系統管理者(System Administrator)、領域管理者(Domain Administrators)、群組管理者(Group Administrators)；系統管理者可以管理服務領域與領域管理者、網域管理者可以管理群組與群組管理者，群組管理者可以管理MRC Gateway、MRC Client、以及遠端連線。 領域會由系統管理者分配領域管理者、領域期限、與領域節點上限，節點代表每個連線到MRC Server的設備就為一個節點，系統管理者也可以針對領域進行各項管理；領域管理者

MVC在軟體工程中是個常見的詞彙，它所代表的是一種 架構模式(architectural pattern) ，例如Repository、Layered、Client-Server、Pipe & Filter都是一些常見的架構模式，架構模式是一種概念，用於解釋與描述軟體架構的一些必要的膠合元素(cohesive elements)。 MVC模式通常用於開發使用者介面的應用程式，由資訊呈現給使用者與從使用者接受的方式，來區分資訊在軟體內部的表達方式；MVC架構的目的是在於實現動態程式設計，降低後續對程式的修改、擴充的難度，簡化程式的架構，並且提升程式的重用性。 在MVC架構中軟體系統分為三個部分，模型(model)、視圖(view)、控制器(controller)；然而如同前面所說的， MVC是一個概念，並不是一個模型或者標準，這使得許多框架在實作自己的MVC架構時，對於三者所負責的功能或多或少有些許不同 (其中個議題引起相當大的迴響，模型與視圖之間到底會不會互動，有興趣可以參考— MVC是一個巨大誤會 )；撇開三者間太細節的定義，大致上可以區分三者的功能為: 控制器(controller): 介於模型與視圖之間，負責處理整個應用程式的流程控制。 模型(model): 負責資料的處理，例如資料庫的存取、資料的驗證與稽核等。 視圖(view): 提供使用者視覺化的介面，接收使用者的輸入或回覆應用程式的結果。 上圖是我認為比較客觀的MVC架構的流程圖；視圖會接收來自使用者透過介面所給的輸入，視圖會將這些輸入資料給控制器，控制器會將資料轉交給合適的模型，模型將資料處理完後所得的資訊傳給控制器，控制器會把資訊給合適的視圖呈現給使用者。 最後仍然必須再次強調，MVC是一個概念而不是標準，不同的語言、不同的框架在實作MVC模式時都會有不一樣的地方；重點在於如何實現動態程式設計，提升應用程式的擴充性與重用性，並降低其複雜度。