もう1つ、会社のブログに記事が追加されてます。
SiteGuard Lite の出力ログを Webalizer で解析してみる
https://toe.bbtower.co.jp/20160428/191/
SiteGuard Lite って、機能縮退版って意味なのかと思ってたら違うんですね。ゲートウェイ型ではなく、ホストにインストールするやつを SiteGuard Lite って読んでるそうです。
SiteGuard Lite は、管理画面もついてて、ログも表示されるんですが、それを集計し、グラフ化する機能は別製品になってます。とは言いながらも、マニュアルに記載があるように、Webalizerで解析、グラフ化するためのパッチも用意されてます。
ただ、ベースが古すぎて、最新版の webalizer-2.23-08 では使えなかったので、使えるように書き換えてみました。動作保証無しですが、よろしければ、上記URLからパッチを入手してみてください。
とにもかくにも、パッチ公開をご快諾頂けたジェイピー・セキュアさんには、重ね重ね感謝です :-)
OpenSSHのバグにより攻撃者が短時間で数千のPW推測を可能に。ネットに公開されたsshアカウントのブルートフォースが可能に。通常はOpenSSHは3から6回のログイン試行しかできない。攻撃方法の詳細有り。公開鍵暗号鍵の利用が推奨http://t.co/yzmMfdYHWx
— 高梨陣平 (@jingbay) 2015, 7月 21
PasswordAuthentication yes
ChallengeResponseAuthentication yes
となっているときに、攻撃が成功するというものです。FreeBSD は ChallengeResponseAuthentication が標準で yes になっているので、標的となる可能性が高いようですが、CentOS/RHEL系は、ChallengeResponseAuthentication が標準で no なので、この攻撃は成功しないようです。
ということで、念のためサーバ設定を確認しておくことをお勧めします。一番はパスワード認証を許可しないことですね。もちろん
PasswordAuthentication no
ChallengeResponseAuthentication no
にする前に、公開鍵認証でログインできるようにしておかないと、ログインできなくなっちゃいますけど。
[追記]:
KbdInteractiveAuthentication
Specifies whether to allow keyboard-interactive authentication. The argument
to this keyword must be “yes” or “no”. The default is to use whatever value
ChallengeResponseAuthentication is set to (by default “yes”).
KbdInteractiveAuthentication が個別に設定されている例もあるかも?
ChallengeResponseAuthentication no
KbdInteractiveAuthentication yes
では影響を受けず、
ChallengeResponseAuthentication yes
KbdInteractiveAuthentication no
なら、影響を受けるようです(結局 ChallengeResponseAuthentication 次第? KbdInteractiveAuthentication の存在意義は……)
Reddit についてるコメントも参考になりますね。
OpenSSH keyboard-interactive authentication brute force vulnerability (MaxAuthTries bypass)
http://www.reddit.com/r/netsec/comments/3dnzcq/openssh_keyboardinteractive_authentication_brute/
[追記その2]:
1つ指摘頂きました。
@kunitake Linuxの場合チャレンジレスポンス認証はPAMを使うので、UsePAM yesも成功条件ですね。noにするとチャレンジレスポンス認証がコケちゃいますw
— no root, nobody (@togakushi) 2015, 7月 22
ChallengeResponseAuthentication yes
の場合でも、UsePAM が no であれば、同じパスワードでのログイン不可となるので、攻撃に成功しないよということになります。より具体的には、ozumaさんが表にまとめられている通り、下記の3つのケースで成功しません。
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM no
Also see: sshd_config(5)
http://jvn.jp/niscc/CPNI-957037/
んーログインする時に、Cipher を指定しなきゃいけないってこと?
http://www.gizmodo.jp/2008/11/61m_1.html
そんな彼らからの忠告はこう。「鍵は、クレジットカードを扱うように取り扱おうね」。
またひとつ僕らみんなに心配の種を増やしてくれて、ありがとう。
吹いた(^_^;
Gmail Account Hacking Tool
http://www.hungry-hackers.com/2008/08/gmail-account-hacking-tool.html
via http://feedproxy.google.com/~r/google-mania/iLyZ/~3/Tyta7iRwE5s/1043
ということで
0. Gmail のログイン
1. 右上の「設定」をクリック
2. 下の方にある「ブラウザ接続」で「常にhttpsを使用する」を選択
3. 変更を保存
として対処。実は、Gmail のこの機能がサポートされた時点で、有効にしてたので、別にいいんですけど、こうして脅威が明確になると怖いですね。
ちなみに、この設定後、i-mode でモバイル Gmail にログインしようとすると、
一時的なエラー(502)
恐れ入りますが、現在 Gmail アカウントにエラーが発生しています
〜略〜
お手数ですが、数分後にもう一度アカウントにアクセスしてみてください。
といわれて、接続できなくなります。せつない......
2008年08月25日追記:
この記事のコメントでご指摘を受けましたが、人によっては、「常にhttpsを使用する」の状態でも、imode経由でログインできるそうです。私の環境だと、やっぱりダメでした。なにが違うんだろう......
2008年08月26日追記:
やっと違いが特定できました。「常にhttpsを使用する」を選択した場合、
非SSL用
http://m.gmail.com/
からアクセスすると、imodeでログインできなくなり、
SSL用
https://mail.google.com/mail/x/
からアクセスすると、imodeでもログインできます。納得といえば納得だけど、エラーがわかりずらい......
http://www.namazu.org/security.html.ja#misidentification-utf7-encode
む?ということで、さっそく社内用にRPMパッケージを作っておく。
http://d.hatena.ne.jp/sen-u/20070520/p1
フリーで使える SQLインジェクションスキャナーが列挙されている。リンク先のツールが本物かどうかはよくわからない (^^;
ふと、
http://www.kunitake.org/chalow/2006-06-19.html#2006-06-19-2
で、加入できないMLがあったのを思い出した。もう 1度試したけど、やっぱりダメだった。なんでだ(´・ω・`)
http://itpro.nikkeibp.co.jp/article/COLUMN/20070510/270527/
mod_dosdetector とどっちがいいんだろ? それとも用途が違ってたりする?
IPv6のタイプ0経路制御ヘッダを利用することで、帯域を食い潰す攻撃が可能となるようです。
KAMEプロジェクトにおけるタイプ0経路制御ヘッダ問題の対応
http://www.kame.net/newsletter/20070502/index.ja.html
関連
- Linux Kernel IPv6 Protocol Type 0 Route Header Remote Denial of ServiceVulnerability
- FreeBSD Security Update Fixes IPv6 Type 0 Route Header Denial of Service Issue
しかしこの問題、根本的な解決策がぱっとは思い付きませんね。うーん……
TCP/IPに係る既知のぜい弱性に関する調査報告書 改訂第2版」の発行について
http://www.ipa.go.jp/security/fy18/reports/vuln_TCPIP/index.html
via http://bloghome.lovepeers.org/daymemo2/20070416.html#p02
- 秘密鍵の内容を確認
openssl rsa -in key.pem -text
- CSRの内容を確認
openssl req -in req.pem -text
- 証明書の内容を確認
openssl x509 -in cer.pem -text
- CRL の内容を確認
openssl crl -in crl.pem -text
どっかのサイトで見たやつ。どこだっけ……これかな?
http://chinmai.net/~osakana/tech-memo/wiki.cgi?page=OpenSSL+CSR%2C+%BE%DA%CC%C0%BD%F1%A4%CA%A4%C9%B3%CE%C7%A7%A5%B3%A5%DE%A5%F3%A5%C9
ウェブアプリケーションを作る上で、セキュリティ上、問題となりうる事柄について、実際のコードを元に説明した記事が
Prepare for Attack! - Making Your Web Applications More Secure
http://www.thesamet.com/blog/2007/01/16/prepare-for-attack%e2%80%94making-your-web-applications-more-secure/
に挙げられています。
- SQLインジェクション
- XSRF
概念的な説明だけではなくて、実例があるから、非常にわかりやすいです。再確認の意味も込めて、次の社内での勉強会では、これを取り上げるかなぁ……
最近、なにかと話題の IPA の
「安全なウェブサイトの作り方 改訂第2版」
http://www.ipa.go.jp/security/vuln/documents/website_security.pdf
セキュア Web プログラミング
http://www.ipa.go.jp/security/awareness/vendor/programming/a00.html
もいいよね〜。