スマホにインストールしたubuntuからディレクトリスキャンツールGobuster/dirbを実行し、使い方と対策について考えてみました。
環境
スマートフォン上のTermux
ゲストOS Ubuntu 24.04LTS
Go言語 1.22.2 linux/arm64
スマートフォンにTermuxやUbuntuをインストールする方法は TermuxにUbuntuをインストール を参照
インストール方法
次のコマンドでインストールしました。
# インストール前確認
# apt を最新にする
$ > apt update
$ > apt upgrade
# go言語がインストール済みか確認する
$ > go version
go version go1.22.2 linux/arm64
# gobuster のインストール、辞書(dirb)のインストール
$ > apt install gobuster
$ > gobuster version
3.6 # 2025/4/26 時点の最新は3.6
$ > apt install dirb
$ > dirb version
:
DIRB v2.22
# バージョンが表示されればインストールが完了
dirbを使ったディレクトリ探索結果
まずはdirbを使ったディレクトリ探索を行いました。
ローカルPC上のApacheサーバに対して実験しました。
# windowsマシン上でApacheを起動しておく（http://192.168.0.145)
# スマホ上のUbuntuよりdirbを実行
$ > dirb http://192.168.0.145
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Sat Apr 26 01:11:45 2025
URL_BASE: http://192.168.0.145/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://192.168.0.145/ ----
+ http://192.168.0.145/cgi-bin/ (CODE:403|SIZE:199)
==> DIRECTORY: http://192.168.0.145/html/
==> DIRECTORY: http://192.168.0.145/HTML/
+ http://192.168.0.145/index.html (CODE:200|SIZE:46)
+ http://192.168.0.145/nul (CODE:403|SIZE:199)
---- Entering directory: http://192.168.0.145/html/ ----
==> DIRECTORY: http://192.168.0.145/html/cgi/
+ http://192.168.0.145/html/index.html (CODE:200|SIZE:1341)
+ http://192.168.0.145/html/nul (CODE:403|SIZE:199)
---- Entering directory: http://192.168.0.145/HTML/ ----
==> DIRECTORY: http://192.168.0.145/HTML/cgi/
+ http://192.168.0.145/HTML/index.html (CODE:200|SIZE:1341)
+ http://192.168.0.145/HTML/nul (CODE:403|SIZE:199)
---- Entering directory: http://192.168.0.145/html/cgi/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
---- Entering directory: http://192.168.0.145/HTML/cgi/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
-----------------
END_TIME: Sat Apr 26 01:13:24 2025
DOWNLOADED: 13836 - FOUND: 7 実行にかかった時間は２分５５秒でした。
結果をまとめると、ローカルホストの公開領域には、
html → 存在する
html/cgi-bin/ → 存在する
html/nul/ → 存在しない
html/index.html → 存在する
html/cgi/ → 存在する(※一覧表示可能)
が見つかったとの内容です。
「nul」についてはよくわかりません。
「html/cgi/」については、一覧表示可能となっていたので確認したところ
となっており、公開表示されていました。（ローカル環境なので設定が漏れていました）
ツールを使って設定の漏れがないかを確認するのは大事ですね。
次は、Apache側でどのようなログが排出されているのかを確認します。
# ローカルサーバのapacheログ
192.168.0.244 - - [26/Apr/2025:10:11:45 +0900] "GET /randomfile1 HTTP/1.1" 404 196
192.168.0.244 - - [26/Apr/2025:10:11:45 +0900] "GET /frand2 HTTP/1.1" 404 196
192.168.0.244 - - [26/Apr/2025:10:11:45 +0900] "GET /.bash_history HTTP/1.1" 404 196
192.168.0.244 - - [26/Apr/2025:10:11:45 +0900] "GET /.bashrc HTTP/1.1" 404 196
192.168.0.244 - - [26/Apr/2025:10:11:45 +0900] "GET /.cache HTTP/1.1" 404 196
: このようなログが約13800件残っていました。
dirbは辞書を使って、よく使われるファイルやフォルダ名を総当たりでWebサーバに問合せして、ステータスコードを見てファイルやフォルダの属性を調べるツールだとわかりました。
ログにばっちりとIPアドレスが残っているので、サーバ管理者が見ると一発でわかりますね。
しかも行数が多いので、目視で発見できそうです。
dirbを使って見つかった問題点の修正
dirbを使って見つかった問題点は
html/cgi フォルダのファイルが公開されていたこと
logファイルにUAが出力されていなかったこと
ですのでさっそく修正しました。
①html/cgi フォルダのファイルが公開されていたこと
対象のフォルダ（html/cgi）が外部に公開されてしまっていたため、以下の手順でアクセス制限を強化しました。
.htaccess または Apache の設定ファイルである httpd.conf を修正することで、外部アクセスを制限できます。今回はhttpd.confを修正して、対策を行いました。
# httpd.conf に次の修正を反映
<Directory "${SRVROOT}/htdocs/html/cgi">
AllowOverride None
Options None
Require all granted
</Directory>この変更により、html/cgi フォルダ内に index.html が存在しない場合でも、そのフォルダのファイル一覧が表示されることを防ぎます。
②logファイルにUAが出力されていなかったこと
logファイルにユーザエージェントが表示されていなかったので、ログの書式を変更してユーザエージェントも保存するように修正しました。
# httpd.confファイル
CustomLog "logs/access.log" common
↓
CustomLog "logs/access.log" combined
# に修正するとユーザエージェントがログ上に保存されるようになりますこの変更で、出力されるログファイルの書式が次のように修正されます。
# access.log
# 修正前
192.168.0.244 - - [26/Apr/2025:10:11:45 +0900] "GET /randomfile1 HTTP/1.1" 404 196
↓
# 修正後
192.168.0.244 - - [26/Apr/2025:11:05:41 +0900] "GET /randomfile1 HTTP/1.1" 404 196 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"ユーザーエージェントを見ると、dirbでは
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
という名前でアクセスを繰り返していることがわかります。
かなり古いユーザエージェント（わざとかな？）ですね。
Gobusterを使ったディレクトリ探索結果
次はgobusterを使ったディレクトリ探索を行いました。
実行コマンドは次の通り
# windowsマシン上でApacheを起動しておく（http://192.168.0.145)
# スマホ上のUbuntuよりdirbを実行
# ワードリストはdirbのものを使用しました
$ > gobuster dir -u http://192.168.0.145/ -w /usr/share/dirb/wordlists/big.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) ===============================================================
[+] Url: http://192.168.0.145/
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/dirb/wordlists/big.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6 [+] Timeout: 10s ===============================================================
Starting gobuster in directory enumeration mode ===============================================================
/.htpasswd (Status: 403) [Size: 199]
/.htaccess (Status: 403) [Size: 199]
/HTML (Status: 301) [Size: 234] [--> http://192.168.0.145/HTML/]
/cgi-bin/ (Status: 403) [Size: 199]
/html (Status: 301) [Size: 234] [--> http://192.168.0.145/html/]
/nul (Status: 403) [Size: 199]
/secci� (Status: 403) [Size: 199] Progress: 20469
/ 20470 (100.00%)
===============================================================
Finished
===============================================================
実行にかかった時間は１０秒でした。
dirbと同じワードリストを使っていますが、gobsterの出力の方が読みやすい感じです。
”/secci�”というフォルダに心当たりがないのですが、なんでしょうか？
webサーバのアクセスログを見るとこんな感じでした。
192.168.0.244 - - [26/Apr/2025:12:08:42 +0900] "GET / HTTP/1.1" 200 46 "-" "gobuster/3.6"
192.168.0.244 - - [26/Apr/2025:12:08:42 +0900] "GET /7557f490-5d7f-4029-9536-???????????? HTTP/1.1" 404 196 "-" "gobuster/3.6"
192.168.0.244 - - [26/Apr/2025:12:08:42 +0900] "GET /!images HTTP/1.1" 404 196 "-" "gobuster/3.6"
1 UIDっぽいものを検索していますね
同じワードリストを使っているのに、gobsterのサーチログは
20470行
出力されていましたので、オリジナルの検索ワードも調べているようです。
こちらは、ユーザーエージェントで”gobuster”と名乗っているのが潔い。
スキャン対策
dirbとgobsterによるディレクトリスキャンを行いましたが、第三者によるスキャンを防ぐことも重要だと感じました。
ユーザーエージェントによるサーチブロックができるのではないかと思い、実験してみることにしました。
dirbのユーザーエージェントは、
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
※windowsXP+インターネットエクスプローラのUA
gobsterのユーザーエージェントは、
gobuster/3.6
を使用していることがわかっています。
# httpd.confに次の修正
# deny用のモジュールをロード
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule authz_host_module modules/mod_authz_host.so
# ユーザエージェントによるアクセス制限
<Directory "${SRVROOT}/htdocs/">
# ブロックリスト
SetEnvIf User-Agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" block_dirb
SetEnvIf User-Agent "gobuster" block_gobster
SetEnvIf User-Agent "curl" block_curl
Deny from env=block_dirb
Deny from env=block_gobster
Deny from env=block_curl
# その他の通常の設定
AllowOverride None
Require all granted
</Directory>実験１ curlによるアクセスをブロック
とりあえず、curlがブロックできるか確認したところ、この変更でCurlによるアクセスをブロックすることはできました。
# 対策前
$ > curl 192.168.0.145
<html><body><h1>It works!</h1></body></html>
↓
# 対策後
$ > curl 192.168.0.145
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p> </body></html>実験２ dirbによるアクセスをブロック
”Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”のユーザエージェントを持ったアクセスを遮断したうえで、dirbによるディレクトリサーチを行ったところ、
ブロックされていてもサーチできる
ことがわかりました。
mod_evasiveを使う方法もあるようですが、レンタルサーバだとモジュールをインストールできないし…
うーん困った。
当面はログのアナライズで対策して、IPブロックするしかなさそうです。
実験３ gobusterによるアクセスをブロック
この方法でGobusterのアクセスを遮断したところ、
アクセスを遮断できる
ことが確認できました。
# gobsterの実行結果(UAで遮断)
$ > gobuster dir -u http://192.168.0.145/ -w /usr/share/dirb/wordlists/big.txt ===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) ===============================================================
[+] Url: http://192.168.0.145/
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/dirb/wordlists/big.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Timeout: 10s ===============================================================
Starting gobuster in directory enumeration mode ===============================================================
Error: the server returns a status code that matches the provid
ed options for non existing urls. http://192.168.0.145/81e081f4
-5bf0-4aea-b412-?????????? => 403 (Length: 199). To continue pl
ease exclude the status code or the length
Gobusterを受け入れたくないサーバでは、UAによるアクセス遮断が有効だとわかりました。
最後に
UAによるアクセス遮断を用いると、CurlとGobusterはUAでスキャンをブロックできる一方、dirbではブロックできないことがわかりました。
OSS（オープンソースソフトウェア）ですので、ある程度の知識がある人ならUAを書き換えることもできますし、総当たりプログラムなら理屈がわかれば自分で作ることもできますので、UAによるアクセス遮断がどれほど効果的かはわかりませんが、こういったツールがあることを知って、自衛対策を講じてもらいたいと思います。
特にローカル環境だと、セキュリティがおろそかになると改めて感じました。
こういったスキャンツール対策として、フォルダ名やファイル名を乱数やハッシュ値にするとか、いやだなぁと感じた午後でした。
