テスト用のサンプルウイルス EICAR - アンチウイルスの動作確認

アンチウイルスソフトを導入したら、動作確認がしたくなるだろう。
 

そんな時は悩まないで EICAR を頼ろう、アンチウイルスのテストファイルがダウンロードできる。 中身は単純なので自分で書いてもOKらしいが。
 
 

大体アンチウイルスで代表的な各社でも、「安全にテストしたけりゃ eicar 使えばいいよ。」というように紹介されている。テスト用として認知されている存在というだろう。
 
各製品共通テストウイルス < < トレンドマイクロ
 
EICAR test string を使って Norton AntiVirus をテストする方法 < < Symantec
 
カスペルスキー製品の効果を確認するためのテスト用ウイルス EICAR とは？– その使用法と入手方法 < < Kaspersky Lab

カスペルスキーだけ なんで報道記事っぽい見出しなんだ。
 
 


さて実際にダウンロードしてみる。。。
や否や、
[caption id="attachment_1267" align="alignnone" width="519" caption="画像：Windows Defender の警告"][/caption]
 
ぬお！ Defender って仕事してたのか！
初めて見たぜ Windows Defender の警告。
 
 

まあ無視してダウンロード、カスペルスキーラボの オンラインウイルススキャナ(ファイルスキャン) に突っ込んでみよう。
 

[caption id="attachment_1268" align="alignnone" width="685" caption="画像：カスペルスキーファイルスキャナ(オンライン)"][/caption]
 
うむ、見事な陽性反応。
たまに本物でテストしようとするのを見かけるが、危ないのでやめような。
 
 


最後にひとつ、いきなりeicar を送りつけてくる奴には気をつけたほうがいい。 テスト検知と見せかけて、本物を送りつける(または紛れ込ませる) といった悪知恵を働かせる輩もいるからだ。
 

PCIデータセキュリティ基準(PCI DSS)、v1.1とv1.2の要件概要を比較する

結論、概要レベルだと一緒です。
 

でも日本語訳がちょっと違う、折角なので比較のために原文、日本語v1.1・v1.2 を並べてみました。※違いがあるところだけ併記。
 

ちなみにバージョン別の各国版はどれも PCIDSSの公式サイト からPDFのダウンロードができます、規約に同意してね。
 

では比較版を。全く意味はないが変更について至極どうでもいいコメントもしてみよう。
 

Build and Maintain a Secure Network
安全なネットワークの構築・維持

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  要件1： カード会員データを保護するためにファイアウォールを導入し、最適な設定を維持すること


• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
  要件2： システムパスワードと他のセキュリティ・パラメータにベンダー提供のデフォルトを使用しないこと

 
全く変わらない、ファイアウォールは運用の要件が変わってたがここでの表現は同じ。
 

Protect Cardholder Data
カード会員データの保護

• Requirement 3: Protect stored cardholder data
  要件3： 保存されたカード会員データを安全に保護すること (1.1)
  要件3： 保存されるカード会員データの保護 (1.2)


• Requirement 4: Encrypt transmission of cardholder data across open, public networks
  要件4： 公衆ネットワーク上でカード会員データを送信する場合、暗号化すること

 

要件3、「安全に保護」だと二重表現っぽいということかな？頭痛が痛いみたいな。
保存の仕方や情報の範囲にも要件はあるので、「保存された」→「保存される」は良い変更だと思ったら、資料のうち詳細のところでは元のままだった。
 

Maintain a Vulnerability Management Program
脆弱性を管理するプログラムの整備

• Requirement 5: Use and regularly update anti-virus software
  要件5： アンチウィルス･ソフトウェアを利用し、定期的に更新すること


• Requirement 6: Develop and maintain secure systems and applications
  要件6： 安全性の高いシステムとアプリケーションを開発し、保守すること

 

Implement Strong Access Control Measures
強固なアクセス制御手法の導入

• Requirement 7: Restrict access to cardholder data by business need-to-know
  要件7： カード会員データへのアクセスを業務上の必要範囲内に制限すること


• Requirement 8: Assign a unique ID to each person with computer access
  要件8： コンピュータにアクセスする利用者毎に個別のID を割り当てること (1.1)
  要件8： コンピュータにアクセスできる各ユーザに一意のIDを割り当てる (1.2)


• Requirement 9: Restrict physical access to cardholder data
  要件9： カード会員データへの物理的アクセスを制限すること (1.1)
  要件9： カード会員データへの物理的アクセスを制限する (1.2)

 
要件8、「する」を「できる」に変更してきました。外的要因への対応？といった所でしょうか、イメージしやすくなったかも。
要件9はなぜかここだけ「こと」のみカット。他に比べてここにはむしろ必要な部類なんじゃあなかろうか…？
 

Regularly Monitor and Test Networks
定期的なネットワークの監視およびテスト

