ライタス株式会社公式ブログ

AWSでVPCを扱うとき、セキュリティポリシーとして、通信制御を行うと思います。 通信制御をするときは、ネットワークACLとセキュリティグループを活用して設定しますが、ここで幾つかハマりポイントがあります。 1. ステートレスとステートフル ネットワークACL ステートレスインスペクション セキュリティグループ ステートフルインスペクション ステートレスとは、指定したポートのみを通すもので、他のポートは通信を拒否します。 ステートフルは、指定したポートを通しますが、その通信の戻り通信も許可します。 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Security.html 2. 設定単位 ネットワークACL サブネット単位 セキュリティグループ ENIおよびグループ単位 ネットワークACLは、VPC内に定義されたサブネット単位で作成できます。 セキュリティグループは、サーバーごとに設定するイメージですが、実態としては、ネットワークカードに対して設定するイメージと捉えています。 3. ネットワークACLとセキュリティグループを両方使う ネットワークACLとセキュリティグループを両方使う場合、両方許可されないと通信ができなくなります。 ネットワークACL セキュリティグループ 結果 許可 許可 許可 許可 拒否 拒否 拒否 許可 拒否 拒否 拒否 拒否 4. ハマリポイント 上記ルールに従って通信制御を行うことができますが、ネットワークACLがステートレスのため、ちゃんと通信ポートが開いてると思っているのに、開いていなかったということがよくあります。 また、戻りの通信ポートがダイレクトポートを使っている場合、ネットワークACLで拒否されてしまって、通信できなかったということが 検証方法としては、ネットワークACLかセキュリティグループを一瞬フルオープンにして通信できるかどうか確認する方法をよく使います。 他にも、AWS全体に言えることですが、設定上限になっているものが結構あります。 事前に把握しておくと良いかと思います。

AWS APIを実行する時に、APIエンドポイントへのアクセスをする必要があります。 この時に、HTTP/HTTPSのポートを開けておけばいいのかと思ったのですが、うまくいきませんでした。 いろいろ調べたところ、NACLのインバウンドで 49152-65535 の範囲でポートを開けておく必要があると記載があったので、設定してみたところ、うまくいきました。 http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html このポートのことをエフェラメルポートと言い、リクエストを効率良く処理するためのポートとして使われます。 AWS APIエンドポイントもこちらのポートを使うようですので、うまくいかないようであれば、ここも疑ってみる必要がありそうです。

 =環境=  Windows Server 2003 R2 SP2  IIS 6.0 + .NET 2.0  =現象=  HTTPアクセスが全滅  iisresetを実行しても回復せず iisresetをしても回復しないあたり、かなりの重症ですね。 ログをあさっていたところ、以下の様なログを発見 Logfiles/HTTPERR/某ログ 1_Connection_Refused という記載がありました。 なんのことかわかりませんでしたが、どうもカーネル周辺のメモリアロケーションに失敗している模様。 http://www.osas.co.jp/magmag/2011/20110703.html http://blogs.msdn.com/b/amol/archive/2012/02/29/troubleshooting-quot-connections-refused-quot-errors-seen-httperr-logs.aspx 対処法は、「OS自体の再起動しかない + 定期的に再起動することで予防」 ってことなので、皆様ご注意を・・・

本末転倒とはこのこと。 と言わんばかりの現象に遭遇しました。 今回の現象について、解説します。 Active Directory(WS2008)に、リモートデスクトップ接続しようとしたところ、 以下の様な画面になりました。 ターミナル接続が現在、接続、切断、リセット、または削除の操作の処理でビジー状態であるため、要求された操作を完了できません。 なんでかなーと思いつつ、別ルートのコンソールツールで実機に直接ログインを試みたところ、 ようこそ画面で止まってしまい、応答がありません。 2chのスレで「ようこそ画面のまま、1時間ほど放置したらログインできた」との 報告があったので、そのとおりにしてみると、15分後あたりでログインできました。 とりあえず、タスクマネージャーを見たところ、CPU / メモリー共に上限まで振り切っていました。 振り切ってる原因のプロセスを確認したところ、MonitoringHost.exeが5個ほど立ち上がっていたので、とりあえず、バッサリと停止しました。 この時点で、リモートデスクトップが復旧したので、ほっと一息です。 さて、今回の原因の、MonitoringHost.exeですが、何者かというと、 SCOMのエージェントプログラムでした。 監視エージェントが暴走するなよ（苦笑 詳細については、以下のとおりです。 http://support.microsoft.com/kb/974051/ja どうも、XP/Vista/WS2008で発症するみたいです。 MSXML6.0のコンポーネントがよろしくないみたいですね。 WindowsUpdateすれば治るようですが・・・確認していないので、よくわかりません(^^; 結局、当該サーバーについては、エージェントレスで監視することにしました。 リモートデスクトップが繋がらないことがあれば、大体CPUかメモリーが いっぱいいっぱいになっていることが考えられるので、 同様の状態になったら、疑ってみてはいかがでしょうか。 本記事は、弊社代表のブログ記事 なんでもIT屋の宿命 からの記事を加筆修正したものです。

