在Kali Linux上安裝GVM 22.9

 事情是醬子的，突然覺得可以改成叫GVM安裝日誌。

這次因為需求進行弱掃時發現一堆Report outdated / end-of-life Scan Engine / Environment。

內心OS：版本又過期了阿。

好吧，更新看看

 yum update -y

沒有任何動靜，於是立馬跑去Atomicorp的Github看看。

在issue可以看到不少鄉民也有類似問題22.4.1 is End-of-Life

看來作者應該是忙到沒時間幫忙打包更新了。

經過一番Google大神爬文後，我下定決心改投入Kali Linux的懷抱。(X

安裝方式也非常簡單，可以參考鄉民寫的詳細教學 - 如何在ESXi 安裝Kali Linux. Kali Linux

在Kali Linux上安裝GVM真的是非常非常容易。

1.檢查更新

sudo apt-get update

sudo apt-get upgrade

sudo apt-get dist-upgrade

2.安裝GVM

sudo apt-install gvm

3.執行設定

sudo gvm-setup

※注意：預設管理者帳號、密碼會在此時建立，記得先複製起來，不然等下會無法登入。

4.啟動GVM

sudo gvm-start

5.檢查設定是否有錯

sudo apt-check-setup

6.更新FEED

sudo greenbone-feed-sync

7.打完收工

正當以為要打完收工時，此時才發現無法從外部主機登入，正確地來說只能在本機裝置上使用https://127.0.0.1:9392 登入，趕快Google爬文一下，才發現鄉民指出要修改設定。

7.1先停止服務

sudo gvm-stop

7.2修改設定檔

sudo nano /usr/lib/systemd/system/greenbone-security-assistant.service

將listen 127.0.0.1 修改為0.0.0.0

7.3啟動服務

sudo gvm-start

然後就可以開心地去修漏洞了。

參考來源：

https://www.kali.org/tools/gvm/#gvm

https://forum.greenbone.net/t/cannot-connect-to-the-gvm-

host/10855

https://github.com/Atomicorp/gvm/issues

https://medium.com/@jieshiun/%E5%A6%82%E4%BD%95%E5%9C%A8-esxi-%E5%AE%89%E8%A3%9D-kali-linux-12f121bea3d2

GVM Web Client Session Time Out

 事情是這樣子的

就在安裝好GVM之後，可以正常掃描，報告也可以順利產出，同事跑來說SESSION TIME OUT 可不可以設定長一點，一下就登出 非常麻煩。XD

看了一下右上角的設定，似乎沒有翻到可以設定SESSION TIME OUT地方，爬了一下網路大神的文章才發現，只要去修改一下啟動服務，加上 --timeout=1440。(1440可以改成您希望的時間)

vi /usr/lib/systemd/system/gsad.service

ExecStart=/usr/sbin/gsad --timeout=1440 --munix-socket=/var/run/gvmd/gvmd.sock $OPTIONS

systemctl daemon-reload

systemctl restart gsad.service

重新登入WEB之後，就可以不會被踢出來，雖然很方便，但是資安面來說 不大好對吧XD，還是要定期登出，避免重要資訊洩漏！

參考來源：

Client Web Portal Timeout

一波多折的GVM(OpenVAS)@CentOS 8

更可怕的是，就當我以為一切都已經成功了，結果掃描還是出錯，我真的是........

心情平復個幾天之後，決定重新再試一次。

全新安裝的CentOS 8

一樣先完全按照透過Atomicorp的Github教學操作。

此時先保持一顆冷靜的心，已經做好接下來可能會有一場硬仗。

深深的深呼吸，開始一步一步來。

首先先依照先來把服務啟動的部分先調整(畢竟這個步驟是讓我感動到差點飆出眼淚的)

SOLVED: Guidance troubleshooting from log files. ospd service running but not accepting connections

第一步先編輯  /user/lib/systemd/system/gvmd.service

#ExecStart=/usr/sbin/gvmd --osp-vt-update=/var/run/ospd/ospd-openvas.sock $OPTIONS

ExecStart=/usr/sbin/gvmd --osp-vt-update=/var/run/ospd/ospd.sock $OPTIONS

第二部接著編輯  /user/lib/systemd/system/ospd-openvas.service

#PIDFile=/var/run/ospd/ospd-openvas.pid

PIDFile=/var/run/ospd/ospd.pid

#ExecStart=/opt/atomicorp/bin/ospd-openvas --pid-file /var/run/ospd/ospd-openvas.pid --unix-socket=/var/run/ospd/ospd-openvas.sock --log-file /var/log/gvm/ospd-scanner.log --lock-file-dir /var/run/gvm/

ExecStart=/opt/atomicorp/bin/ospd-openvas --pid-file /var/run/ospd/ospd-openvas.pid --unix-socket=/var/run/ospd/ospd-openvas.sock --log-file /var/log/gvm/ospd-scanner.log --lock-file-dir /var/run/gvmd/

這部分跟原作者分享不同的地方在於，當我試著把ospd-openvas修改成ospd.pid 跟ospd.sock時，會造成服務啟動失敗。(我也不知道怎麼回事，太弱了(掩面))

接著執行

systemctl daemon-reload

把服務重新啟動

systemctl restart gvmd.service

systemctl restart ospd-openvas.service

此時查看LOG時發現錯誤，無法讀取ospd.sock

 Log路徑為/var/log/gvm/gvmd.log、為/var/log/gvm/ospd-scanner.log

此時偷吃步直接到/var/run/ospd 建立鏈結

ln -s ospd-openvas.sock ospd.sock

接著查看log沒有看到奇奇怪怪的錯誤訊息了。

趕快登入WEB 介面，測試掃描。

等待的心情真是坎坷不安XDD

終於終於成功了，看著百分比再跑著，有種說不出的感動。

感謝網路上各路大神分享，才能得以順利完成，真的真的是非常謝謝你們。

一直以來能在資訊這領域默默的接受網路上這些無私大佬的分享，真的真的很謝謝你們。

 

 

 

===下方為之前以為終於成功的紀錄，結果掃描下去還是出錯=== 

事情是這樣子的 ~

之前裝好的GVM可能因為版本太舊的關係，又無法使用了。

由於上次的良好經驗，心想這次大概就是三二一步驟貼一貼就可以收工了。

沒想到這次安裝上會遇到這麼多奇奇怪怪的小問題XD。

首先一樣是按照透過Atomicorp的Github教學，安裝的過程倒是輕鬆又愜意。

就在把NVT 等Feed更新完成之後，準備要建立掃描時，一直出現錯誤訊息

Failed to find config 'daba56c8-73ec-11df-a475-002264764cea'

爬文一下才知道原來是少了Scan Configs，於是看了一堆網路大神的解決方法。

Missing scan configs (GVM 20.08.1)

全部方法試過還是失敗，這時不死心地查看一下LOG(/var/log/gvm/gvmd.log)

osp_scanner_feed_version: failed to get scanner_feed_version. OSPd OpenVAS is still starting

看起來跟ospd這個有關，檢查一下LOG(var/log/gvm/ospd-scanner.log)

permission denied

此時突然想起某篇討論(當然前面也曾經照這篇調整修改過)

 SOLVED: Guidance troubleshooting from log files. ospd service running but not accepting connections

 把/user/lib/systemd/system/ospd-openvas.service 裡面的--locked-file-dir /var/run/gvm修改為

--locked-file-dir /var/run/gvmd

重新讀取systemctl daemon-reload 然後把ospd服務重新啟動(重新開機也可以XD)

當下查看LOG時，出現正在更新GVMD_DATA(當下都感動得快飆出淚來了~)

更新完成之後，Scan configs的東西就出現了。

這是一篇非常雜亂，又誤打誤撞莫名其妙成功的心得。

希望給遇到相同困擾的鄉民一絲絲希望。 

參考來源：

Missing scan configs (GVM 20.08.1)

Unable to create scanner configs, and no default configs are provided

SOLVED: Guidance troubleshooting from log files. ospd service running but not accepting connections

Can’t start ospd-openvas.service: Could not gather openvas settings

OpenLDAP Password Policy overlay (ppolicy)

 事情是這樣子的............. (如同往常，又離題了XD)

正當我興高采烈地安裝好openLDAP並且準備開心的使用時，在大量寫入資料時發生錯誤。

根據錯誤訊息才知道原來是mapsize limit reached的問題，還好這個小插曲不算太難解決，調整大小之後就順利解決了。

vim increaseDbSize.ldif

dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcDbMaxSize
olcDbMaxSize: 1000000000

ldapmodify  -Y EXTERNAL -H ldapi:/// -f increaseDbSize.ldif

就當以為一切都順利搞定時，才發現原來預設是沒有密碼政策的，什麼密碼複雜度、輸入失敗錯誤鎖定..等是需要額外套用，嗯，這一切看起來真的是非常合理呢，接著便拼命的上網爬文，無論是網路上各路大神、或是鄉民的單一心法照抄都是失敗(可能看得不夠多)，所幸皇天不負苦心人，混合使用之後終於僥倖的套用成功，記錄下來提供給可能照抄單一大神步驟失敗的朋友們試試看看。

第一步：啟用policy Overlay

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif

第二步：建立一個放置規則的位置(請把cn=admin,dc=yourdomain,dc=yourcom替換成您的位置)

vim policies_1.ldif

dn:ou=Policies,cn=admin,dc=yourdomain,dc=yourcom
objectClass: top
objectClass: organizationalUnit
ou: Policies
description: Password policy config files

ldapadd -D cn=admin,dc=yourdomain,dc=yourcom -W -f policies_1.ldif

第三步： 讀取Modules

vim policy_module.ldif

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: ppolicy.la

ldapadd -Y EXTERNAL -H ldapi:/// -f policy_module.ldif

第四步：讓資料夾知道讀取政策位置(mdb請自行替換成你的openLDAP的模式)

vim policy_overlay.ldif

dn: olcOverlay={1}ppolicy,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {1}ppolicy
olcPPolicyDefault: cn=DefaultPPolicy,ou=Policies,cn=admin,dc=yourdomain,dc=yourcom

ldapadd -Y EXTERNAL -H ldapi:/// -f policy_overlay.ldif

第五步：建立密碼政策(可以參考slapo-ppolicy)
vim Default_Policies.ldif
dn: cn=DefaultPPolicy,ou=Policies,cn=admin,dc=yourdomain,dc=yourcom
cn: DefaultPPolicy
objectClass: pwdPolicy
objectClass: device
objectClass: top
pwdAttribute: userPassword
pwdMaxAge: 2592000
pwdExpireWarning: 2160000
pwdInHistory: 3
pwdCheckQuality: 1
pwdMinLength: 8
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 30
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
ldapadd -D cn=admin,dc=yourdomain,dc=yourcom -W -f Default_Policies.ldif

接下來就可以快樂的使用這些密碼政策了

參考文章

How to increase size of OpenLDAP MDB database? (MDB_MAP_FULL Error Code)

OPENLDAP: password policy overlap, how to assign to a specific OU

OpenLDAP Password Policy overlay (ppolicy)

slapo-ppolicy

GVM 22.08 (OpenVAS) 安裝?

事情是這樣子的，原本每段時間會利用OpenVAS進行一次全系統的掃描，一如往常地準備更新，沒想到更新時卻發生錯誤，於是透過Greenbone社群發現，看到有鄉民提到如果是使用EOL的版本將無法繼續更新。

好在GVM22(OpenVAS)新版的安裝也是非常的簡單，快速把CentOS 8安裝好後，透過Atomicorp的Github教學，很輕易的就能安裝完成。

雖然安裝的過程中有發生一個搞笑的插曲

yum config-manager --set-enabled PowerTools

PowerTools在CentOS 中是小寫，害我在這邊卡了一下，還特地爬一下文XDDD 

 PS.新版的介面用起來還蠻順暢的，另外最近看到新聞，RedHat似乎要丟棄CentOS 8，看來要好好思考一下:P

OpenVAS 9 更新

最近在弱點掃描時，發現OpenVAS不會更新，於時爬文發現有位鄉民提到了很棒的解決方法(如下方參考來源)

在OpenVAS的Feed Status中，可以看到一共有三種類型。
分別是 NVT、SCAP、CERT

如果要各別更新的話您可以這麼做

#NVT
/usr/sbin/greenbone-nvt-sync
#SCAP
/usr/sbin/greenbone-certdata-sync
#CERT
/usr/sbin/greenbone-scapdata-sync

更新好之後記得更新快取

 /usr/sbin/openvasmd --update --verbose --progress

然後把服務重啟

systemctl restart  openvas-manager.service
systemctl restart  openvas-scanner.service

當然你也可以寫成SHELL SCRIPT，然後放到排程讓他自動更新。


Referenece
Update Openvas Feeds

LVM @ CENTOS 7 - resize2fs: Bad magic number in super-block while trying to open

今天又是來離題的 XD

話說上次安裝系統時，試著嘗試使用LVM (LVM有一堆優點...........)，不過還是我第一次嘗試。

然後最近碰到空間滿的情況，以前都是用GPARTED在那邊調空間
這次也很自然地就這樣做了 (喂，當初採用LVM不就是因為它可以方便的調整)

結果我熊熊的發現，GPARTED沒辦法去調LVM (不知道是否版本過舊)
但也讓我回想起，我當初幹嘛用LVM了。

快速GOOGLE一下 LVM調整方法。
整個步驟還蠻簡單的，可以參考下方連結。

只是最後要把空間擴充的時候，心想可以打完收工了XD

vgextend /dev/mapper/centos-root

然後我就看到

resize2fs: Bad magic number in super-block while trying to open 

翻了一下網路上廣大鄉民的意見，發現在CentOS 7 下是要用xfs_growfs 而並非resize2fs

xfs_growfs /dev/mapper/centos-root

參考來源：
resize2fs: Bad magic number in super-block while trying to open ….
resize2fs: Bad magic number in super-block while trying to open