DataDomain: CVE-2020-1938,Port 8009的AJP漏洞

今天被通知在弱點掃描時,發現有一台EMC DataDomain有一個Port 8009的漏洞,查了Google後,應該是這個CVE-2020-1938的漏洞。

文件網址:https://www.dell.com/support/kbdoc/zh-tw/000020741/cve-2020-1938

剛好我們有兩台DataDomain,一台的DDOS是6.1.2.0,另一台是6.2.0.20,那要如何得知Port的使用情形呢?

我是用Linux的nmap來查看,執行指令如下:nmap 192.168.1.126 -F,可以發現DDOS 6.1.2.0的這台的確有開啟Port 8009



另一台DDOS 6.2.0.20的結果如下,果然Port 8009已經不見了



藉由這次的機會,學習了nmap的算基本使用。

Oracle REST Data Services(ORDS)安裝

 為了方便測試,我用Docker來測試,直接從Oracle下載好21c XE版DB的Image,並且將它啟動。

這台DB我有新建一個PDB是xepdb1,port:1521

簡述一下我的IP配置

Docker Hosting:192.192.192.10
ubuntu:172.17.0.2
Oracle 21c DB:172.17.0.3

因為不打算將DB與ORDS安裝在同一台server,所以再準備一台ubuntu的container來安裝ORDS,一邊學習一邊記錄。

1、先從Oracle下載ORDS的zip檔並解壓到ubuntu上。

2、在ubuntu上安裝JDK,我安裝的是Oarcle JDK 19並且在.bash_profile設定好變數JAVA_HOME與PATH

3、在ubuntu設定ODRS的環境變數

   # echo -e 'export PATH="$PATH:/<ords product folder>/bin"' >> ~/.bash_profile

4、第一次啟動前先設定ODRS configure:ords -–config <config folder> install,我的指令如下:

   # ords -–config /opt/ords/conf install

  接著就依照提示輸入相關的訊息,如IP、Port…等,其中有一項是要求administrator username,我用的是sys

   另外ORDS會問你是否start ORDS in standalone mode,我是選擇YES,所以安裝完後會自動啟動ORDS Service。

   ORDS除了可以standalone mode啟動外,也可以模組的方式應用在Oracle WebLogic Server、Apache Tomcat,之後如果有機會再來測試看看。   

5、完成上述的步驟後,基本上ORDS就安裝完成了,之後如果要重新啟動ORDS,可以下列的指定啟動:

   #  ords --config /opt/ords/conf serve


Oracle DB impdp匯入時出現ORA-39070

 我在Oracle 11gR2利用impdb匯入資料,語法如下:

$ imp user_a/xxx REMAP_SCHEMA=user_b:user_a directory=DUMP_DATA dumpfile=temp.dmp logfile=impdp.log

結果出現下列的訊息:

ORA-39002: invalid operation
ORA-39070: Unable to open the log file.
ORA-29283: invalid file operation
ORA-06512: at "SYS.UTL_FILE", line 434
ORA-29283: invalid file operation

看訊息好像跟log file有關,最後發現是資料夾的權限不足,記錄一下檢查的步驟。

檢查是否有建立Directory
SQL> select directory_name,directory_path from all_directories where directory_name='DUMP_DATA';

DIRECTORY_NAME                  DIRECTORY_PATH
---------------------------                -------------------
DUMP_DATA                           /testora/mes_data

確定有建立Directory後也檢查OS是否存在/test/ora/mes_data目錄,因為就算該目錄不存在,建立Directory也會成功

重新授予Directory的讀寫權限
SQL> grant read, write ON DIRECTORY DUMP_DATA TO user_a;  

重新impdp也是一樣的問題,最後是修改/test/ora/mes_data目錄的權限才解決,換句話說,如果無此目錄、目錄名稱錯誤、目錄權限錯誤都會出現上述的問題



用docker來執行firebase CLI login注意事項

 我想在docker container上執行firebase cli,在login時遇到了一些問題,故將步驟記錄下來。

1、我用node最新的docker image來建立container。

