靜默冥思@技術本位

2017年8月8日 星期二

第三方支付

上個月去了一趟大陸,大陸的微信支付幾乎無孔不入,連路邊賣包子饅頭的店都能使用微信支付,甚至給剛認識的人打錢分擔餐費,便利性讚不絕口;反觀台灣,一直自詡是資訊大國,但是Line Pay, Apple Pay被很多的政治問題給干涉,導入時間嚴重延後,於技術無關的誰得利問題,在央行和外資間打轉.

早在好幾年前,電商這一塊,我就在雅馬遜上買過、在Steam上面買過,跨國最強大的第三方支付,無異於就是Paypal,它是Elon Musk現實世界鋼鐵人人生最重要的軌跡之一,雖然他現在把重心都擺到特斯拉去了.

不得不佩服Paypal,因為它比任何一間國內銀行的資安水平都要高,光看憑證就能略知一二.重點,即使再手機上進行Paypal的跨境支付,仍舊很安全,但是其他銀行和第三方支付的APP其資安的程度就良莠不齊了.公家開發的第三方支付,很多更是沒有在資安上下足功夫(https://www.inside.com.tw/2017/06/30/pay-taipei-2),直接明碼曝曬個資的情況屢見不鮮,對此感到擔憂.這做法像足了遊戲廠商的開放測試,由社會大眾來協助Debug,代價是你的個人資料.

日媒針對中國第三方支付興盛此事有不同見解(http://news.ltn.com.tw/news/world/breakingnews/2156128),認為中國普遍流通的假鈔太多,產生對於鈔票的不信任問題.兩年前過境日本,我曾經深入研究為何日本人沒有偽鈔,其中有三點:第一、日本鈔票防偽技術非常高端;第二、日鈔使用的紙漿來源為日本特有種樹木;第三、鈔票的製作成本與面額相若.於是導致了日本有著全世界最難偽造的鈔票,換另一句話,沒有人願意偽造日鈔,因為得不到實質上的好處,這點從人性根本上防偽,令人景仰.

對於鈔票的信任,所以日本人並不仰賴第三方支付,因為他們不可能收到偽鈔;對於鈔票的不信任,導致中國需要大量仰賴第三方支付,微信上面的數字,遠比紙鈔加上驗鈔機強,至少他們背後有著靠山.

談談第三方支付的優缺點.第三方支付優點,講白一點,就是交易金額的託管商,不管是B2C還是C2C中,都大幅度的提升雙方的信任問題.不會讓電商交易,進入一種到底先交貨還是先付款的無窮迴圈問題;甚至在一定程度上可以避免詐騙,但是要注意,境外第三方支付的不一定有辦法拿回.

缺點,越來越多的第三方交易把實名制納入,中國更大舉把支付寶和微信納入網聯(銀聯的隨附組織),換句話來說,錢你們賺,個資部分銀聯全拿走,中國官方可以看到一切的交易內容和個資.或者這舉動,或引發境外旅客或商貿減少跟支付寶和微信的互動關係,不過待觀察,畢竟這件事才剛發生.不過相對於此事,蘋果有著全然不同的作法,即便是FBI以國安為由要求蘋果解鎖裝置,蘋果也不願意,顯然蘋果更把個資視為本身資產,但是對於消費者來說,實名制只會有一種下場,消費者個資在誰手裡的問題而已.

但是第三方支付的缺點,同時也是網路交易的優點,因為只需要信任第三方支付的平台媒介,就能完成金流動作,並且從中保障交易雙方的權益,對於網路金流問題來說,是一帖良藥.尤其那些雨後春筍冒出的電商交易的網站,第三方支付有著巨大的引響力,畢竟他可以直接信賴這些第三方交易的金流處理,把最困難解決的問題簡單化.


總結來說,第三方支付存在著強大的便利性,尤其是如果它跨了電商也跨了生活圈,有點像手邊的悠遊卡同時具備可以對實體通路消費、對虛擬通路消費、對公營單位繳費、對其他客戶轉費用的功能,有著強大的便利性,當然得擔一點個資的風險.




2017年5月17日 星期三

關於資安這件事


最近wannacry弄得大家人心惶惶,但是我想告訴大家的是,其實如果有養成良好的習慣,綁架軟體並沒有想像中可怕;還有可以透過一些資安政策,避免類似的攻擊手法。

其實SMB協定,非常被泛用在一般資訊領域,尤其在NAS或是NFS系統上,因為他透過了簡易的方式共享了檔案。很早以前,它依存在NetBIOS協定之上,NetBIOS over TCP/IP這項協定在XP之後大量的被使用,就像各位所熟知的網路上的芳鄰。但由於NetBIOS本身的設計上面就有許多的資安漏洞,所以微軟一直想要拋棄這項舊包袱,但是多數的使用者依賴性,導致現在還是存在,並且泛用在一些組織中。

這次被攻擊的主角是SMB協定,而且是主動被攻擊,所以像是本人的NAS也有受到來自四面八方的攻擊者測試存取NAS,由於SMB直接對外開放。而且可以看得出來攻擊端的對外跳板來自於俄羅斯、香港、北非(經IP地理資訊系統對照,雖然未必精確),而且使用帳號測試密碼嘗試存取SMB服務。而且可以發現,駭客其實是熟知資安的專家,它不會密集高頻的測試你的admin密碼,大約是五分鐘測試五次,而且各種可行帳號都會輪流測試(例如: GUEST或是Root);而密碼測試的部分,我猜是使用了字典攻擊。

為什麼會低頻的測試?
迴避了資安部分的原則(Policy),例如:我的資安原則是”在一分鐘內,測試該帳號十次登入失敗,即禁止該IP連線30分鐘。”
如果被阻擋IP,它一小時只能測試我單一帳號20次密碼。
如果使用低頻,例如五分鐘內測試五次密碼,它一小時內能試60次。
可以有效降低暴力破解的時間。

當然像其他重要的密碼原則,如同:密碼複雜化、定期更新密碼、密碼不得重複等資安政策落實,都會延展駭客暴力破解密碼的時間。最害怕的就是,並未關閉那些具有管理權限的帳號又沒有設定密碼,那很容易的SMB漏洞,就淪為被攻擊的羔羊。

所以我們在上述的紀錄檔稽核過程中,可以知道,我們需要延展資安原則,例如:在半小時內,測試該帳號十次登入失敗,即禁止該IP永久連線;直到管理者手動解禁。我們需要落實密碼原則,關閉預設的帳號(Admin和Root即應立刻停用,以其他實名帳號替之),立即將駭客IP打入永久禁止連線黑名單,以防堵再次被密碼測試。如果企業組織有更強大的IDS或IPS系統,可以建立更為完善的防堵規則,那便可更有效率的自動阻擋類似攻擊。

我還記得以前老師在課堂上面說過,最安全資料儲存方式就是將資料置於永不揮發的記憶裝置,或者硬碟、光碟中,並將其置於安全的保險庫內。

任何裝置能以任何方法連上網際網路,從該刻起,所有資料即非絕對安全。所以在雲端的任何資料,都不能說是完全靠譜。雲端上面的資料,具有一定程度的可靠性,通常會具有版本回朔跟定期備份的功能。但是,他無法保證任何的隱私權,因為如果它的系統有漏洞導致資料外洩,就像先前SONY跟APPLE都曾發生過大規模被盜用個資和雲端儲存資料的問題。

備份這件事情比任何事都重要,但是資料分成兩種,第一種是具有隱私成分的個資、機密資料,會建議離線儲備,會比在線儲備安全,例如:透過硬碟、磁帶、內部私有雲,使用異地的方式做存放。另一種是不具個資的例行性資料或是交易資料,這種可以透過網路或外部裝置進行備份,例如:各種公有雲或外部雲。


不要過於信任任何種類的用戶端防毒軟體,防毒軟體是一種極為消極的防禦方式;如果是在企業內部,應該利用體制(例如:資訊安全規範),來約束員工,並且制定可追蹤跟稽查的紀錄,來防止員工瀏覽高危險網域。當然,配合IPS與IDS防禦,Mail SPAM的黑白名單制定,遠比防毒軟體要來得有效。

為什麼不要過度信任防毒軟體,因為防毒軟體是有毒它才能防禦、才能提供對應的解決和移除,沒有一種防毒軟體可以對抗一種還沒有公開過的病毒的,再者本人認為防毒軟體本身就是一種毒,因為它會變相的拖累用戶端的效能,不管何種防毒幾乎都是常駐程式,既然是常駐程式沒有不耗損資源的。還有,防毒軟體時常過度誤判,導致防毒效果越好的軟體會經常性的誤殺可能需要的執行檔或是文件;以及病毒碼空窗期,如果非定時更新病毒碼,難道那段時間就不會有中毒風險嗎?連Windows Update微軟都承認有空窗期了。

良好的規範可以導正試用者習慣不去點擊危險連結、不造訪危險網站,這點遠比任何的軟體要強,甚至有效;因為這個習慣,絕對可以避免中毒。
曾經看過客戶把整台伺服器的軟體防火牆關閉,然後裝上防毒軟體;這是一種不可取的行為,因爲防火牆是相當積極的防禦手段;而防毒軟體是相當消極的防禦手段。就單以這次的檔案綁架來說,如果你防火牆政策是白名單,老實說根本就無懼於wannacry,我很少見過企業組織會開啟對外的SMB協定,除了一些IT非常消極的公家單位外。

這篇文章大概只寫出資安問題的冰山一小角,更大的問題在於:垃圾郵件、DDOS、木馬程式、假冒DNS、假冒網站、縮址與轉址、危險附件、檔案勒索...。

2016年11月4日 星期五

針對Citrix AMC(Access Management Console)使用者清單消失問題之解決方案


問題環境:Citrix XenApp 4.5/5.0 For Windows Server 2003
問題描述:Citrix AMC(Access Management Console)使用者清單消失
錯誤訊息:



如需叫用 Just-In-Time (JIT) 偵錯的詳細資料,
請參閱本訊息結尾處 (而非這個對話方塊) 的資訊。

************** 例外狀況文字 **************
System.NullReferenceException: 並未將物件參考設定為物件的執行個體
...(下略)

解決方案:
I was getting this error with a new 4.5/Win2003 farm when trying to navigate through servers or published applications in the Management Console. The AMC wouldn't show users connected and then the .net error would randomly pop up.

Just by luck I tried; View-> Set Accessibility Options-> Use Defaults and it all works now. I didn't note the previous settings.
解決情況:已解決


2016年10月17日 星期一

About Citrix Database Migrate


在Databese老舊或汰換可能情況下,很多客戶會考慮Database的移機。

如果以Citrix架構來說,會建議從幾個面向來考慮。
1. 舊有伺服器Database是否有定期備份;如果沒有,移機前務必先備份。虛擬機建議snapshot一併執行。

2. 是否為異質平台的移機,如果僅是MS-SQL舊版轉移到MS-SQL新版,通常不會面臨太大的挑戰。例如Oracle轉移到MS-SQL,建議使用備份檔先做測試。

3. 是否有足夠的停機時間,需要下指令讓DB轉置,會停止IMAService一段時間,並再恢復服務後進行測試,如果停機時間不足,或者不允許長時間停機,可以考慮直接建立新的Database而非移機。

4. Farm內發布Application的數量是否為大量,或者僅是少量發布。如果是大量發布,那Database的移機需要長時間規劃跟測試;如果是少量App,建議直接重建Database而不移機;優點是,可以在服務不中斷的情況下提供測試和切換,比起移機來說風險比較低。

5. Citrix 的Database本質上不會面臨到IOPS的問題,因為只負責存放Application相關的設定資料,發派給那些人或群組權限為何,大多脫離不了這圈子。如果Databse有問題或短期離線,會造成無法修改應用程式設定的情況,但是不至於馬上衝擊服務,因為XA Server會有相關的XML暫存文件會描述這些事情,除非使用者從未使用過相關應用程式沒有留下XML快取。
因此,針對Citrix Databse安裝可以放在VM上面,未必要使用實體機。

2016年9月30日 星期五

轉換現有的 Windows Server 2012 版本與啟用產品金鑰

安裝 Windows Server 2012 之後,您可以隨時執行安裝程式來修復安裝 (有時候也稱為「就地修復」),或者,在特定情況下,它可以轉換為不同的版本。
您可以在任何版本的 Windows Server 2012 上執行安裝程式來執行「就地修復」;結果會是您一開始使用的相同版本。
對於 Windows Server 2012 Standard,您可以將系統轉換成 Windows Server 2012 Datacenter,方法如下:從提升權限的命令提示字元,執行 DISM /online /Get-CurrentEdition 來判斷目前的版本名稱。記下版本識別碼,它是版本名稱的簡短形式。然後執行 DISM /online /Set-Edition: /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula,提供版本識別碼和零售版產品金鑰。伺服器將重新啟動兩次。
如果是 Windows Server 2012 Essentials,您可以執行安裝程式,提供適當的零售授權金鑰,將它轉換成 Windows Server 2012 Standard。

微軟參考網址 

2016年9月2日 星期五

XenServer常用指令與開關機計畫


常用指令部分

全指令取得
xe help --all

xsconsole 互動設定選單


如何得到主機的UUID
[root@xenserver-eric ~]# xe host-list
uuid ( RO)                : 8b165643-8a3d-4ff5-9819-41df3368e818
          name-label ( RW): xenserver-eric
    name-description ( RW): Default install of XenServer

如何得到VM的UUID
[root@xenserver-eric ~]# xe vm-list
uuid ( RO)           : 32a852eb-e70a-1adc-7830-2911e2ead625
     name-label ( RW): 0_AD.sciformosa.tk_Win 2012 R2 (64-bits)_192.168.0.201
    power-state ( RO): running
(注意該指令會列舉)

VM詳細參數列舉
xe vm-param-list uuid=

如何將指定VM關機:
xe vm-shutdown vm="VM主機名稱"
xe vm-shutdown uuid=

如何將XenServer主機關機:
xe host-disable uuid=<主機UUID>
xe host-shutdown uuid=<主機的UUID>

如何將指定VM開機:
xe vm-start uuid=
xe vm-start vm="VM主機名稱"

以下的指令只有在有HA架構時有用,請務必注意。
Re-enable the VM autostart feature for the pool object:
xe pool-param-set uuid=UUID_OF_THE_POOL other-config:auto_poweron=true

Set the following parameter for VMs you wish to have automatically starting:
xe vm-param-set uuid=UUID_OF_THE_POOL other-config:auto_poweron=true

文字編輯器與時區修改(時區也可以用xsconsole)
vi /etc/ntp.conf

Server Log 查詢
cat /var/log/xensource.log
cat /var/log/message
(注意cat會列舉,建議配合grep執行)
例如:cat /var/log/xensource.log | grep shutdown
意即尋找xensource.log文件中帶有shutdown關鍵字的資料筆數列舉

如何製作一個XenServer開關機計畫
(主要功能為vApps)
建議使用GUI介面編輯


可以新增一個vApps。


最重要的是調整每個VM的Start Order(開機優先序,小的在前面);和Delay Interval(延遲秒數,前一個順位開機過後多久,才啟動它)。
*計畫要注意,AD與DNS的優先序最高(數值最小),接著是Xen的License Server,Xen的DB,Xen的DDC,Xen的其他APP Server與VDA,最後才是測試機(或許測試機不宜加入此計畫中)。


最這樣就完成一個vApps的編輯了,記得,這個順序是雙向的,可以開機也能夠關機,關機順序會顛倒過來,從Start Order最大的開始關機。

XenServer開機(或重開機)後如何自動將上面運行的VM開機呢?

如何在XenServer開機流程中,自動加入vAPP開機序步驟:
Step 1. 利用GUI建立vAPP
Step 2. 在cli介面下達xe appliance-list指令查詢vApps的UUID


[root@xenserver-eric ~]# xe appliance-list
uuid ( RO)                  : 52d05820-f7a6-75f5-5be9-bb4df302d1f3
            name-label ( RW): AD
      name-description ( RW): AD boot
                   VMs (SRO): ebeac105-cb55-ccb7-bff7-e7cb8d67d852; 8ea457bf-2cb3-db23-09c5-f50165e4522e; 32a852eb-e70a-1adc-7830-2911e2ead625
    allowed-operations (SRO): clean_shutdown; hard_shutdown; shutdown
    current-operations (SRO):


Step 3. 使用指令vi /etc/rc.local打開rc.local編輯

在文件末端加入以下兩行(按i進入insert模式)
sleep 40
xe appliance-start uuid=
按Esc離開編輯模式後存檔(下:wq) *wq意指存檔後離開,如果不存檔離開請使用q!
詳細 vi編輯器相關指令可參考鳥哥:http://linux.vbird.org/linux_basic/0310vi/0310vi.php
Step 4. 重新開機自動會生效

這樣就完成了一個自動關機與開機計畫了!