使用 CTFd 架設 CTF 平台 (Apache + mod_wsgi + MySQL)

這陣子因為課程需要建立一個 CTF 平台, 最後決議使用 CTFd 來架設這次的CTF計分板, 安裝的過程中踩了不少的地雷, 又因為懶得裝 Nginx 改採 Apache + mod_wsgi 結果冒出了更多問題, 真的是人不作死就不會死.

本篇文章假定各位已經裝好 Apache 與 MySQL.

關於 CTFd

CTFd 是 isislab 推出的 open source jeopardy style CTF platform, 使用上非常容易上手, 運行要求十分輕量且容易客製化.
DEMO: CTFd.io

環境資訊

Python 2.7
Apache 2.4
Debian 8

1. 環境準備

sudo apt-get update
sudo apt-get install build-essential libffi-dev git libapache2-mod-wsgi python-pip python-dev
a2enmod mod_wsgi

2. 取的最新版 CTFd

git clone https://github.com/isislab/CTFd.git
cd CTFd

3. 安裝相依

pip install -r requirements.txt
pip install -U sqlalchemy

4. 設定啟動腳本

在 CTFd 下建立 apache.py, 讓 Apache 使用這個 py 來啟動服務

import sys
sys.path.insert(0, '/CTFd') # /CTFd 要改成你的 CTFd 主目錄的路徑, 範例是放在 /CTFd

from CTFd import create_app
application = create_app()

5. 設定 Apache

DocumentRoot /CTFd # CTFd 所在目錄
WSGIDaemonProcess CTFd user=www-data group=www-data threads=5 # user/group 決定 Apache 用哪個帳號運行這支程式
WSGIScriptAlias / /CTFd/apache.py # 前面步驟設定的啟動腳本
 <Directory /CTFd>
    WSGIProcessGroup CTFd
    WSGIApplicationGroup %{GLOBAL}
    Order allow,deny
    Allow from all
    Require all granted  # Apache 2.4 預設禁止目錄在 /var/www 外, 這行可以解除這項限制
</Directory>

6. 設定資料庫連線(Mysql)

建立資料庫的時候編碼記得選擇 utf8mb4_bin (若選擇general將會導致計分板無法正確取得題目類型), 這樣就可以讓 CTFd 支援 Emoji 和中文

編輯 CTFd/CTFd/config.py

SQLALCHEMY_DATABASE_URI = "mysql://帳號:密碼@主機位置/資料庫名稱?charset=utf8mb4"

這邊無需導入資料表, 在網站第一次啟動的時候程式會自動建立必要資料表以及產生Admin

7. 重新啟動 Apache

systemctl restart apache2

備註

由於 CTFd 有檔案上傳與Log, 要記得將 CTFd 目錄的擁有者設定成 Apache 使用的帳號, 不然CTFd不會正常運作

如何在 AWS EC2 建立 Windows Server 2016 主機

最近系統測試環境需要使用 Windows Server 2016, 但手邊沒有多餘的測試主機, 想到平常工作都是使用 Linux, 所以 Amazon Web Service(AWS)上的主機也都是以 Linux 系統為主, 那就在 AWS EC2 上開一台 Windows 2016 玩玩看好了, 實際使用後才發現流程上有點差異, 決定做個筆記紀錄一下

Step 1. 建立 Windows EC2

創建 Windows EC2 的方法就跟建立 Linux EC2 的方法大致相同, 只要選擇 Windows 的 AMI 即可(這邊選擇 Windows Server 2016)

後續步驟跟平常建立 EC2相同, 這邊就不再贅述

Step 2. 選擇憑證

在 EC2 建立精靈的最後一步會要求選擇憑證, 請務必選擇憑證, 這憑證是用來解開密碼用的, 很多人在這個步驟想說 Windows 不支援 PEM 登入就不選擇, 導致最後無法解開登入資訊

Setp 3. 取得登入密碼

在主機建立完成後, 可以在主機上按下右鍵選擇 Get Windows Password

若主機上尚未準備完成會顯示如下訊息, 過幾分鐘後重試就可以了(主機建立後四分鐘通常就可以正常取得密碼)

當系統準備完成時, 系統會要求我們上傳自己的 PEM(建立EC2時選的那張憑證)

上傳PEM後選擇 Decrypt Password

畫面上就會顯示登入資訊

