2008-03-31
PKCS (Public Key Cryptography Standards)
http://dictionary.rbbtoday.com/Details/term2353.html
公開鍵暗号の規格セットらしい
そういや昔、PKCS#5とか知らずに使ってた記憶があるな
当時は、何がなんだからワカランかったけど。
SMTPoverSSL
http://www.iana.org/assignments/port-numbers
SMTPoverSSLは 465を使うけど、どうやらIANA的にはNGらしい
と言っても、こいつら何もんなんだか・・・・
urd 465/tcp URL Rendesvous Directory for SSM
igmpv3lite 465/udp IGMP over UDP for SSM
P2Pを使用することを前提とした流出を防ぐ方法
その他 |
いっそポジティブにP2Pを使用することを前提にセキュリティを考えてみよう。
使うなって言っても、使うんだし。
前提条件
PC 1台
お金は掛けない(極力)
あまり手間が掛からない
PCが1台だと、ファイルアクセス権限をP2Pアプリから奪うために、
ルート権限を持ったユーザーで動かすのを防ぐ必要がある。
WindowsだとAdmin権限で実行をしない方向にする。
どこから突破されるか判らないので、物理は不可能でも、論理レベルで切り分ける。
てことで、ここでVirtualPCを使う
仮想PC上にOSをインストールして、HDDを完全に仮想に追い出せる。
こうすれば、多分ホストOS上のHDDに直にアクセスする方法は無いはず。
問題はOSだ これは買うしかない。
あとは、極力ゲストOS側からホストOS側へのアクセス手段をなくす。
たとえば、ファイル共有なんかは使わない。
ファイルのやりとりは、Webストレージを経由すれば理論的にはベスト
たぶん、ウィルスチェックもやってくれる。
めんどくさいなら、ゲストOSにFTPサーバでも立てて、ホストOS側からアクセスする。
これで運用すれば、物理HDDの中をなんらかの方向で検査されても
仮想HDDのファイルを消すだけで、完全証拠隠蔽ｗ
悪用しないように。
ビクターの業務情報が流出
ニュース |
http://internet.watch.impress.co.jp/cda/news/2008/03/31/19000.html
もうさ、P2P用のPC配っちゃえよｗ
「希望者にはP2P専用個人PCを貸与します」
誰も借りねーよｗ
フレッツスポット その３
その他 |
って、よく考えたら標準モードでも、どこかとVPNでも張れば問題ないんだけどね。
標準モードでWEP暗号
んで、その上にOpenVPNで・・・
ペイロードよりヘッダの方が大きそうだｗ
フレッツスポット その２
その他 |
WEPで思い出した
1.標準モード
2.高セキュリティモード
2.は、802.1xのサーバ証明を用いた形 クライアント認証を除けば、ほぼ理想系
1.は、なんと、全ユーザーで共通のWEP
セキュリティが無いに等しいだろｗ
普通のユーザーは、標準と高セキュリティの間を求めてると思います。
ビットフリッピング攻撃
http://internet.watch.impress.co.jp/cda/special/2008/03/31/19001.html
んで、帰ってきたエラーのパケット内容が既知なのを元に、WEPを解読する。
んー、この辺の脆弱性は空想力満点だな・・・・
無線LANのフレームの傍受は、勉強がてらやろうと思ったが金が掛かるので止めた
100万くらいあれば、機材が買えます。
JPドメイン
http://internet.watch.impress.co.jp/cda/special/2008/03/31/19001.html
日本語.JPって見かけたことないんだがｗ
メールアドレスに使えないし、使えたとしても海外のサイトじゃ使えないだろうし
流行る要素が全然無い仕組みだな。
プロミスキャストモード
http://e-words.jp/w/E38397E383ADE3839FE382B9E382ADE383A3E382B9E383A2E383BCE38389.html
BroadComのNICはフレームイジッてアプリに渡してる雰囲気があるんだが、
このモードにするとちゃんと取れるんかな？
サーキットレベルゲートウェイ
http://itpro.nikkeibp.co.jp/word/page/10005841/
http://yougo.ascii24.com/gh/36/003667.html
？？ちんぷんかんぷん
セッションフィクセイション
http://www.soi.wide.ad.jp/class/20040011/slides/18/17.html
攻撃者が、一旦Webアプリにアクセスし、セッションIDを取得し、
そのセッションID付きのURLを攻撃対象に踏ませて、ログイン行為を行わせ、
その後攻撃する方法。
そういや、たしかTomcatはアクセスした瞬間にセッションIDを発行してたけど、
Weblogicはセッションに何か突っ込まないとセッションIDを発行しないんだよな
この攻撃対策なのかな
smtp VRFY EXPN
http://www.criterion.sc/sub_notes/Postfix_Security.html
双方ともsmtpのコマンド
VRFY hogehgoe でユーザーが存在するか確認
EXPNはシステムアカウントがあるか確認
KDDIがクアルコムを捨てた？
ニュース |
http://www.nikkei.co.jp/news/sangyo/20080331AT1D3100431032008.html
クアルコムから脱却？
けど、基地局全部入れ替えじゃないか？
2012年の周波数再編前に、TLFかCDMA2000の2Gに入れ替えないと、
全部圏外になっちまうぞ
けど、TLFは2010年からだから、2010年まではCDMA2000の2G整備か
てことは、2010年には、800Mhzと2GとTLF対応の、トリプル対応携帯がでるかもｗ
マルチホーミング
http://e-words.jp/w/E3839EE383ABE38381E3839BE383BCE3839FE383B3E382B0.html
よく忘れるシリーズ
リンクアグリゲーションとマルチホーミングは、言葉がごっちゃになる。
フレッツスポット
その他 |
家の近くの勉強によく利用するガストが、2つともフレッツスポットが使えるので加入
けど、フレッツスポットって加入するのメンドくさいな
いまどき工事待ちはねーだろ？
LiveDoorWirelessはアクセスポイントで加入できて、すぐ使えるのに。
DomainKeys
http://www.atmarkit.co.jp/fsecurity/special/88domainkeys/dk01.html
SenderIDより、重量級か
SPFより、メール転送に強い
SPFだと、メールがリレイされると認証は弾かれるはず
DmainKeysだと、送信元IPは関係なく、署名と鍵で証明が可能。
けど、証明書を取り扱うので、メールサーバの負荷は結構高い
Sender ID FrameWork
Sender Policy FrameWorkと同義らしい
てか、SPFを他社が開発して、SenderIDとして統合したのがMSっぽい。
http://www.microsoft.com/japan/mscorp/safety/technologies/senderid/default.mspx
Sender Policy FrameWork
http://www.atmarkit.co.jp/fsecurity/special/82senderid/sender101.html
メールを受信した側がメールのFromを元に、DNSサーバにIPアドレスを問合せ、
自分から送信しないとか設定できるみたいなので、飛ばさないドメインは登録しとくと
幸せになれるかも。
未処理
その他 |
DRDoS
IPv6 経路情報の集約が可能
IPアドレス 自動構成機能
DomainKeys Identified Mail
TCSEC
SELinux Flask
セキュリティコンテキスト
Type Enforcement TE
Role-Based Access Control
RBAC
IPS
WAS
SAML (日本HPのWebサーバにある http://h50146.www5.hp.com/products/software/security/icewall/topics/gsso2.html)
ECB ElectronicCodeBook
CBC CipherBlockChaining
OFB OutputFeedBack
HMAC
SPD SecurityPolicyDatabase
ISAKMP SA
IPSec SA
AH AuthenticationHeader
ESP Encapsulating Security Payload
ESPトレーラ
XAUTH
PKCS(Public Key Cryptography Standard)
認証書失効リスト CRL(Certificate Revocation List)
OCSP （Online Certificate Status Protocol）
RMON(Remote Network Monitoring)