1 2 3 次ページ / page 1 (3)

カテゴリ:Security

2016-05-14 Sat


SiteGuard Lite の出力ログを Webalizerで解析 [Linux][Security]


もう1つ、会社のブログに記事が追加されてます。

SiteGuard Lite の出力ログを Webalizer で解析してみる
https://toe.bbtower.co.jp/20160428/191/

SiteGuard Lite って、機能縮退版って意味なのかと思ってたら違うんですね。ゲートウェイ型ではなく、ホストにインストールするやつを SiteGuard Lite って読んでるそうです。

SiteGuard Lite は、管理画面もついてて、ログも表示されるんですが、それを集計し、グラフ化する機能は別製品になってます。とは言いながらも、マニュアルに記載があるように、Webalizerで解析、グラフ化するためのパッチも用意されてます。

ただ、ベースが古すぎて、最新版の webalizer-2.23-08 では使えなかったので、使えるように書き換えてみました。動作保証無しですが、よろしければ、上記URLからパッチを入手してみてください。

とにもかくにも、パッチ公開をご快諾頂けたジェイピー・セキュアさんには、重ね重ね感謝です :-)



2015-07-22 Wed


OpenSSH に MaxAuthTries をバイパスできる脆弱性 [Security]




パスワードの総当りアタックが大変捗ります、という攻撃手法が見つかってしまったようです。

念のためこの攻撃が成功するか確認してみました。上記サイトにも書いてあるんですが、この攻撃が成功する前提として、 keyboard-interactive authentication が許可されてないとダメというのがあります。

具体的には /etc/ssh/sshd_config に

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つ指摘頂きました。



もうちょっと噛み砕いた情報が欲しい場合は、ozumaさんの

sshによるユーザ列挙攻撃"osueta"
http://d.hatena.ne.jp/ozuma/20140623/1403532516

内の、"ちょっと脱線:UsePAMとPasswordAuthentication" の部分が参考になります。

つまりは

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)


2008-11-17 Mon


SSH通信において一部データが漏洩する可能性 [Security]


http://jvn.jp/niscc/CPNI-957037/

んーログインする時に、Cipher を指定しなきゃいけないってこと?


2008-11-04 Tue


61m先から撮った写真で合鍵が作れるソフト [Security]


http://www.gizmodo.jp/2008/11/61m_1.html

そんな彼らからの忠告はこう。「鍵は、クレジットカードを扱うように取り扱おうね」。
またひとつ僕らみんなに心配の種を増やしてくれて、ありがとう。


吹いた(^_^;


2008-08-21 Thu


Gmail の Account Hacking ツールが出回っているらしい [Google][Security]


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でもログインできます。納得といえば納得だけど、エラーがわかりずらい......

Referrer (Inside): [2008-08-25-1]

2008-03-13 Thu


Namazu Security Update [Security]


http://www.namazu.org/security.html.ja#misidentification-utf7-encode

む?ということで、さっそく社内用にRPMパッケージを作っておく。


2007-05-21 Mon


SQL injection スキャナー [Security]


http://d.hatena.ne.jp/sen-u/20070520/p1

       フリーで使える SQLインジェクションスキャナーが列挙されている。リンク先のツールが本物かどうかはよくわからない (^^;


2007-05-20 Sun


日本DNSオペレータズグループ [Security][DNS]


ふと、

http://www.kunitake.org/chalow/2006-06-19.html#2006-06-19-2

で、加入できないMLがあったのを思い出した。もう 1度試したけど、やっぱりダメだった。なんでだ(´・ω・`)


2007-05-14 Mon


mod_evasive [Apache][Security]


http://itpro.nikkeibp.co.jp/article/COLUMN/20070510/270527/

mod_dosdetector とどっちがいいんだろ? それとも用途が違ってたりする?


2007-05-10 Thu


タイプ 0 経路制御ヘッダに DoS を許す問題 [IPv6][Security]


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

しかしこの問題、根本的な解決策がぱっとは思い付きませんね。うーん……


2007-03-02 Fri


OpenSSL の確認コマンド [Security][Apache]


- 秘密鍵の内容を確認

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


2007-02-02 Fri


攻撃に備える! [Web][開発][Security]


ウェブアプリケーションを作る上で、セキュリティ上、問題となりうる事柄について、実際のコードを元に説明した記事が

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

もいいよね〜。