Setp 3. 取得連線資訊

在主機上按下右鍵選擇 Connect

點選 Download Remote Desktop File, 下載 RDP 資訊檔

接著只要打開下載的 RDP 檔就可以建立遠端連線了!

重設 mysql root 密碼(Mysql 5.7.5 以下, 5.7.6 以上)

由於工作內容時常接手不明主機, 找 root 密碼早已是家常便飯, 這邊與各位分享 Mysql <= 5.7.5 以及 Mysql >= 5.7.6 的 root 重設方法

1. Stop Service

停止執行中的 mysql

service mysql stop

2. Run Mysql in single-user mode

進入單人模式

mysqld_safe --skip-grant-tables --skip-networking &

參數解釋:
* –skip-grant-tables: 不載入權限表
* –skip-networking: 關閉網路連線(遠端使用者將無法連入主機)

警告: 單人模式下所有人都可以免密碼存取 root, 若您的環境是共用系統, 為避免造成資安上的疑慮, 請務必將主機上其他人請下線.

3. Reset Root Password

3.1 Mysql <= 5.7.5

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('root_password');

3.2 Mysql >= 5.7.6

UPDATE mysql.user SET authentication_string = PASSWORD('root_password')
WHERE User = 'root' AND Host = 'localhost';

4. Flush Privileges

FLUSH PRIVILEGES;
exit;

5. Restart mysql

重新執行 mysql, 使其恢復正常模式

service mysql stop
service mysql start

6. Finish

現在可以使用新的 root 密碼進行登入了~

取得及修改 cpanel mysql 的 root 密碼

Cpanel 在主機管理系統的市佔率極高, 在路上很容易遇到 cpanel 主機, 雖然操作作業通常都由 cpanel 的後台直接進行, 但有時候我們需要直接從 cli 中去對資料庫操作, 這時候就會需要 mysql root password, 而 cpanel 的所有服務密碼都是獨立的, 因此 WHM 的 root password 並不適用.

cpanel 會將 root 密碼存在 /root/.my.conf 當中, 檔案內的 password 後方就是 root 密碼.

[client]
password="#kdu^39dk!;dl"
user=root

若想要修改 mysql 的密碼, 在修改密碼後回填 /root/.my.conf 以及重啟 DB, cpanel 就會使用新密碼進行操作.

PostgreSQL 備份與還原

最近在進行一個 postgreSQL 的主機轉移作業, 由於主機的版本有升級, 決定採取導出後導入的方式進行, 在這邊紀錄一下 PostgreSQL備份與還原的過程, 以及過程中遇到的問題

環境

  • DB_SERVER_1
    OS: Debian 8
    DB: PostgreSQL 9.3.5

  • DB_SERVER_2
    OS: Debian 8
    DB: PostgreSQL 9.5.5

步驟

備份(導出)

指令:

pg_dump [-h 主機] [-p 資料庫Port] [-U 使用者名稱] [資料庫名稱] [-f 檔案名稱]

範例:
Host: db01.postgresql
Port: 5502
User: pqadmin
DB: website

pg_dump-h db01.postgresql -p 5502 -U pqadmin website -f website-2016-11-07.sql

系統接著會問密碼(輸入不會顯示在畫面上), 再輸入完後我們就會得到一個 website-2016-11-07.sql 的導出結果

還原(導入)

指令 psql

psql [-h 主機] [-p 資料庫Port] [-f 檔案名稱] [資料庫名稱] [使用者名稱]

注意參數格式, psql 與 pg_dump 參數格式不同

範例:
Host: db02.postgresql
Port: 5990
User: pqadmin
DB: website

psql -h db02.postgresql -p 5990 -f website-2016-11-07.sql website pqadmin

接著一樣輸入使用者密碼系統就會開始導入

遭遇問題

1. pg_dump: aborting because of server version mismatch

問題原因

pg_dump 的版本低於目標Server的版本, --ignore-version 這個參數在新版已經無法使用

解決辦法

安裝正確版本的 postgresql, pg_dump 便會是相對應版本

2. pg_dump 版本不符

問題原因

安裝了正確版本的 postgresql 後, pg_dump 的版本依然是舊的, 主要的問題在安裝新版 postgresql 的方法大多都是使用官方 repo, 官方repo 與 apt, yum package 的安裝位置不同, 導致 pg_dump 會一直抓到 apt, yum 安裝的版本而不是新的版本