• Requirement 10: Track and monitor all access to network resources and cardholder data
  要件10： ネットワーク資源およびカード会員データに対するすべてのアクセスを追跡し、監視すること (1.1)
  要件10： ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する (1.2)


• Requirement 11: Regularly test security systems and processes
  要件11： セキュリティ・システムおよび管理手順を定期的にテストすること (1.1)
  要件11： セキュリティ・システムおよびプロセスを定期的にテストする (1.2)

 
要件10、「資源」→「リソース」、ちょっとハイカラな表現で演出してきましたね。
なのに全体で AおよびB を CおよびDする となってちょっとオシャレ度ダウンな印象、およびおよびな。
要件11もハイカラですね、でも1.1の意訳っぽい表現のほうがマッチしていたかも。
 

Maintain an Information Security Policy
情報セキュリティ・ポリシーの整備

• Requirement 12: Maintain a policy that addresses information security
  要件12： 情報セキュリティに関するポリシーを整備すること (1.1)
  要件12： 情報セキュリティポリシーを整備する (1.2)※

※要件12、PCIDSS資料本文のところでは「従業員および派遣社員向けの情報セキュリティポリシーを整備する」になってます。見出しから変えすぎじゃない？
 
セキュリティにまつわるエトセトラ、的な表現から単体指名になってますね。まあ 大体あってる ので分かりやすくなった、ここは潔くてナイス。
ただ本文のほう、従業員および派遣社員向け だけじゃなくて サービスプロバイダ向けもあるので本文の追加見出しに不足があります、注意。
 
 
 

v1.1 で見られる文末を「・・・すること」で統一するというポリシーがなくなった模様。
あと範囲が限定的すぎた表現を適切になるよう変更したといった感じですかね。
「・・・すること」全廃でもいいと思うけどなあ。

第17回まっちゃ１３９勉強会に行ってきました

今日は黒七味を買いに京都へ行きました、お子様向けに生八つ橋いちごチョコレートもね。
 

[caption id="attachment_1180" align="alignnone" width="240" caption="写真：黒七味と八つ橋"][/caption]

[caption id="attachment_1181" align="alignnone" width="240" caption="写真：東本願寺前から京都タワー"][/caption]

 
 

早速の脱線から閑話休題、と言うわけで「第17回まっちゃ１３９勉強会」行ってきたのでちょいレポ、あえて味については書かない。
スタッフの皆さん、講師・LTそして参加者の皆さんお疲れ様でしたー
 

基本的に勉強会の内容については、詳細は口外無用というポリシーがあるので当たり障りがなさそうな話で感じた内容をメモっておこう、自分のメモなので内容については保証できないです。
（当たり障りのある話があったか？と聞かれても困るけど）
 
 

008年セキュリティインシデント総まとめ（仮題）（小野寺匠さん）

この辺→「日本のセキュリティチーム (Japan Security Team)」のお方。
 

●悪さをする人の狙いの変遷。99年-01年くらいはWEB改ざん、それ以降はクライアントの脆弱性をつくように。組織的に行われ、手段が洗練化してきてたちが悪く。
●(だいぶ丸めて)WindowsUpdateはやろう。リリース版の無印WIndows、SP1はマズイ。SP2からはマシ。
●日本はセキュリティ的にレベル高め、
●Windowsを直接WEBにつなぐと危ないの当たり前なので、ISPはモデム貸すのは完全にやめて、ルータだけにしてほしい。
（これについては日系NETWORKにもあったが、WinXPのSP2未満はインターネット直接接続すると 4分でなにかしら感染するらしい。。）
●昨年の"MS08-067"はブラスターみたいに流行ってもおかしくなかった、当時に比べ個人のPCのパッチ適用率が上がってたりと拡散しにくい状況になったのかな。
●USBメモリによる感染増加、USBの自動再生いやならGPでとめたり。
●MD5の証明書やめようねー
 

まあその他もろもろ、引き出しの多さには非常に驚き…
 
 

LTは省略しておく、この辺は参加したほうがよさそうだから。
ちなみにテーマはこんなだった。

「アイデンティティ管理入門」ヴァルカンさん

セキュリティ規格色々紹介（題名うろ覚え）F.koryuさん

「その後の龍谷大学理工学部メール環境」セキュメモの小島先生

「UltraVNC SCを使った遠隔サポート」よーいちさん

 

皆さん勉強量がハンパないなぁと感じる、普段の私の仕事は結構「動けばいいや」的なところがあるので、仕様とか規格・ましてその背景など説明されると関心せざるを得ないですね。
モノ作るにあたってはやはり納得いくまで調べないと、または定型化しておかないと結局あとで困るんだよなあと思う。
 

