タグ「ssh」が付けられているエントリー

某所で運用しているサーバの話なんですが、割と"SSH Brute Force Attack"がヒドく、対策を行わないといけないんですが、せっかくなので、攻撃者がどんなユーザ名でログインを試みているかの統計を取ってみました。

SSH総当り攻撃(Brute Force Attack)の傾向から利用を避けたいユーザ名 - RX-7乗りの適当な日々

おもしろそうなので，便乗してみる．某所のサーバからです．

# cat /var/log/secure* | grep 'Invalid' | awk '{print $8}' |
sort | uniq -c | sort -nr | head -n 100
   1306 test
    723 admin
    666 a
    376 guest
    363 user
    332 oracle
    255 tester
    207 postgres
    171 testing
    169 webmaster
    163 testuser
    157 123456
    155 ftpuser
    151 student
    138 info
    132 test1
    129 temp
    126 alex
    117 123
    115 12345
    108 web
    106 administrator
    104 qwerty
     98 test2
     98 test123
     97 sales
     97 john
     95 tomcat
     94 dan
     94 1234
     93 testftp
     90 adam
     89 paul
     88 zxcvb
     88 sarah
     86 richard
     85 tests
     85 nagios
     84 robert
     83 webadmin
     82 matt
     80 master
     80 fax
     80 demo
     78 user1
     78 patrick
     78 frank
     78 eric
     76 toor
     76 david
     76 backup
     75 abc
     71 www
     71 support
     71 kevin
     70 amanda
     69 mike
     68 michael
     67 adrian
     66 stephen
     65 office
     64 steven
     63 james
     62 wwwrun
     61 irc
     61 andy
     61 abcde
     61 abcd
     60 victor
     60 jack
     59 lisa
     59 larry
     58 public
     58 max
     57 service
     57 martin
     56 peter
     56 dave
     55 jacob
     55 carol
     54 test3
     54 scott
     54 sandy
     53 upload
     53 tony
     53 louise
     53 linda
     52 shell
     52 maria
     52 library
     52 jessica
     51 ben
     50 brian
     49 students
     49 linux
     49 client
     49 bill
     48 victoria
     48 mailtest
     48 cyrus

なるほどなるほど．こういうユーザ名をログイン可能にしておいてはいけないんですね．わかりました．ちなみに，現所属サーバだとsshに制限をかけているので，情報が少ない・・・．

# cat auth* |grep 'Invalid' |awk '{print $8}' |sort |uniq -c |sort -nr
      1 toor
      1 test
      1 staff
      1 spd
      1 oracle1
      1 master
      1 admin

効果はあるようだ．

まとめ：
sshは公開鍵認証で．

そろそろファイナルにしたいっす．回線が開通したので，接続テストやらなんやらやってたら，起動しなくなりました（ぇ．いや，まぁ，事なきを得たんですが，ヒヤリでした．

で．予想通りトラブルに見舞われています．全く理解できません．

・svn+sshできない
できないというのは嘘で，できるんだけど，できない．できる状況は以下の通り．

• サーバ内から，svn+ssh://ループバック/
• サーバ内から，svn+ssh://外部IPアドレス/
• サーバ内から，svn+ssh://FQDN/
• 研究室内回線から，svn+ssh://内部IPアドレス/

ダメな状況は以下の通り．

• 研究室内回線から，svn+ssh://FQDN/
• 研究室内回線から，svn+ssh://外部IPアドレス/
• 研究室外回線から，あらゆるsvn+ssh

FQDNは内部DNSで内部IPアドレスに変換しているはずです．少なくとも，nslookupではそう返事が返ってくる．外からFQDNへのアクセスは管轄上位のDNSによって外部IPアドレスが返されます．だからこそ，FQDNでアクセスしたいのだが・・・．

svn単体は許可していないので，sshポートフォワードが必要になるのだが，どうも外部線から入ろうとするとダメなようだ．何故だ．sshはどこからでも繋がるのに・・・．事実，svn+sshではなく，ssh単体はどこからでも繋がる．誰か・・・助けて＞＜．

で．自宅に帰ってきてからVPNを使わずに外部線でsvn+sshしたら，普通に繋がった件について．ぇー．もうこうなったら，研究室内部のネットワーク構成がおかしいってことじゃないですかー．もしくは，オレのPCがおかしいってことじゃないですかー．明日もトラブルシュートか．