解決辦法

可以在 /usr/lib/postgresql/{version}/bin/找到對應版本的 psql 與 pg_dump

在 Windows 下 存取 Ext2/Ext3/Ext4 磁區

在主機維護的日常中, 時常會在 Linux 與 Windows 環境中切換, Linux 下如果要開啟 NTFS 格式沒有甚麼困難, 但 Windows 開啟 ext2/ext2/ext4 格式卻很少人討論

因工作上需要在Windows 環境下讀取 Linux 的磁碟資料, 在這邊介紹一個可以使用的讀取工具

軟體介紹

Ext2Fsd 是 Windows 下一套很實用的 Driver, 雖然名稱是 ext2fsd 但 ext3/ext4 都可讀取, 安裝完成後電腦便可直接認得 ext 格式磁區
雖然官方介紹只能支援到 Windows 8, 但實測 Windows 10 可以正常使用

軟體資訊

官方網站: Ext2Fsd Project
下載網址: 點此下載

使用方法

安裝完成後重新啟動電腦, 系統便可直接識別出 ext 格式的磁區, 可以搭配 vmdk 掛載 直接用檔案總管來操作磁碟

直接掛載 Vmdk

有使用 Esxi 或 VMWare Workstation 的使用者對於 vmdk 這個格式想必都不陌生, 近日因工作上需求需要取得vm內的檔案, 但是又不想掛載整台虛擬機, 所以決定直接打開vmdk, 在這邊與各位分享一下掛載步驟

環境準備

VMWare Workstation

步驟

1. 打開 Map Virtual Disks

工具列 -> File -> Map Virtual Disks

2. 開啟 Map 選單

3. 設定掛載 vmdk

Filename: 選取想要掛載的 vmdk
Volume: 選擇想要掛載的分割磁區, 這台VM 共有三個磁區, 這部分我選擇 74.5GB 的磁區
Drive: 磁區掛載的磁碟代號

4. 卸除磁碟

當使用完畢後, 我們可以在 Map Virtual Disks 點選 Disconnect 來卸除磁碟

小記

直接 mount vmdk 是一個很實用的功能, 但目前只有 Workstation 版本可以使用, Player 版本並沒有這個功能
另外, 使用完畢務必卸除磁碟, 不然還是會像一般硬碟那樣損毀

Security Hardening Guides 的 Compilers 是什麼?

在很多檢查工具中都會有一個類別叫做 Hardening, 在這個類別中常見的東西有 安裝防毒, 定時稽核… 等, 其中有一個項目叫做 Compiler(s), 這個項目是我被問過最多次的一個項目, 在這邊跟大家分享這個項目的主要目的

說明

Compiler(s) 項目表示主機內有可供使用的編譯器, 像是 gcc, g++ 這類可以直接編出 Binary 的編譯器

風險

基本上在大多數正確設置的主機中, 若權限設定得宜可以將入侵後的破壞風險控制住, 但 Kernel 漏洞是很多人難以處置的問題, 可能原因是主機無法任意重開或者懶得管, Kernel 漏洞跟編譯器的主要關聯在於Kernel 漏洞可以透過編譯 exploit 來進行提權, 藉此獲取更高的權限, 這將使權限設定的效果降低, 而這樣的過程需要使用編譯器, 因此一個可以被使用者使用的編譯器會讓主機在某些層面上增加風險.

補充

  1. Lynis 有檢查這個項目
  2. 2016/10/20 – Linux 發現一個存在9年的 Kernel exploit – Dirty COW(CVE-2016-5195), 就是一個需要在編譯 exploit 的例子. 參考來源: The Hacker News – Dirty COW

Lynis: 忽略特定檢查

Lynis 讓我們可以快速的檢查主機的安全問題, 但有些檢查是我們不感興趣(例如提示), 或者主機特殊需求造成的誤判, 實際上 Lynis 是可以讓我們自定要跳過哪些項目

我們可以在 Lynis 的設定檔案中定義想要忽略的檢查, 這邊我使用預設的profile

default.prf

在最下面加入以下內容

skip-test=你想跳過的檢查編號

這邊的例子是想忽略 PKGS-7392 這個檢查項目

skip-test=PKGS-7392

