2016年11月30日水曜日

AWS VPCでのネットワークACLとセキュリティグループのハマリポイント | ライタス株式会社

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全体に言えることですが、設定上限になっているものが結構あります。
事前に把握しておくと良いかと思います。




2016年11月29日火曜日

AWS APIで通信がうまくいかない | ライタス株式会社

AWS APIを実行する時に、APIエンドポイントへのアクセスをする必要があります。

この時に、HTTP/HTTPSのポートを開けておけばいいのかと思ったのですが、うまくいきませんでした。

いろいろ調べたところ、NACLのインバウンドで 49152-65535 の範囲でポートを開けておく必要があると記載があったので、設定してみたところ、うまくいきました。

http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html

このポートのことをエフェラメルポートと言い、リクエストを効率良く処理するためのポートとして使われます。
AWS APIエンドポイントもこちらのポートを使うようですので、うまくいかないようであれば、ここも疑ってみる必要がありそうです。


2016年11月25日金曜日

IISが停止! iisresetをしても回復しない! | ライタス株式会社

 =環境=
 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自体の再起動しかない + 定期的に再起動することで予防」


ってことなので、皆様ご注意を・・・


2016年11月24日木曜日

SCOM監視エージェントが暴走中 | ライタス株式会社

本末転倒とはこのこと。

と言わんばかりの現象に遭遇しました。

今回の現象について、解説します。


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屋の宿命からの記事を加筆修正したものです。

2016年11月22日火曜日

IIS SMTPなんて嫌いだー! | ライタス株式会社

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を付け替えてくれているようです。


余計なことしやがって

親切なのはうれしいのですが、ちゃんと動いていないのが残念でなりません。

で、その対策を探しているのですが、なかなか見つかりません。
レジストリをいじってやれば、できるとかそういうのを期待したんですけど・・・

見つからないということは、世間にこんなことで、悩んでいる人はきっといないということで、
ちょっと安心(?)しました。


私はというと、他のMTAにSMTPすることで回避しました。
(最初からそうしろよっっていう話もありますが、こちらものっぴきらない事情がありまして・・・泣)


別件ですが、似たようなことでお怒りの方を発見・・・御参考までに
http://www.dreams.ne.jp/support/mail/messageid.html



ちなみに、調べて初めて知ったのですが、Windows 7には、IIS SMTPは付属していないみたいです。



本記事は、弊社代表のブログ記事なんでもIT屋の宿命からの記事を加筆修正したものです。

2016年11月8日火曜日

宅急便業者を装うウィルスメールが急増してます | ライタス株式会社

クロネコヤマト社から同社の名前を騙った不審なメールが発生しているとの注意喚起が発信されました。
実際に被害がでているようなので、皆様におかれましても注意いただければと思います。

「お届け予定eメール」を装った不審メールにご注意ください
http://www.kuronekoyamato.co.jp/info/info_160629.html


これまでも、銀行を騙る手口のメールがありましたが、新たに宅配業界にも進出したと見ることができるでしょう。
典型的なパターンが繰り返されるのは、有効な証とも取れ、今後も被害が広がっていくのではないかと憂慮しています。

ウィルスメールを見分ける方法については、いくつか方法がありますので、それを解説したいとおもいます。


攻撃側が狙っていること

攻撃する側は、パソコンの情報を抜き取ることが目標であることが多いです。
情報を抜き取る方法は幾つかありますが、今回は「相手にウィルスを実行させること」が目標になっているタイプの攻撃方法です

ウィルスを実行すると何が起きる?

ウィルスを実行すると、まずはウィルスが削除されないような場所に隠れる事が多いです。
一旦隠れられると、見つけるのは難しくなります。見つけるには、ウィルス対策ソフトのフルスキャンが有効です。できるだけ定期的に実行するようにしましょう。

隠れたら、次は実行を止められたときに、再度自分自身を実行するための命令をパソコン内部に仕掛けます。こうすることで、ウィルスの行動が止められたり、パソコンが再起動されたりしたときにも、継続して活動しやすくなります。

次に、ウィルスは、パソコン内部にあるデータをインターネットの先にいるウィルスを作った人へ送り始めます。送り終わったら、その痕跡を消すケースも見受けられます。

「ウィルスを開かない」が身を守る最終ライン

アンチウィルスソフトでも、ある程度はパソコンを守ってくれるのですが、100%ではありません。
新種のウィルスなどには対抗できない例が増えてきています。もちろん、新しいアンチウィルスソフトには、最新鋭の対抗策を盛り込んで販売していますが、古いアンチウィルスソフトを利用していたり、有効期限切れのものを利用している場合は、守られることなく感染してしまうことがあります。

ウィルスに感染しないコツとしては、「ウィルスを実行しないこと」が必要です。
ウィルスも実行されなければタダのファイルと同じです。削除もできます。
まずは、ウィルスが添付されたメールをどのように対処すればいいのか、を考えることが大事です。

1. 身に覚えのないメールは開かない

当たり前ではありますが、あの手この手でメールを開かせようとしているので、難しいこともあります。

2. 身に覚えはあるが、明らかにおかしいメールは疑う

今回のケースはこのパターンで対処できるかもしれません。
荷物を受け取る予定がないのにもかかわらず、「荷物が届きました」というメールが届くのが今回のケースですが、荷物受け取りサービスに登録していないメールにこのようなメールが届く場合は、明らかに変ですよね。そういったちょっとした変な兆候を気づく癖をつけておくと、回避できることがあります。

3. 身に覚えがあるメールなのに内容が変

最近は、外国人による犯行が増えており、メールの文面がちょっと日本語的におかしい場合というケースが多いです。
そういったケースは、本文を読むことで回避できるケースがあります。

4. どうしても開かなければいけない場合

添付ファイルの中身をどうしても確認しなければならない場合は、拡張子に注目してください。
実行ファイルの見分け方については、別の投稿にて解説します。


まとめ

メールによる攻撃も増えていますが、基本的には、「実行しない」が最善策であることをお伝えしました。そうは言っても、添付ファイルが安全であるかどうかについては、一定の判断が必要で難しいのですが、ある程度はアンチウィルスソフトが防衛してくれる面もあると説明させていただきました。