2、安裝firebase cli:npm install -g firebase-tools

3、為了避免時區的問題,所以在建立container時一併指定了時區;firebase login會用到port:9005,所以我的指令如下:

   # docker run -it -p 9005:9005 --name firebase_cli -e TZ=Asia/Taipei firebse_cli /bin/bash

4、在cli下執行firebase login時,因為認證會轉到localhost,所以會無法成功,可改用firebase login --no-localhost,用取得authorization code的方式登入

 


Solaris掛載LUN時,以format指令發現drive type unknown

 我們有一台Storage是vnx5100,有一個2TB的Lun掛到Solaris上,以format檢查磁碟時發現如下圖有<drive type unknown>



參考文件如下網址,應該是Host ID的問題
https://www.dell.com/community/PowerPath/how-to-clean-devices-are-seen-by-the-format-in-solaris-removed/td-p/6811091

所以我登入vnx5100 -> Hosts -> Storage Groups,如圖


發現這個Host LUN ID的確不是0 ,所以我把這個LUN在「Selected LUNs」中按下Remove與Apply,以移除Lun,再從「available LUNs」中選擇LUN0並按下Add與Apply,重新加入,此時Host LUN ID預設就變為0,如下圖


之後再回到Solaris,可以發現已成功抓取到LUN了。




EMC DataDomain登入時出現 HTTP Status 404

 今天要登入EMC DataDomain時一直無法登入,但是CLI登入卻又是正常的,因為不知道原因,所以就把DataDomain重開機,重開完成後,要登入Web管理介面時卻出現了Http Status 404的錯誤。


最後找到文章說可能是憑證失效了,重新產生憑證後就恢復正常了。

# adminaccess certificate generate self-signed-cert regenerate-ca


EMC DataDomain重建Replication ,出現Error

事件:DD Replication出現Error的錯誤

注:我是參考手冊與測試得出的結果,故將此事件記錄下來,如觀念有錯,請以官方文件為主

因為一直無法恢復正常,所以Disable Pair再Enable Pair也是出現Error,而訊息中有提到可能需要重建Replictaion

我把Replication Pair Delete後,想要重建一個新的Replication,但是卻出現Mtree already exists


環境是有兩台DD,分別為DD1、DD2,其中DD1是源系統,只做一對一的複製。

如果在新建Replication時,設定DD2一個新的mtree,此時兩台DD會從頭開始同步,如果網路速度有限,在擁有龐大的資料量下,此方案並非好選擇。

因為DD2還存有原本的資料,只是Replication需要重建,所以應該會有其他的方案。

在DD2登入CLI,輸入mtree list,可以發現下列的資訊:


其中/data/col1/backup_DD3300-1的status是「D」,這是我之前手動刪除了這個mtree,在還沒有執行filesys clean的情況下,mtree僅是被註記。此時新建的Replication如果指定相同的名稱「backup_DD3300-1」,一樣會出現Mtree already exists的錯誤訊息,僅管在Web的管理介面上已經看不到這個mtree。

要解決這個情況,只要手動執行clean,當然你如果有設定clean的排程,也可以等待排程自動執行。下列指令是執行與停用clean,如果只是要刪除status為「D」的mtree,不用等到clean作業完成,只要等待一至兩分鐘,就可以停用clean(如果你的clean很快完成,就不需要停用了)

# filesys clean start

# file sys clean stop

 

因為在DD2上已經有Error之前的同步資料,所以改用另一個方案。

一樣在DD2的CLI執行mtree list

 

Status為「RO/RD」表示是mtree是屬於Replication Destination,此時我們把Replication Pair刪掉後,則Status會變成「RW」,因此該mtree會變成獨立。也因為如此,在新建Replication時,是無法在DD2指定相同的名稱。

選擇Start Resync,接著步驟與新建Replication一樣,而且可以指定DD2已存在的mtree,它會警告如果與源資料不一致,會同步DD2的資料。

CLI指令為:replication resync destination


 

設定完成後,因為DD2已存有Error前的同步資料,所以原本需要同步5T的資料,只需要70G即可