|
|
| |||||||
| |||||||||
巻き戻し中。
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2010-01-27(水)
やっと [長年日記]
_ 
UDP
全く別の案件だが、偶然にも内部のActiveDireatoryがらみと外部のDNSでUDP故の問題に当たったぽい。
アプリケーション側でフォローがなければ、廃棄やフラグメントで順番狂うとアウト。(´Д｀)
そりゃそうだ。
特に外部は経路上のどこでポイされたか後から知ったり再現するの難しす。
(´-ω-`)
2010-01-24(日)
鯖で [長年日記]
_ 試しに
mod_securityでちょろっと拡散防止の保険と、一部対策。
「SecResponseBodyAccess On」にして、以下のルールを作成してinclude。*1
読み込む順番は、先の方が良いね。
後ろの方だとエラーになったり挙動が変わる。
POSTされてくる内容やファイル、Referrerも一応確認。
手口は内部からftpアカウント盗んでだから、まともに外から来る可能性は低いが念のため406。
RESPONSE_BODYも見ているので、万一変なファイル置かれても、他人様が読んじゃう前に415で止める。
まぁ、こんな感じ。。。（「/＊C●DE1＊/」を含むhtmlファイルを置いてみた）
でもなぁ、ftpアカウント取られた時点でこの程度のルールぐらい書き換えられちゃってもおかしくないよね。。。
「気は心」程度かな。
*1 例によって自爆しないよう、「＊」を全角にしてるお(＾ω＾）
SecRule REQUEST_HEADERS|ARGS "/\＊L●PL\＊/"\ "status:406,phase:2,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2" SecRule RESPONSE_BODY "/\＊L●PL\＊/"\ "status:415,phase:4,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2" SecRule REQUEST_HEADERS|ARGS "/\＊CO●E1\＊/"\ "status:406,phase:2,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2" SecRule RESPONSE_BODY "/\＊CO●E1\＊/"\ "status:415,phase:4,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2" SecRule REQUEST_HEADERS|ARGS "/\＊G●U GPL\＊/"\ "status:406,phase:2,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2" SecRule RESPONSE_BODY "/\＊G●U GPL\＊/"\ "status:415,phase:4,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2" SecRule REQUEST_HEADERS|ARGS "/\＊Ex●eption\＊/"\ "status:406,phase:2,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2" SecRule RESPONSE_BODY "/\＊Ex●eption\＊/"\ "status:415,phase:4,t:none,log,deny,msg:'It includes suspicious keyword such as Gumblar',severity:2"
_ RESPONSE_BODY
そう言えば、この項目がなかなかフィルタされずに半日悩んだ。
RESPONSE_BODYの項目を読むと「SecResponseBodyAccess On」と「MIMEタイプ設定*1してね」ぐらいしかマニュアルに書いていないのだが、SecResponseBodyAccessには、
Dependencies/Notes:
This directive is required if you plan to inspect HTML responses.
This directive must be used along with the "phase:4"
processing phase action and RESPONSE_BODY variable/location.
If any of these 3 parts are not configured,
you will not be able to inspect the response bodies.
だと。
いや、ずっとphase:2でやっていて悩んでしまった。
ちなみにマニュアルの図を見ると、本来「REQUEST_HEADERS」はPhase1っぽいが他の例を見てもPhase2になってる。
結局Phase2とPhase4で分けてみた。*2
ふーん( ´_ゝ｀)
2010-01-23(土)
詐称 [長年日記]
_ spam
このところSpamAssassinとClamAVでほぼ誤検知無しな環境な訳だが、思い出したように[spam]マーク付けたヤツをチェック。
ふむふむ、、、、
ヘッダを見たら「onvt.com (localhost [123.22.185.181] (may be forged)) by・・」だと。
涙ぐましく「localhost」に詐称しとるわと思ったら、「onvt.com」も偽装。
Daemon5# nslookup 123.22.185.181
Server: Daemon5.uekusa-com.com
Address: 0.0.0.0
Name: localhost
Address: 123.22.185.181
しかし、nslookupで「localhost」返してくるとはｗｗｗｗ
ちなみにwhoisしてみたがこいつはダミー
Domain Name: ONVT.COM
Administrative Contact:
Rae, Kathryn kathy@raemedia.com
Winfield
Lake Country, BC V4V 1Y3
CA
766-2500
で、IPでwhoisしたヴェトナムのこいつ！
inetnum: 123.22.0.0 - 123.22.255.255
netname: VNPTinfrastructure-NET
country: vn
descr: Vietnam Posts and Telecommunications(VNPT)
admin-c: NXC1-AP
tech-c: KNH1-AP
status: ASSIGNED NON-PORTABLE
changed: hm-changed@vnnic.net.vn20081016 20081016
mnt-by: MAINT-VN-VNPT
source: APNIC
123.16/12*1って結構広大だな。
ちなみに123.16-123.31の間はどこを逆引きしても「localhost」ってspamウハウハ仕様です((´^ω^))ゥ,、ゥ,、
まぁ、一生ヴェトナムには用事がないので丸ごとバッサリでした。
つーか、( ゜Д゜)＜氏ね！
*1 123.16.0.0 - 123.31.255.255
2010-01-22(金)
一応 [長年日記]
_ 胃ガメラ？
午前中に無事完了。
相変わらず苦手だ。
「うぇっｗｗｗｗ」じゃなくて「うぇっおぇっ」って感じで。
もうね、メガネ外してるし涙目で、「ほら見える?」とか言われてもそれどころじゃねぇよ。
結果は「あー、キレイに治ってるねぇ」だそうで。
原因ねぇ。。。仕事も酒も大して変わっておらんですよ。
(´-ω-`)
2010-01-21(木)
がんばる [長年日記]
_ 今流行の
がんぷら*1じゃなくてGumblar。
総当たりで「ぁゃιぃ埋め込まれたIFRAME/SCRIPT」を検索するソフト発見(*゜Д゜) ムホムホ 。
一昨日から試してみようと思っていたのだが、忘れていた。
で、ローカルのネットワークからおいら鯖にスキャン掛けると若干取りこぼすので、待ち時間を入れる方が良いみたい。
パターンの追加変更も出来るし、動的ページもとことん追いかけてくれるので便利。
でも、cgiのパターンもリンクがあれば全部叩くだけに激しく時間と負荷がかかる。
まぁ、動的ページに埋め込まれていないという保証もないわけで、安全サイドから考えたら仕方が無いか。。。。
*1 いや、そりゃケロロ軍曹が大好きなヤツｗ
2010-01-17(日)
脆弱 [長年日記]
_ 暗号化
強度が弱いとまた言われた。
ふむふむ。。。
httpd/sendmail/qpopperそれぞれあるわけだが、、、
ApacheやqpopperはSSL/TLSのバージョン指定が出来る。
なので、TLS/SSLv3だけの指定があれば
'ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM'
と
'ALL:!SSLv2:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM'
は同じ結果。
でも、そんなの関係ねぇsendmail.cfは結果が違っちゃう。
/usr/local/bin/openssl ciphers -v 'ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM'
/usr/local/bin/openssl ciphers -v 'ALL:!SSLv2:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM'
それぞれの結果を見ると分かる。
要は明示的に書いた方がより安全みたいなので、
ALL:!SSLv2:!NULL:!EXPORT56:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:+SSLv3:+TLSv1
にしてバッチリ。
| Tweets by RC31E | |||||||||
| |||||||||
| |||||||||
| |||||||||