如果想跳過多個就多寫幾行

skip-test=跳過檢查編號1
skip-test=跳過檢查編號2
skip-test=跳過檢查編號3

這樣在下次執行 Lynis 的檢查時將不會檢查我們希望忽略的檢查項目了

Lynis: Linux 主機安全性掃描工具

作為一個主機維運人員, 資訊安全一直都是我們非常注重的一個目標, 但主機一多就不容易顧及到所有細節.

本篇文章介紹的 Lynis 是一套 Linux 的主機稽核工具, 可以用來檢查主機的漏洞與弱點, 以及簡易的後門檢查, 也可以針對各種設定做出建議, 是一套非常好用的主機安全維護工具

安裝 Lynis

方法一: 使用 apt-get

使用 Debian, Ubuntu 的使用者可以使用 apt-get 進行安裝

apt-get install lynis 

雖然 apt 很方便, 但 apt 上的版本不會是最新的, 安全檢測工具最好要維持在最新版, 才能提供最完善的檢測效果, 建議從官方網站下載最新版本

方法二: 從官方網站下載(建議)

前往 官方網站 下載最新的版本

我在寫這邊文章的時候最新版本是 2.3.4, 下方指令使用 2.3.4 版作為示範, 記得要更換為最新版本喔!

wget https://cisofy.com/files/lynis-2.3.4.tar.gz
tar zxvf lynis-2.3.4.tar.gz
cd lynis

執行 Lynis

Lynis 的執行分為 root 模式與一般使用者模式, root 模式會檢查所有細節, 一般使用者模式僅檢查一些通用項目, 在這邊建議各位使用 root 模式

使用 root 執行 Lynis

sudo ./lynis audit system -Q

新版本還可以檢查 dockerfile, 挺厲害的呢

Lynis 將會開始進行各項稽核

執行完成後 Lynis 會將 log 放置於

/var/log/lynis.log

Lynis 結果報告

報告解讀與改善

透過 Lynis 的執行結果, 我們會發現 [FOUND], [NONE] 各種檢測結果, 這些結果根據不同的分類會有不同的解釋, 最簡易的判定方式是藉由顏色分辨, 綠色正常, 黃色提醒, 紅色警告, 但這不是絕對, 實際上需要依據實際需求狀況去做探討.


上圖就是一個例子, 由於這台主機的角色為路由器, 因此很多特殊的設定都被打開, 在這邊的紅字反而但表著正常.

在 Lynis 檢查結果的最後會附上如下圖的建議事項表

拿其中的一項做舉例

Warnings (1):
  ----------------------------
  ! Found one or more vulnerable packages. [PKGS-7392]
      https://cisofy.com/controls/PKGS-7392/

這個例子中舉例有弱點套件沒有更新, 前往下方的網址 PKGS-7392 就可以了解詳細的內容, 像是如何修補的建議與漏洞成因之類的, 在這次的範例中給出了下方的指令, 看樣子是更新系統的指令

apt-get update
apt-get upgrade

更新之後再一次的執行 Lynis, 就發現這個項目消失了, 代表我們解決了這個問題, 主機的安全更進一步了.

報告細節

有些公司可能會要求記錄稽核改善過程, Lynis 可以幫助你寫出好像很厲害的細節, 延續上面的例子, 我們針對 PKGS-7392 這個稽核項目進行更深入的了解

Lynis 提供的 show details 指令, 讓我們可以查詢每一項稽核結果的細節, 下方以PKGS-7392為例

sudo ./lynis show details PKGS-7392

Lynis 就會從 /var/log/lynis.log 中取出關於 PKGS-7392 的部分