・Satisfy Anyできない
研究室構成員だけが見られるようにしたいディレクトリがある．そこにパスワード認証をかけて，研究室外からはパスワード認証で，研究室内からはIP制限で通したいのだ．だから，.htaccessでsatisfy anyだ．だから，こう書いた．

AuthUserFile /etc/.htpasswd
AuthGroupFile /dev/null
AuthName "Please enter username and password"
AuthType Basic
require valid-user

Satisfy Any
order deny,allow
allow from 127.0.0.1
allow from 192.168.11.0/24
deny from all

なんがー！なにがダメがー！わからんちん．誰か・・・ボスケテ．

200811191047追記：
今日になったら両方とも絶好調稼働中な件について．なんじゃそら．きっと無茶苦茶な設定を繰り返す内に，オレPCのDNSやらなんやらがおかしかったんだろうなぁ・・・．再起動してテストしてたつもりだったんだけどなぁ・・・．

研究室からsvnのリポジトリに繋がらなくて，一瞬絶望した．やべっ！今日の仕事が出来ねー！って思ってしまった．そこはそれで，そうなれば，必死に何とかするわけです．というわけで，今日はsvn+sshを実現する方法を説明します．

まず，条件．サーバはVine3.2上で，subversionが動いています．ポートは適当に決まっていて，サーバのFWは通過できるようになっています．クライアントはWindowsでTortoiseSVNが動いているものとします．クライアントは学校側のFW下におり，svnプロトコルでの接続はブロックされている．httpおよびsshは接続可能であることを確認済み．この状況下で，svn（プロトコルではなく）を使えるように頑張る．

httpかhttpsでdav_svnという方法も考えたんだけど，自宅との運用性を考えたとき，httpじゃねぇ・・・．ということで，svn+sshを試みることにした．既にsshが使える環境であるならば，やるべきことは至って簡単．サーバ側で設定することは何もない．設定は全て，クライアント側のみだ．

上の画面はTortoiseSVNの設定画面である．赤枠に注目していただきたい．ネットワークの項目から，SSHクライアントを設定する．TortoiseSVNにはTortoisePlinkなるSSHクライアントが付属されているので，それを使えばいい．至って簡単だ．SSHクライアントの設定欄は以下のように設定する．

tortoisePlink -l ユーザ名 -i 秘密鍵のフルパス

なんという簡単さ．さて，ここで注意したい．Plinkという名前でティン！と来たあなたは鋭い．このTortoisePlinkはPuTTYベースなので，鍵情報はPuTTY形式じゃないとダメなんだ．だから，PuTTYをダウンロードして，puttygenを起動させる．初めて鍵を作る人は普通に作ればいい．それはどこかのサイトを参照のこと．今回はOpenSSHで作成された鍵をPuTTY形式に変換する．

読込からOpenSSHで作った鍵を読み込んでやると，このように上図のように表示される．指示通りに，秘密鍵の保存をすればいい．拡張子.ppkが付くので，同じ名前で保存してもいいんじゃん？さぁ．鍵の準備が出来たので，先に説明したSSHクライアントの設定で，鍵情報を追加しておこう．

最後に，svn+sshで接続できるように，リポジトリの再配置を行おう．

既に再配置済みなので，どちらも同じアドレスになっているが，以下のような書式で指定する．

svn+ssh://ユーザ名@サーバアドレス/リポジトリのディレクトリ

まぁ，今までsvnプロトコルを利用していた人なら，"ユーザ名@"をサーバアドレスの前に付けるだけです．簡単だねっ！enjoy!

んなバカな！っていうタイトルが付いてますが，事実です．XREAは普通にSSHで入るとrbashという制限モードで繋がります．どのぐらい制限されているかって？

yocchan440@s319:~> ls
rbash: /bin/ls: restricted: cannot specify `/' in command names
yocchan440@s319:~> cd /
rbash: cd: restricted
yocchan440@s319:~>

正にガッカリな状態である．そこで，bash化を行うわけです．やり方は簡単で，参考サイトをそのまま．これでSSHでの作業時も安心ですねっ！