管理者/sshd への攻撃を撃退

sshd へのブルートフォース攻撃
ログの調べ方
解析コマンドの意味
攻撃パターン
撃退法
ログを解析して、怪しい相手のＩＰアドレスをブラックリストに追加していくタイプ
頻繁に接続してくる相手をファイアーウォールでシャットアウトするタイプ
現状
コメント

sshd へのブルートフォース攻撃†

sshd への総当たり攻撃について、古い記事だけれど次のものを読みました。

http://yoosee.net/d/archives/2005/11/08/002.html

で、気になって調べてみました。

ログの調べ方†

疑わしいアクセスに /var/log/auth.log に POSSIBLE BREAK-IN ATTEMPT! という文字が付くので、これを抜き出し解析します。すると・・・

LANG:console
$ gunzip -c /var/log/auth.log.*.gz | cat - /var/log/auth.log* | grep "POSSIBLE BREAK-IN ATTEMPT" | sed -e "s/.*getaddrinfo for //g" -e "s/ failed - .*//g" | sort | uniq -cd
   201 116.214.25-66.del.tulipconnect.com [116.214.25.66]
   189 18.136.142.219.broad.bj.bj.dynamic.163data.com.cn [219.142.136.18]
   289 82-102-134-122.orange.net.il [82.102.134.122]
  1221 bbsfix-168-26-142-118-on-nets.com [118.142.26.168]
    82 corporat201-244190250.sta.etb.net.co [201.244.190.250]
   129 ilink19.eprotea-finexus.com [202.151.225.19]
   290 ip37.ccpu.com [216.54.134.37]
  4413 ip94.dyn1.charleroi3.schedom-europe.net [83.101.41.94]
 70129 powersportsupport.com [208.101.55.178]

わんさか出ました（ＴＴ

解析コマンドの意味†

Debian ではログは最新のものが /var/log/auth.log で、次が /var/log/auth.log.1、さらに古いものは圧縮されて /var/log/auth.log.?.gz の形になっているので、

gunzip -c /var/log/auth.log.*.gz | cat - /var/log/auth.log* ですべてを繋げます。
grep "POSSIBLE BREAK-IN ATTEMPT" で該当行を抜き出して、
sed -e "s/.*getaddrinfo for //g" -e "s/ failed - .*//g" でサーバー名だけを抽出して、
sort でアルファベット順に並べてから
uniq -cd で同じサーバーからの攻撃が何件あるかを算出

という流れです。

攻撃パターン†

LANG:console
cat /var/log/auth.log.1 | grep "POSSIBLE BREAK-IN ATTEMPT" | head
Apr 25 07:58:36 dora sshd[28659]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:58:39 dora sshd[28661]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:58:43 dora sshd[28663]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:58:46 dora sshd[28666]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:58:50 dora sshd[28668]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:58:53 dora sshd[28670]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:58:56 dora sshd[28672]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:59:00 dora sshd[28674]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:59:03 dora sshd[28676]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 25 07:59:06 dora sshd[28678]: reverse mapping checking getaddrinfo for powersportsupport.com [208.101.55.178] failed - POSSIBLE BREAK-IN ATTEMPT!

ということですので、攻撃はだいたい３〜４秒間隔で繰り返されるようです。

撃退法†

大きく分けて２種類あるようです。

ログを解析して、怪しい相手のＩＰアドレスをブラックリストに追加していくタイプ
頻繁に接続してくる相手をファイアーウォールでシャットアウトするタイプ

1. は、定期的にログを解析して、怪しいＩＰアドレスを /etc/hosts.deny へ追加していくものです。定期解析までの時間、多数のアタックを受け付けてしまうという点と、あちこちのＩＰアドレスからアタックを受けるとブラックリストが肥大化してしまうという点に、多少の問題があります。

2. は、１分間に２回以上の接続が続いたら、そのＩＰからの接続を受け付けない、という設定をするものです。例えば３度目の接続からシャットアウトできるなど、即効性がある点に優れていますが、５分に一回のアタックなど、時間を空けて行われると無力です。

たぶん、両者を組み合わせて使うのが良さそうです。

ログを解析して、怪しい相手のＩＰアドレスをブラックリストに追加していくタイプ†

DenyHosts というのが有名なようです。

http://ibio.jp/index.php?DenyHosts
http://denyhosts.sourceforge.net/

Debian ではパッケージ化されているので、

LANG:console
$ sudo aptitude install denyhosts

でインストール終了です。

いくつか設定項目があるようですが、詳細は連休開けてから。

頻繁に接続してくる相手をファイアーウォールでシャットアウトするタイプ†

http://dsas.blog.klab.org/archives/50208645.html#trackback

に書かれているように、iptables に hashlimit というルールを追加して、頻繁に送りつけられるアクセスをファイアーウォールで落としてしまうという方法です。

こちらの環境は、

LANG:console
$ sudo iptables --version
 iptables v1.4.3.2
$ uname -a
 Linux dora 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux

だったので、上記ページにあった方法がそのまま使えるはず。

こちらも導入結果は週明けにでも。

現状†

/etc/deny.hosts に 400 件近いエントリーが入っているにもかかわらず、今でも

LANG:console
$  gunzip -c /var/log/auth.log.*.gz | cat - /var/log/auth.log* | grep "POSSIBLE BREAK-IN ATTEMPT" | sed -e "s/.*getaddrinfo for //g" -e "s/ failed - .*//g" | sort | uniq -cd
    11 115.111.10.163.static-chennai.vsnl.net.in [115.111.10.163]
    10 176.53.64.218.broad.nc.jx.dynamic.163data.com.cn [218.64.53.176]
     7 57-147-246-190.fibertel.com.ar [190.246.147.57]
     8 84-235-124-106.saudi.net.sa [84.235.124.106]
     8 85-20-190-234-static.albacom.net [85.20.190.234]
     8 abts-kk-static-193.6.166.122.airtelbroadband.in [122.166.6.193]
     3 vps.alispot.ca [76.74.246.213]

みたいにちょびちょび来てます。

とはいえ約１ヶ月を積算してこの回数なので、対処前に比べたら圧倒的に減ってますね。

コメント†

こんな方法があったんですね。参考になります。sshの公開鍵認証方式のみにしてパスワード認証しないのが基本だと思っていましたが。。 -- [bols_blue] 2011-06-08 (水) 15:12:44
本来パスワード認証を切ってしまうのがベストなのですが、全員に強制できない場合にはそこそこの効果はあるかも、という感じでしょうか。数回で破られるようなパスワードを使っていなければ何とか。denyhosts はミスタイプでそれ以降繋がらなくなってしまうという副作用を手動で戻さなきゃならない感じです。 -- [武内（管理人）] 2011-06-08 (水) 18:48:58