2016-10-21 12:49:46 Performing test ID PKGS-7392 (Check for Debian/Ubuntu security updates)
2016-10-21 12:49:46 Action: updating repository with apt-get
2016-10-21 12:49:51 Result: apt-get finished
2016-10-21 12:49:51 Test: Checking if /usr/lib/update-notifier/apt-check exists
2016-10-21 12:49:51 Result: apt-check (update-notifier-common) not found
2016-10-21 12:49:51 Result: found vulnerable package(s) via apt-get (-security channel)
2016-10-21 12:49:51 Found vulnerable package: bind9-host
2016-10-21 12:49:51 Found vulnerable package: dnsutils
2016-10-21 12:49:51 Found vulnerable package: exim4
2016-10-21 12:49:51 Found vulnerable package: exim4-base
2016-10-21 12:49:51 Found vulnerable package: exim4-config
2016-10-21 12:49:51 Found vulnerable package: exim4-daemon-light
2016-10-21 12:49:51 Found vulnerable package: fontconfig
2016-10-21 12:49:51 Found vulnerable package: fontconfig-config
2016-10-21 12:49:51 Found vulnerable package: host
2016-10-21 12:49:51 Found vulnerable package: libbind9-90
2016-10-21 12:49:51 Found vulnerable package: libcurl3-gnutls
2016-10-21 12:49:51 Found vulnerable package: libdns-export100
2016-10-21 12:49:51 Found vulnerable package: libdns100
2016-10-21 12:49:51 Found vulnerable package: libfontconfig1
2016-10-21 12:49:51 Found vulnerable package: libgcrypt20
2016-10-21 12:49:51 Found vulnerable package: libgd3
2016-10-21 12:49:51 Found vulnerable package: libgdk-pixbuf2.0-0
2016-10-21 12:49:51 Found vulnerable package: libgdk-pixbuf2.0-common
2016-10-21 12:49:51 Found vulnerable package: libgraphite2-3
2016-10-21 12:49:51 Found vulnerable package: libidn11
2016-10-21 12:49:51 Found vulnerable package: libintl-perl
2016-10-21 12:49:51 Found vulnerable package: libirs-export91
2016-10-21 12:49:51 Found vulnerable package: libisc-export95
2016-10-21 12:49:51 Found vulnerable package: libisc95
2016-10-21 12:49:51 Found vulnerable package: libisccc90
2016-10-21 12:49:51 Found vulnerable package: libisccfg-export90
2016-10-21 12:49:51 Found vulnerable package: libisccfg90
2016-10-21 12:49:51 Found vulnerable package: libjasper1
2016-10-21 12:49:51 Found vulnerable package: liblwres90
2016-10-21 12:49:51 Found vulnerable package: libmodule-build-perl
2016-10-21 12:49:51 Found vulnerable package: libtasn1-6
2016-10-21 12:49:51 Found vulnerable package: linux-image-3.16.0-4-amd64
2016-10-21 12:49:51 Found vulnerable package: linux-libc-dev
2016-10-21 12:49:51 Found vulnerable package: ntp
2016-10-21 12:49:51 Found vulnerable package: ntpdate
2016-10-21 12:49:51 Found vulnerable package: openssh-client
2016-10-21 12:49:51 Found vulnerable package: openssh-server
2016-10-21 12:49:51 Found vulnerable package: openssh-sftp-server
2016-10-21 12:49:51 Found vulnerable package: python-pil
2016-10-21 12:49:51 Found vulnerable package: qemu-guest-agent
2016-10-21 12:49:51 Warning: Found one or more vulnerable packages. [test:PKGS-7392] [details:-] [solution:-]
2016-10-21 12:49:51 Suggestion: Update your system with apt-get update, apt-get upgrade, apt-get dist-upgrade and/or unattended-upgrades [test:PKGS-7392] [details:-] [solution:-]
2016-10-21 12:49:51 ===---------------------------------------------------------------===

這樣我們就可以依據Log結果來寫稽核報告了呢

定時執行

稽核要定時執行才能達到最好的效果, 我們可以藉由加入 crontab 來達到自動重複執行的目的

crontab -e

這邊假設 每天凌晨四點執行 (小提醒: 請注意主機時區)

0  4   *   *   *   root    /were/is/the/lynis audit system --no-colors -q -Q

這樣每天凌晨四點就可以去 /var/log/lynis.log 取得 分析結果, 有空的網管可以自己寫一支程式去分析結果然後寄送mail, Lynis 有提供可程式讀取的報告檔案

/var/log/lynis-report.dat

更新 Lynis

Lynis 要積極更新才能發揮他完整的作用, 可以使用以下指令來查詢是否有新的版本

./lynis update info

這部分有點可惜的是, Lynis 2.2 以後免費版就不再提供官方更新點了

雖然 Lynis 內建了更新指令, 但要自行架設更新主機

./lynis update release

由於不能直接更新, 各位要記得定時到官方網站下載最新版, 至於更新點的架設, 下次有機會的時候再來與各位分享