©National center of Incident readiness and Strategy for Cybersecurity.
©National center of Incident readiness and Strategy for Cybersecurity.
acctonで全てのコマンド履歴を残します。 コマンド履歴は各々のユーザーの history にも残りますが、それらはユーザー自身で変更や削除ができてしまいます。 よって、管理者権限のみアクセス可能な履歴を別途取得し、何かあったときに追跡しやすいようにします。 ただし、ログにはコマンドのみで、引数までは記録されないので、これだけでは、 誰がいつ何をしたか?の特定は不可能です。inotifyのログ等と合わせてみれば少しはマシになるかもしれません。
起動スクリプトを作成して対象ディレクトリ配下の変更をログに記録していくようにします。 これにより、重要なファイルがいつ変更されたかが分かるので、トラブル時には役にたつかもしれません。 ただし、誰がやったかまでは分からないので、sudo のログや accton のログ等と組み合わせて見る必要があります。 #!/bin/bash # inotifywait: Start/Stop inotifywait # # chkconfig: - 80 20 # description: inotifywait waits for changes to files using inotify. # # processname: inotifywait . /etc/rc.d/init.d/functions . /etc/sysconfig/network LOCK=/var/lock/subsys/i
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
SkipfishはSQLインジェクションをはじめWeb向けの脆弱性を発見するソフトウェア。 SkipfishはGoogle製のオープンソース・ソフトウェア。2011年になってセキュリティインシデント関係の話題が飛び交っている。特に大きいのはソニーだろう。あそこまでの規模は相当珍しいが、何も対岸の火事という訳ではない。 オプション セキュリティホールを狙うのは人間に限らない。日々クローラーがWebサイトにアクセスしてセキュリティホールを狙っているのだ。狙われる前にSkipfishを使って自主的にチェックしてみよう。 SkipfishはGoogleが開発したセキュリティチェックソフトウェアだ。ターミナルで動作するソフトウェアで、指定したURLに対してSQLインジェクションやXSSなどWebアプリケーションが狙われやすい脆弱性をついてくる。結果はHTMLベースのレポートとして出力される。 結果は
OWASP World Tour Tokyo 2017年10月04日09:43 yoshinari_fukumoto オフィシャルコメント by:福本 佳成 みなさん、こんにちは。Rakuten-CERTの福本です。 先日、東京工業大学 蔵前会館にてOWASP World Tour Tokyoが開催されました。このOWASPの本格的なトレーニングイベントはなんと無償で提供され、有志のボランティアによって運営されました。サテライト会場も含め総勢700名を超える参加者が集まり、これだけのイベントがスポンサー無しで実施できたということが、いまのOWASP Japanのセキュリティコミュニティの強さを示しているのかなと思います。今回のトレーニング内容についてですが、各所での様々なOWASPのプロジェクトの活用例が充実しており、会場からは、このケーススタディを参考にして自社で同じような取り組みをや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く