さて、省略してはイカンところとしては宣伝？
セキュリティホールmemo 小島先生のサイト、連日かなりお世話になっている身としては初の生・小島先生に少々感動。
関東の方はまっちゃ445 よろしく？
admintech.jp も要チェック、というか次の「AD×LDAP」とか大好物だ、さすがに東京まで行けないので資料だけでも欲しい…
 

ほか、PCI-DSSは具体的な部分について個人的にまとめサイト作ろうとしてるので（要件に対応するOSの機能・設定をまとめる。）もっと話を聞きたいなあ。
 

「UltraVNC SC」、何気に一番面白かったカモ。。実用向け特化の内容はウチの保守部隊iSTAFFに通ずるものが。

 
 
 

懇親会も行った、まっちゃ139御用達、定番のお店だったらしい。お料理美味しかったです。
色々お名刺の交換させて頂きましたが、普通に取引先の方がいて噴いた、エー。セキュメロにも来られるそう、よしちょっと行ってみよう。
せっかくなのでまっちゃさんに抱きついておいた、「アッー！」
 
 

今回驚いたのは私の所属するアイクラフト社員の女の子がいきなりいたこと、事前情報なし。確かにこないだ誘ったが、くるなら教えてくれよ（笑） 新手のツンデレかと。
ついでに言うと、小野寺さんの発表で彼女はマイクロソフトのイメージが変わったらしい。「仕様ですから」とつっけんどんに御高くとまっている印象が払拭された模様。確かにそういうのはあるかも。
 

ほか Wassr購読中の方々 と話す機会を結構もてた。この辺は結構貴重なんじゃなかろうか。
 

あとは帰りに一緒だった勉強会@徳島 の子。
話を聞くにプログラミングにどえらい情熱を持っていることがよくわかった、素直ないい子だった。「オリジナル言語をつくるぜ」と言ってたので是非がんばって欲しい。
 
 

…こういった高い情熱を持ったエンジニアをを雇用して食わせながら遊ばせたい（もちろん利益はアリで）とする、一部ベンチャー企業の経営者さんの気持ちがわかる気がした。
 

彼らの情熱を業績につなげ、なおかつ市場の活性化と雇用の確保をやっていくという事はITに携る者として目指す姿の一つなのかもしれない。美化しすぎかな？
 
 

とりとめないがこんなもんで。

ITのウイルスも風邪のウイルスも気をつけよう

IT屋のはしくれである私が「ウイルス」と言い出す、コンピュータに妙な動作をさせて被害を与えるアレの話と見せかけた、ちょっとひねってるようで直球な話、長文注意！
 

ここ最近、通勤時など人混みに身をさらす用事では使い捨ての不織布マスクを装着している。
早い話が 風邪、インフルエンザ等、空気感染のウイルス対策をしているということなんだが、マスクのほかにも拠点に着いたら手洗いうがい、なんとなく体を払っておいたりと、気がつく範囲で対策に余念ないよう心がけている。
おかげでこの冬は 病気的な理由でで体調が悪かった事は(二日酔いと疲労を除いて)今のところ無い。
 
 

さて、 この辺から本題だけど、セキュリティが低下するといった意味で、コンピュータウイルスと人体に悪影響を及ぼすウイルスはよく似ている。
(そもそもコンピュータウイルスの語源だから当然ともいえるのか。)
好きこのんでセキュリティ勉強会（まっちゃ139等）に参加したりする身としては、やはり健康に起因するセキュリティ事故にも注意を払うべきだと思うわけです。
 
 

まあちょっと比較してみよう、まずは個人単位でのセキュリティ。

• コンピュータウイルスで自分のPCがやられる
  →復旧作業に丸一日、業務に支障


• 風邪ウイルスで自分の体がやられる
  →一日仕事休み、業務に支障

 

さらに対処を遅らせ無理して動かすと…

• コンピュータウイルスはどんどん拡散・感染
  →周辺のPCに被害拡大、業務に大幅な支障


• 風邪ウイルスは周囲に拡散・感染
  →体調不良者続出、業務にも結構な支障が

(※この辺は定義的にワームも入っている気もするが、まあこのくだりでは広い意味でウイルスとまとめてよいでしょう。)
 

どちらもやっぱり被害はでかい、今の時期に人混みでマスクしない(＝自衛しない)のはまあ仕方ないけど、自らが咳をしているのにまったく無防備という方を見受けると、セキュリティの意識が低めなのではないかと思ってしまう。
 
少なくともウイルス撒いてそうなのがいたら身を守る手段、たとえばマスクなど持ち歩くほうが良いのではないかと思う。
 
 

コンピュータウイルスの影響は一部の業務停止から始まり、情報漏えいだとかによる会社の社会的信用低下といった副作用が直感的にわかりやすい、新聞沙汰もざらだし。
それを受けて、「なるほど気をつけるべきだ」というのは分かる、興味をもって調べる・対策を講じる人が多くなるのも自然でしょう。
 

