管理者/sshd への攻撃を撃退 のバックアップの現在との差分(No.3)

更新


  • 追加された行はこの色です。
  • 削除された行はこの色です。
[[公開メモ]]

#contents

* sshd へのブルートフォース攻撃 [#uf3860a9]

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

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

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

* ログの調べ方 [#o84361fa]

疑わしいアクセスに /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]

わんさか出ました(TT

* 解析コマンドの意味 [#k6fb7d03]

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 で同じサーバーからの攻撃が何件あるかを算出

という流れです。

* 攻撃パターン [#b00388eb]

 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!

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

* 撃退法 [#x8a72f23]

大きく分けて2種類あるようです。
+ ログを解析して、怪しい相手のIPアドレスをブラックリストに追加していくタイプ
+ 頻繁に接続してくる相手をファイアーウォールでシャットアウトするタイプ

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

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

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

* ログを解析して、怪しい相手のIPアドレスをブラックリストに追加していくタイプ [#ae91c231]

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

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

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

 LANG:console
 $ sudo aptitude install denyhosts

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

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

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

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

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

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

* 現状 [#sbe75f95]

/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]

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

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

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

#comment_kcaptcha



Counter: 36863 (from 2010/06/03), today: 1, yesterday: 0