IISのSMTPで困ったことになっているので、解説がてら整理。 IISのSMTPは、Windowsを利用していれば、簡単に利用できるSMTPサーバーで、 結構利用されているケースが多いように感じています。 テストケースに使うにはもってこいですし。（なんで本番につかうのかなー） というか、そもそもIIS SMTPなんか使うなというお叱りはごもっともだと思います。 のっぴきらない理由はお察しください｡･ﾟ･(ﾉ∀`)･ﾟ･｡ さて、今回の現象ですが、RFCに関わる部分なので、多少前提知識が必要です。 ここをお読みの方は、きっとハイエンドな方ばかりだと勝手に信じて話をすっ飛ばすと・・・ メールヘッダーにMessage-IDという項目があります。 Message-IDに関しては、ここのサイトが詳しい解説をしています。 http://www.emaillab.org/essay/message-id.html この値は、インターネット的にユニークな値であることを保証される必要があるのですが、 IIS SMTPを使ってメールを出すと、条件によっては、重複したものが生成されるケースが あるようです。 その条件は、よくわかっていないのですが、現象が起きている環境をちょこっとだけ書くと、 Windows Server 2003 R2 + IIS + ASP.NET 2.0で、メールをIIS SMTPに対して短い間隔で出す と、現象が発生するようです。 IISのMessage-ID の形式は、 [サーバー名][よくわからない文字列9文字][8桁の数字(連番?)]@[DNSサフィックス] のようですね。 重複するのは、[8桁の数字(連番?)]の部分が原因みたいで、 予想では、マルチスレッドで動作している場合に、同じIDが出ることがあるとか、 そんなんじゃないかなとおもいます。 ASP側で、Message-IDを生成して送るように設定したはずなのですが、 どうも、IIS側でMessage-IDを付け替えてくれているようです。 余計なことしやがって 親切なのはうれしいのですが、ちゃんと動いていないのが残念でなりません。 で、その対策を探しているのですが、なかなか見つかりません。 レジストリをい

クロネコヤマト社から同社の名前を騙った不審なメールが発生しているとの注意喚起が発信されました。 実際に被害がでているようなので、皆様におかれましても注意いただければと思います。 「お届け予定eメール」を装った不審メールにご注意ください http://www.kuronekoyamato.co.jp/info/info_160629.html これまでも、銀行を騙る手口のメールがありましたが、新たに宅配業界にも進出したと見ることができるでしょう。 典型的なパターンが繰り返されるのは、有効な証とも取れ、今後も被害が広がっていくのではないかと憂慮しています。 ウィルスメールを見分ける方法については、いくつか方法がありますので、それを解説したいとおもいます。 攻撃側が狙っていること 攻撃する側は、パソコンの情報を抜き取ることが目標であることが多いです。 情報を抜き取る方法は幾つかありますが、今回は「相手にウィルスを実行させること」が目標になっているタイプの攻撃方法です ウィルスを実行すると何が起きる？ ウィルスを実行すると、まずはウィルスが削除されないような場所に隠れる事が多いです。 一旦隠れられると、見つけるのは難しくなります。見つけるには、ウィルス対策ソフトのフルスキャンが有効です。できるだけ定期的に実行するようにしましょう。 隠れたら、次は実行を止められたときに、再度自分自身を実行するための命令をパソコン内部に仕掛けます。こうすることで、ウィルスの行動が止められたり、パソコンが再起動されたりしたときにも、継続して活動しやすくなります。 次に、ウィルスは、パソコン内部にあるデータをインターネットの先にいるウィルスを作った人へ送り始めます。送り終わったら、その痕跡を消すケースも見受けられます。 「ウィルスを開かない」が身を守る最終ライン アンチウィルスソフトでも、ある程度はパソコンを守ってくれるのですが、100%ではありません。 新種のウィルスなどには対抗できない例が増えてきています。もちろん、新しいアンチウィルスソフトには、最新鋭の対抗策を盛り込んで販売していますが、古いアンチウィルスソフトを利用していたり、有効期限切れのものを利用している場合は、守られることなく感染してしまうことがあります。 ウィルスに感