ここでちょっと考えて、「なんで対策するの？」って話になった場合、やっぱり業務停止するのが嫌なんだったり、悪い影響が広がると後々面倒だということになる。
 

それはそのまま人体向けのウイルスにも当てはまると考える。
インフルエンザ感染しやすいウイルスが広まると学校は閉鎖、病院はごった返しとそれこそ社会的にどえらいことになるわけで、一社の信用が失墜するのとはまた違った意味で影響がでかいんですよね。
 
 

長くなったけども、情報セキュリティに気をつけると自負するならば身の健康もしっかり守ろう、ということが言いたかった、ウイルスが原因で体調崩すのは立派なセキュリティ事故だよと。これは大いに啓発したい、あとコンピュータのアレをウイルスになぞらえて表現した最初の人もリスペクトしたい、誰だか知らないが…
 
 

しかしここ数年で気づいた事で面白い事例がある、やや主観に基づいてるけど子供を生んだ母親は（大体）強い。ウイルスなんてへのカッパ。
ノロウイルスだ何だと父娘が苦しんでいても平気で面倒みている、あれらは少々特殊なのかも知れないなぁ、そのへん誰か解明してないかな。

第17回まっちゃ１３９勉強会に参加申込みした(1/17)

社外の勉強会に参加する、ということで京都を拠点に関西でセキュリティを勉強しようという「まっちゃ１３９」に参加してくる、2回目。
 
 

勉強会、懇親会の内容や申込みは下記から。
第17回まっちゃ１３９勉強会

第17回まっちゃ１３９勉強会懇親会
 

日本のセキュリティチーム (Japan Security Team) や セキュリティホール memo の中の人が講師＆ライトニングトークをされるようでとても面白そう。
(間違ってたらごめんなさい。)
 
 

うちの会社は勉強会参加費＆交通費を出してくれるので助かる、会社の名前くらいは言ってあげよう。懇親会は実費で参加。
前まっちゃに参加したときは懇親会行かなかったけど今回は行こうかな、admintech.jp のに行ってみたら面白かったので。
京都なのでちょっと遠いのがやや心配。
 

sendmail で リレーするメールの DATA 部分をログに記録する

sendmail を使っているメールサーバでちょっと調べ物があった。
 

取りあえずメールのヘッダを記録したかったので、 sendmail.cf にてログレベルをデフォルトの9から11 → 15 → デバッグの → 16 → 20くらいまで引き上げたが、エンベロープは記録されるものの、肝心のDATAの中身が記録されなくて困った。
 
 

何か別の手段はと思い、Manpage of sendmail を見たら物騒なオプションを発見

-X logfile
指定された logfile に、メーラに出入りする情報すべてを記録します。メーラをデバッグする際の最後の手段としてのみ使ってください。非常に大量の情報があっという間に記録されます。
Manpage of sendmailより

まあ行儀が良さそうなオプションじゃないな。
 

早速起動スクリプトのsendmail 起動コマンドラインに "-X /var/log/maildata" とでも追加して起動したところ、思い通りDATAの中身が丸ごとログに吐かれた。
 

これで"Message-Id:" や "Subject:" も確認し放題、もちろんメール本文もだ。
悪用厳禁やね。
 
 

---

追記：2009/4/9
姉妹ネタを作成、ログがでかくて困るという時にはこっちでも。
sendmail の .forward で、メールの任意の行をログに出力
 
 

冬期の長期休暇を控えて：JPCERT/CC が注意喚起

JPCERTコーディネーションセンター(JPCERT/CC) が年末年始長期休暇を控え、管理者向けの注意喚起 冬期の長期休暇を控えて を公開しています。
 

昨年はやったUSBメモリ(外部記憶)の自動実行については、下記のように特に注意するよう呼びかけ。

外部記憶装置を媒介したウイルス感染が増加:

昨今 USB メモリやフラッシュメモリーカード、外付型ハードディスクなどの外部記憶装置を媒介したウイルス感染が増加しています。
休暇中に社外で使用した外部記憶装置を社内の機器に接続する場合は、ウイルスの感染を防ぐためにシフトキーを押しながら PC に外部記憶装置を接続することで自動実行を一時的に無効にすることを推奨いたします。
また、内容を確認する前にウイルス対策ソフトでスキャンを行って下さい。

 

「シフトキーを押しながら PC に外部記憶装置を接続する」
ああ、そんな手があったな。これなら繋いでゆっくりスキャンでもOKだ。
 

ちなみにWindows起動時のスタートアップもシフトキー押してれば回避できる。
 

他、休み明けの心得とかを紹介しているので、会社・自宅問わず管理者な方は目通ししておいては。

WebDav DELETE コマンドは、IIS 6.0 の仮想ディレクトリのパスの長さの合計 が 4096 バイトを超えた場合を実行しているサーバー上のすべての Web サイト コンテンツを削除します。@MicrosoftKB

