ロリポップは 2001 年以来、約 15 年間ホスティング (レンタルサーバ) サービスを提供してきた。その間、ハードウェアやソフトウェアの進化に伴って要求されるサービス品質も高くなってきており、いかにサービス事業者の運用コストを減らしながらも、高品質なサービスを提供するかが重要である。そこで、私が京都…
はじめに サーバ管理をしている身としては、 セキュリティ は常に付きまとう悪魔みたいなもので、このセキュリティに関しては何をどこまで頑張ればいいのか不透明な部分が多い。 脆弱性に関しては、CVEなど、毎日情報は入ってくるが、それがどのサーバの何に関連したものなのかなんていちいち調べてられないし、どの脆弱性がすぐに対応しなければいけないもので、どの脆弱性があとあと対応すればいいものなのかなんてわからない。 実際のところ、大きな話題になった脆弱性くらいしか緊急で対応してないという人は多いのではないかと思う。 そんな中、満を持して登場したのが vuls !! 各サーバの脆弱性情報を取得して、個々のサーバそれぞれでどんな脆弱性があり、どのくらいやばい脆弱性なのかを検知できるようになった! 今回はこのvulsを紹介します。 Vulsとは 公式でロゴが発表されたので、差し替えました 公式ドキュメント:
(追記) このStarpitの課題点を改善したtaRgreyというものを提案しています。 こちらのほうがいろいろな点でよりベターなものになっていますので、こちらのエントリーをご覧いただいた後は、このエントリーもご確認下さい。 taRgrey - S25R + tarpitting + greylisting (tarpit + greylist policy server) モーグルとカバとパウダーの日記 - taRgrey - S25R + tarpitting + greylisting (修正 2009/05/19) 現時点でのスパムに対応するように遅延時間を85秒に変更しました。またS25RのパターンをIPv6での誤検出が無いように変更されたのを、今更ながら反映しました。 Starpitというスパム対策方法を提案します。*1 これはMTAで「ほぼ誤検出無く」93%程度のスパムを排除
A few years ago, the web at large was unencrypted. HTTPS was reserved for only the most critical sections of a web page. The consensus was only sensitive user data needed to be encrypted; public parts of a web page were okay to send in the clear. Well, things are different now. Today we know it’s not a good idea for any web traffic to be unencrypted, and anyone running a website, no matter the con
今までSSL(TLS)のciphersuite設定はmozilla wikiのSecurity/Server Side TLS]の記述を個人的に推奨してきましたが、Historyを追ってるとたまに迷走してるし、今の設定が本当に良いのか怪しくなってきたので、もう FIPS@STRENGTH:!aNULL:!eNULLでいいんじゃないかと思いました。 FIPS準拠、PCI準拠になるし。 https://matsuu.net/ は2014年10月現在このciphersuiteを実践中です*1。 反論お待ちしております。 追記:ciphersuite以外の設定は引き続きmozilla wikiのSecurity/Server Side TLS]を参照するか、Generate Mozilla Security Recommended Web Server Configuration Filesをオス
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
SMTP Server specific settings Topics covered in this section: Server-side certificate and private key configuration Server-side forward-secrecy configuration Server-side TLS activity logging Enabling TLS in the Postfix SMTP server Client certificate verification Supporting AUTH over TLS only Server-side TLS session cache Server access control Server-side cipher controls Miscellaneous server contro
サーバーの基本的なセキュリティ対策の1つとして重要なのが、ネットワーク内のどのマシンがどのポートでサービスを提供しているのかを把握することだ。このために有用なのが、ポートスキャナと呼ばれるツールだ。本記事ではポートスキャナとして有名な「Nmap」というソフトウェアを使用し、ポートスキャンを行う方法について解説する。 定番のポートスキャナ「Nmap」とは 対象として指定したホストに対してポート番号を変えながらIPパケットを送信し、その反応を調べることでどのポートが外部からアクセス可能なのかを調査する行為をポートスキャンと呼ぶ。Nmap(Network Mapperの略)は、オープンソース(GPLv2ライセンス)で開発・提供されているポートスキャンツール(ポートスキャナ)だ。NmapではOSが提供するソケット機能を利用するだけでなく、ポートスキャンに使用するパケットを独自に生成することで、高速
※2014/10/3 0:00時点で Shell Shock への修正パッチは4つ公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください ※2014/10/7 14:00時点で Shell Shock への修正パッチは6個公開されています 既に対応済みのシステムでもパッチの漏れがないか注意してください 先日 ShellShock についての記事を書きましたが、 その後もいろいろと進展があり更にいくつかの脆弱性が検出されました ※前回の記事はコチラ bash の脆弱性 "Shell Shock" のめっちゃ細かい話 (CVE-2014-6271) - もろず blog 現時点で ShellShock に関わる脆弱性はなんと6個も報告されています CVE-2014-6271 CVE-2014-6277 CVE-2014-6278 CVE-2014-7169 CVE-2
IPスプーフィング(アイピースプーフィング)とは、IP通信において、送信者のIPアドレスを詐称して別のIPアドレスに「なりすまし」(英:spoofing)を行う攻撃手法を指す。ハッキング、サイバーテロ(サイバー攻撃)の一つ。より原義に近い形としてIPアドレススプーフィングと呼ぶこともある。 IP通信において、不正アクセスを防止する観点からポリシーに基づくフィルタリングを行うケースは多く、「特定のIPアドレスからの接続のみ可能」といったアクセス制限が施されている場合がある。このようなアクセス制限が施されている状況下にあっても、送信元IPアドレスを詐称することができればアクセス制限を迂回できてしまうため、攻略対象システムへの不正アクセスを成功させる可能性が高まる。また、攻略対象システムに残されるログにも詐称されたIPアドレスが記録されるため、攻撃者が攻略対象システムの管理者による追跡を逃れられ
環境変数に仕込まれたコードを実行してしまうBASHの脆弱性が CGIスクリプトに影響を与えるか試してみたら結果は悲惨な感じに Tweet 2014年9月25日 嶋田大貴 この記事は2014年のものです 朝から Bash specially-crafted environment variables code injection attack なるもので騒ぎになっていたので、さっそく手元の Apacheで試してみました。 /hoge.cgiというURIで実行されるように、一行のメッセージを出力するだけの CGIスクリプトを設置します。いっけん、なんの入力もクライアント側から受け付けていないため危険のありようもなく見えます。 #!/bin/sh echo "Content-type: text/plain" echo echo "Hi! I'm an ordinary CGI script w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く