はてなダイアリー インフラ管理者の独り言（はなずきん＠酒好テム管理者）
で見つけたIIS6の不具合、内容はタイトルのとおり。
 

修正パッチの配布や詳しい内容はこちら→ マイクロソフトKB(修正パッチ込み)
 
 

要はパスが長すぎると、根こそぎ消されるぞ という事だ。気持ちは分かるが、そこはこらえて欲しいな。

ニンテンドーDS（無印）のWi-Fi接続をバッファローの Wi-Fi Gamers(WCA-G)で (がんばって)セキュアにやる

ニンテンドーDS（無印）では無線の通信暗号化方式が WEP しか使えない。
自宅に無線LANこそ導入はしているが、そこは当然 WPA(AES)を使ってる、WEPも選択できるが…ITPro：利用率7割のWEPは「1分」で破られる こんな現状なのではっきり言って使いたくない、使えない。
 
 

しかし実際に ニンテンドーDS を使う子はそんな事情なんて知ったこっちゃない、Wi-Fi やりたいと頼まれちゃあなんとかする方法を模索するしかない。なんでWiiはブリッジにならないんだよ！（言いがかり）
 

ちなみに新しい ニンテンドーDSi はWPA にきっちり対応している、それ買えって？
だって 古いDS壊れてないし DSi高いし WEBブラウザなんて余計な機能がついてる（注：もちろん制限できるんだけど…いまいち不安）しで却下、そんなにコスト掛けたくない。
 
 

で、既存の環境に影響がでないように安手のAPを追加として、これ使うことにした。

 
 

「BUFFALO Wi-Fi Gamers 無線LANアクセスポイント WCA-G」に電源スイッチを組み合わせた。

結論から言うと「電源OFFにしてWEPの脆弱性から身を守る」という運用を課すことで親子間のSLA合意した。
↓構成はこうだ。
[caption id="attachment_1045" align="alignnone" width="300" caption="写真：WCA-Gと電源スイッチ"][/caption]
 

子には「DSでWi-FiしたくなったらスイッチON、終わったら切ってくれ」とした。ACアダプタにくっついている電源スイッチだ、LED付き でお子様にも分かりやすくしている。
うちの環境では常時起動のマシンはない為、これで十分。 「Wi-Fi Gamers(WCA-G)」 の起動には15-20秒ほどかかるが特に気にするほどではない、ポケモンのWi-Fiセンターに突撃している間に準備は完了している。
 
 

予想以上にコンパクトサイズだった

[caption id="attachment_1046" align="alignnone" width="225" caption="写真：AirStatonとWCA-Gのサイズ比較"][/caption]

[caption id="attachment_1047" align="alignnone" width="225" caption="写真：WCA-G持ってみた"][/caption]

 

すごい小さい。
 
 

初期設置は楽なもんだった、液晶小窓もよい感じだ

ニンテンドーDS は AOSS に対応している、で、 この 「Wi-Fi Gamers(WCA-G)」 もAOSSで設定するようになっている。
説明書の設定方法には「AOSSでつなぐのでこのボタン（上についてるデカいボタン）押せ」程度のことしか書いてない。
まあそれで済むからいいや。
 
液晶小窓、ステータスが表示できる。 「起動中」 → 「起動完了」 ってちゃんとわかるので今回の運用方法にかなりマッチ。
画面下のカーソルキーで少し操作できる、環境確認やチャンネル変更が可。ファームのアップデートなんかもできるようだが、発売以来新しいのは一つもないようなので確認できず。
 
 

説明書にはなぜか載ってないWEB設定画面に注意、使いではあるが…

さてこの「Wi-Fi Gamers(WCA-G)」 説明書に載ってないWEB設定管理画面がある。
 
これがとってもいただけないことに、
「root / 空パスワード」 で設定画面に入れる。
んですね、初期設定では。
 
[caption id="attachment_1048" align="alignnone" width="500" caption="画像：WEB設定画面トップ"][/caption]
小窓でIPアドレス確認できる仕様にしといて、これはないだろ。
 

もし「Wi-Fi Gamers(WCA-G)」 を使う場合は、
WEB管理画面のパスワードを必ず設定してください
[管理設定] → [パスワード] で変更できます。
 

AOSS なので「無線ANY許可」、DS なので「WEP」 となかなか強力なカードがそろっている中、Root空パスはアカンやろうに。
 
 

パスワードさえ設定してしまえば、WEB設定画面はそれなりに使いでがある。クライアントモニタや許可済み機器の状況も把握できる。
[caption id="attachment_1049" align="alignnone" width="500" caption="画像：WEB管理画面の一部"][/caption]
 

まあ自宅ではこの構成に落ち着いたが、普通にWPA（AES）なども対応しているので安手の追加APとしても十分に使える。手軽に無線AP追加したかったらいい商品なのかもしれない、小さいし。
 

くれぐれもWEBのパスワードは忘れないように、液晶でIPわかっちゃうからね。
 
 

iptablesでお手軽なssh総当りログイン試行攻撃対策

有用だと思ったのでメモ、元ネタチェインつきで。
 

元ネタ
sshへの辞書攻撃をiptablesで防ぐ (曖昧スラッシュ)
↑
の元ネタ
sshへの総当り攻撃をiptablesの2行で防ぐ方法 (blog@browncat.org)
↑
の元ネタ
Block brute force attacks with iptables (Kevin van Zonneveld)
 
 

sshに対する攻撃といえば、ブルートフォースや辞書によるログインの試行が代表的、secureログが汚れるわ最悪ログインされるわと大迷惑(事故？)だ。
そもそも不要な接続は許可しないべきなんだけど、接続元のIPアドレスを限定するという事がしづらい場合もある。
 
 

２行の iptables コマンドでSSH攻撃対策をしよう

※テストに使ったOS,バージョン → CentOS5.2+iptables v1.3.5
recentモジュールが必要なので"/proc/net/ip_tables_matches"ファイルに
recentという行があることを確認

iptablesの簡単設定で、一定時間内に複数回ssh接続してきたIPを自動で拒否するようにできる、という情報を見つけたので記事にする。
以前誰かがfail2ban を設定していたのは見たことある。やれることは大体同じのはずだけど、細かい設定とかを管理したいならそちらがいいかもしれない。
 
 

引用すると下記２行でOK(※ eth0 の部分は環境による)。はみ出した分はどっかにコピペで…

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

これで 60秒間に8回のssh接続を仕掛けてきたIPアドレスからの新規TCPセッションを拒否するようになる。
 

ぱっと見では2行目だけで良さそうな気もするが、recentモジュールの使い方がそうなっているのかな。
これでセーブしておけばOSの起動時にもルール有効になり、対策OK。
ほか、初代の元ネタBlock brute force attacks with iptables (Kevin van Zonneveld) に色々注意事項が書いてある、試すなら cron で iptables をリセットしとけとかは面白い記述。
 
 

攻撃されたことをログに残そう

コレだけだとほんとに転載しただけなので芸が無い、とりあえずログに残るようにしておこう。
また、一つ目の元ネタsshへの辞書攻撃をiptablesで防ぐ (曖昧スラッシュ) によると、デフォルトのINPUTチェインを使うだけでは他の通信に遅延が出る恐れが。確かにそうなるかもしれない。
 
幸い、色々考慮済みの iptables のテーブルが前述の元ネタに紹介されている。折角なので パクリ 再現してみよう。
 

実行するiptables のコマンドは下記、セーブなど考慮して無いので注意。

# ssh接続を取りあえずユーザチェインに渡す
iptables -A INPUT -m state --state NEW -p tcp --dport 22 -j SSH_ACCEPT
 
# SSH_ACCEPTチェインの設定、条件マッチでSSH_BFAチェインに渡す
iptables -A SSH_ACCEPT -m recent --set --name SSH_ACCEPT
iptables -A SSH_ACCEPT -m recent --rcheck --seconds 60 --hitcount 5 --rttl --name SSH_ACCEPT -j SSH_BFA
 
# SSH_BFAチェインの設定、ログに書き出してドロップ
iptables -A SSH_BFA -j LOG --log-tcp-options --log-level 4 --log-prefix 'iptables: ssh_bfa:'
iptables -A SSH_BFA -j DROP

 

で、出来たテーブルがコレ。
OK、元ネタ にほぼそっくりだ。これで遅延無し、攻撃者のIPがログに残るiptablesのルールが完成。

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
SSH_ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
 
Chain SSH_ACCEPT (1 references)
target prot opt source destination
all -- anywhere anywhere recent: SET name: SSH_ACCEPT side: source
SSH_BFA all -- anywhere anywhere recent: CHECK seconds: 60 hit_count: 5 TTL-Match name: SSH_ACCEPT side: source
 
Chain SSH_BFA (1 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level warning tcp-options prefix `iptables: ssh_bfa:'
DROP all -- anywhere anywhere

閾値は60秒当たり5回になった。ほか recent が update から rcheck になったが違いがよく分からないな。
 

気になるところとしては、LOGのルールがちょっと違う。
「LOG flags」って箇所がよく分からなかった。TCPフラグで判断する仕様なのかと思ったが、手元の iptables の man ではそれっぽいオプションが見当たらなかったので、代わりに tcp-options を入れた。
ログが詳細になったが、意図するところは多分違うかもしれない。

続・アクセスログの保存期間は3ヶ月を目安にすればいいんじゃないか

ちょっと前のエントリ、「アクセスログの保存期間は3ヶ月を目安にすればいいんじゃないか」の続き。
 


つい先日まで知らなかったんですが、PCI DSS（PCIデータセキュリティ基準)というのがあります。
米国でやっているクレジットカード業界の認定らしい。認定って言うとセキュリティ関連のISMS(ISO27001) や プライバシーマーク 等が思い浮かぶけど、考え方は似たようなものです。
 
ただそれらに比べると、とても技術重視なことが特徴といえるんじゃないでしょうか。←※さわりをちょっとかじった感想なので参考までに。
 

ITProから一部引用

CI DSS（Payment Card Industry Data Security Standard）は，情報セキュリティの向上を目的としたクレジットカード産業の業界基準である。
 
PCI DSSは，クレジットカードのカード情報および取引情報を保護するために，次に示す六つの目的と，それに関する12のデータ・セキュリティ要件を定めている。

 

ほか、PCI DSSの詳しい内容はITProがきっちりまとめてくれています、運用管理者は是非一読を。

ITPro：セキュリティ基準「PCI DSS」
http://itpro.nikkeibp.co.jp/article/COLUMN/20080407/298166/

 
 

PCI DSSでは要件がすごく具体的

なぜこのPCIDSSを記事に引っ張ってきたかというと、示されている用件がとても具体的で有用な定義だと思ったから。
 

どのように具体的か紹介しておきます、分かりやすいので他社さん(日本オフィス・システム株式会社)の記事から引用させてもらいます。「PCIDSS-ISMSとどこが違うのか」が参考になりました。

• リモートアクセスのユーザー認証では二要素認証を導入する


• パスワードの伝送・保管はすべて暗号化する


• 休眠ユーザーは90日ごとに取り除く


• パスワードは90日ごとに変更する


• 直近4回は同一パスワードの使用は不可


• 連続したアクセス試行は6回以内に制限


• ロックアウトは30分


• セッションアイドル時間は15分以上でパスワード入力にする

あふれんばかりの具体性ですね、さすがにお金がらみはシビアです。
 
が、お手本にするにはもってこいですね。
PCIDSSにあげられている要素を並べ、取捨選択。それに適当に期間を設定するだけでとてもセキュリティ管理の行き届いたシステムになることでしょう。
 
 

アクセス・ログを3カ月間保管しなければならない(タイトル引用→引用元)

ようやく本題？
前回提唱した「アクセスログは3ヶ月保存で定義しとけばいいじゃない」に関連したPCIDSSの要件は↓な感じ。

10.7　監査証跡履歴は，少なくとも1年は保管，最低3カ月間はオンラインで閲覧利用できるようにする。

 

ここでも目安として3ヶ月という期間が出てくる。
実は ITProの見出し「3ヶ月間保管」につられ、得たりとばかりに記事を書き始めてしまったが、クレジットカード的には1年保管しろという事のようだ。これでは趣旨が変わる？
 

しかし、いつもお金(取引・決済)関係のように気を使うシステムを作っているわけで無いためここは大きく解釈してみる。
「サーバ本体=1次ストレージ」、「ログ保管場所=2次ストレージ」 とした場合、1次に3ヶ月、2次を含めて1年というという事で妥当な感じがする。
PCIDSSの要件的には最初の3ヶ月時点で「集計済み・閲覧しやすい状態」が求められている気がするが、まあそれは置いとこう。awstats でも logparser でも何でもあるから。
 

2次ストレージを利用するかはシステムの要件次第という事で、基本は「1次ストレージに3ヶ月保管」というポリシーで運用すればよい、とすればやっぱり「ログの保管は３ヶ月でOK」 という結論を仕立てあげることが出来る。
 
 

1年保管はどうしてもログがかさばってしまうので出来ればやりたくない。
OSの初期設定とかもこういうニーズにあわせてあると後で困らなかったりするのになぁ。

Solaris10の自動アップデートインターフェイス

Solaris10 の管理でOS関連ファイルのアップデートをしたい場合、smpatch コマンドというのがある。これはyumっぽい。
 


それとは別にGUIで「Sun Update Manager」というのがある。
これはMicrosoftUpdateっぽい。
[caption id="attachment_1024" align="alignnone" width="300" caption="画像：Solarisの「Sun Update Manager」"][/caption]
 

これは WSUS みたいに集中管理ができる模様、管理のしやすさ(他人への押し付けやすさとも言うな)というのもOSの売りになるなと思った。

アクセスログの保存期間は3ヶ月を目安にすればいいんじゃないか

ログの保存期間ってイマイチ迷う。
「アクセスログ 保存期間」「ログ 保存期間」で検索しても中々スパッとした答えが出てない、その代わり期間決定に色々参考になる情報があるという事はよく分かった。
 

それなら自分の中で定義しよう 3ヶ月(90日)でOK。(2008年10月現在の定義)
※最少は30日から、上は各自ストレージと相談してお好きなように
 

結論にいたるまでは、それなりの経過がある。以降は判断までの過程なので興味なければ不要。
 
 
 

プロバイダ責任制限法には制限が無いらしい

関連サイトなど。

• プロバイダ責任制限法関連情報Webサイト
  http://www.isplaw.jp/

 

• 社団法人テレコムサービス協会
  http://www.telesa.or.jp/

 

責任法の第4条では開示要求について記載されている。
「プロバイダは当局のログ提出要請に応じてネ。」という事のようだけど、じゃあどのくらい昔のログを出したらいいのかというと特に触れられていない。
 

外部サイト参考：「プロバイダー責任(逃れ)法可決 」 にあるように、そもそもログの取得が義務で無いため、ログが無ければ無いでよいという解釈になる。
なんでそんな事に？と思うかも知れないが、結局色々しがらみがあるんだろう。
 
 
 

不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）にも期間の指定は無いが…

関連サイトなど。

• 不正アクセス行為の禁止等に関する法律
  http://law.e-gov.go.jp/

 

• 警察庁 不正アクセス対策法案に関する意見書
  http://www.jisa.or.jp/opnion/990107-01.html
  

 

肝心の警察庁案が見当たらなかったが、当時についての記事1、当時についての記事2 から、警察丁案ではこちらの法律で 90日間又は30日間が義務付けられそうだった という事が分かった。
 

じゃあコレでいいじゃんという事で。
不正アクセスやら何やらで、当局に提出を求められる可能性があるログの類は、迷ったら3ヶ月(90日)を目安に運用すればOKだ。
(Apache・IIS等のWEBサーバアクセスログ、SMTP・POP3のメールログ、その他ログイン履歴などetc...)
 
 

そうそう、サーバ貸してる場合は、ユーザさんとはちゃんと取り決めを交わしてから消してね。
 
 

続きを書いたのでそっちもよろしく。
続・アクセスログの保存期間は3ヶ月を目安にすればいいんじゃないか

アプライアンスとCSRF(クロスサイトリクエストフォージェリ)

適当なアプライアンスのWEBインターフェイスを触っていると、WEB管理画面から色々できる事に関心する。システム関連の設定から再起動・シャットダウンまで可能で便利。
 
 

某アプライアンスを触っているとき、シャットダウンの許可確認ページが簡素な作りなことが気になった。
ソースを覗いてみると簡単なフォームだったので、試しに外部サイトにリンクを貼って、シャットダウンページのFormと同じリクエストがいくようにしてクリックしてみる。
 
結果、見事にシャットダウンした※。
あーこれCSRF(クロスサイトリクエストフォージェリ)とか言う奴だなと。リファラも何も見ちゃ居ない。
 

※CSRFなので既にそのブラウザで管理画面にログイン済み(Cookie有効状態)という条件です
 
 

しかしこれをとっ捕まえて「CSRFできるからさあ直せ！」と言うかとするとまた別の話。
不特定多数が利用することを前提としたWEBのASPサービスならまだしも、アプライアンスのUIにどこまで求めるかというのも難しい。
 
使ったらすぐログオフしたり、管理系は普段とは違うブラウザ使ったり、予防策を張れないでもない。
 
 

ただ、ログ収集系の機械とかだと、「HTMLのインジェクション発覚→管理者が画面開いただけでシステム操作が可能。」
というシナリオがあるんですよね。
 

最近はどんな入出力にも、常にHTMLタグとSQLを突っ込もうとする輩がいるので、開発する人は気をつけていきましょう。

hosts.allow、hosts.deny を使うサーバプログラムを見分ける

メモエントリ
 

hosts.allow、 hosts.denyはTCPラッパーの設定ファイル。サーバプログラムによってこれを使ったり使わなかったりする。
要はバイナリがTCPラッパーのライブラリにリンクしてれば使ってるだろうという見分け方をする。
 

netstat コマンドでサーバプログラムのバイナリ名を調べる

netstat はpオプションでポートをリッスンしているプログラムを表示してくれる。(Windowsのnetstatだったらbオプション)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
(中略)
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2327/vsftpd
(以下略)

丁度いいのがいた、この vsftpd はどうなのか調べる。
 
 

ldd コマンドでリンクしているライブラリを一覧表示

libwrapが居るかな？

# ldd `which vsftpd`
libssl.so.4 => /lib/libssl.so.4 (0x0088d000)
libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00b60000)
(以下略)

いた。
このvsftpd は hosts.allow、 hosts.deny を使うので、hosts.deny にALL 指定とかしてるサーバでは、どこかに allow を明示する必要があると。
バイナリにパスが通ってなかったら ldd に渡す引数でフルパス指定が必要。
 

ソースからコンパイルするならコンフィグヘルプを見ると、 libwrap 使うか選べるようになってる事がある。