Q&A
送信元のIPアドレス制限の設定は何を利用していますか。ファイアウォール、iptables、httpd の設定等の意味で。
linux上のJavaプログラムで、送信元IPを制限しているAPIに接続する(https)ようなことをしています。
API側ではこちらのグローバルIPを許可して穴あけした「らしい」状態で、この許可作業が正しく設定されているかどうかをこちらで確認するのには
# telnet XXX.XXX.XXX.XXX 443
で Connected to XXX.XXX.XXX.XXX. の応答があれば確認OKだとばかり思っていたのですが
適当な私用のさくらのVPSやAWSのインスタンスから上記コマンドで確認してみたら同じくConnected to~が出てしまったのであてがはずれ（別のテストサーバで実施した際は何も応答がなかったので、この確認方法で問題ないと思っていた）、適切な確認方法がわからない状態です。
サーバ間通信において、正常に穴あけされているかどうか確認する適切なコマンドを教えてください。
接続先はLBで、接続元のIPを制限しています（許可IP以外は通さない）という情報を頂いています。
改めてtelnet以外のコマンドで確認したところ、
- wget -S --spider https://XXX.XXX.XXX.XXX/
これは無関係のサーバからもConnecting to XXX.XXX.XXX.XXX... connected.と返答
- curl -k -l https://XXX.XXX.XXX.XXX/
無関係のサーバからは暫くした後curl: (56) SSL read: errno -5961と返答（許可IPからはhtml）
→先日はcurlでも応答があった旨書いており、logにも残っているのですが、現状はこうなりました
ので、curlでやるのが信憑性があるだろうか？ という風に短絡的には思っています。ただし、情報追加修正のご指摘でも頂いておりますが、疎通確認の方法はケースにより異なるというように認識しております。ですが、その「どのケースの際にはこの確認方法」という手法がわからないため、今後のためにご助言など頂けませんでしょうか。wget, curl, telnet以外の方法や、検索ワードなどでもありがたいのですが、よろしくお願い致します。
ファイアウォールになります。
# 私用のほうはiptablesでhttp/sは全開です
念のため確認ですが、API側で送信元IPを制限しているのは、どのレイヤでですか。TCP/IPでの接続・通信、TLS (SSL) でのクライアント認証等、httpdでのアクセス制御や認証、アプリケーションでの認証や認可、といったものが考えられます。このうちtelnetなどで疎通を確認できるのは、最初の場合だけです。
ikedasさん：TCP/IPでの接続・通信以外ではtelnetでの確認が適切でない旨ご教示ありがとうございます。どこで制限しているか、まだ確認できておりませんが、質問の意図としては、telnetが適切でない場合、他の疎通確認のための適切なコマンド（あるいは手法）が知りたいということになります。
言葉を返すようでなんですが、どのレイヤでどうやって制限しているかをまずはっきりさせていただかないと、適切な確認方法も回答しようがないです。
ikedasさん：仰る通りです。ご指摘の情報追加修正に関しましてはわかり次第行いますが、その部分は確認できるまでわからない点となりますので、想定していた回答の方向性としましては可能性の提示或いは「こういう場合はこう」とリストして頂く形でした。恐れ入ります。
回答5件
0
ポート番号443のhttpsの疎通確認ですね。
#nmap XXX.XXX.XXX.XXX
を実行してポートスキャンしてみて下さい。
疎通OKならば
443 https
が開いているメッセージが出るはずです。
ご参考まで
投稿2016/10/05 09:35
編集2016/10/05 09:36
総合スコア1628
nmapをインストールできない環境です。私用の方ではできますがnmapを利用することに抵抗があり･･････。今後の参考とさせていただきます。
・https://www.websec-room.com/2014/02/09/1812
> 但し、あくまで Nmap は自分の管理下にあるサーバーに対して行うようにしてください。
質問者さんのコメントの通り、nmapの使用には注意が必要です。
当然相手方の同意があれば使用可ですが、nmapの話を持ち出すならその辺の注意はしてあげるべきかと思います。
また、今回の目的に対してnmapは過剰ではないかとも思います。
"nmap -sT -p 443 (IPアドレス)"
または
"nmap -sS -p 443 (IPアドレス)"
と、ポートを限定した方がいいと思います。
皆様、色々とご指摘ありがとうございます。いずれにしろポートスキャンを
させて頂く許可を得てから実施しなければなりませんね。
又、nmapを一から入れるくらいならばポートスキャン用の簡易ツールを
インストールしてしまった方が楽かもしれません。
今回はLinuxの環境とのことですが、Windows環境からポートスキャンを
するのであれば
http://blog.layer8.sh/ja/2012/01/09/port-scanner/
が良いのではないかと思います。
ご参考まで
0
443/tcpの確認という観点では、方法自体は間違っていないと思います。
ただ、被接続側のフィルタリング設定が不適切で、本来遮断すべきIPからの接続を許可してしまっているのではないでしょうか。
被接続側のログは確認されましたでしょうか？
投稿2016/10/05 09:24
総合スコア1894
> 被接続側
は、こちら（送信元）から見たAPI側の方でしょうか。連絡して確認することはできると思うのですが、接続先は複数あり、そのどれもでそうなってしまったので、こちらの確認の仕方が悪いのかと思い、できることすべてしてから問い合わせるのが良いかと思っているしだいです。
用語についてはご認識の通りです。
分かりにくかったようで済みません。
kunaiさんへの回答も見ての判断ですが、やはり不必要なIPアドレスからの接続を許可しているとしか思えません。
トランスポート層までのtcp疎通確認ならtelnetで十分ではありますが。
API側で接続を制限するのはそれなりの理由があってのことだと思うので、意図せず不必要な疎通が許可されていると疑われる状況ならば遠慮せずに伝えるべきだと思います。
API側の接続ログとFWの設定を見れば一目瞭然だと思いますよ。
コメントありがとうございます。不勉強なため、指摘に際しては慎重になっています。特に、
> トランスポート層までのtcp疎通確認ならtelnetで十分
の部分でも引っかかりを感じています。
ご丁寧にありがとうございます。勉強になります。
今回私が指摘した内容であれば、(語弊がありますが)間違ってたら「ごめんなさい」で済むような気がしますがどうでしょうか。(相手との関係性次第ですけど)
「引っかかりを感じる」というのは具体的にどういう点でしょうか。
参考までにお聞かせいただけると嬉しいです。
質問追加部分ですが、curlの実行結果としてはトランスポート層までは接続できている、と読み取れます。
fymartymさんがこの作業で確認したいことは結局何なのでしょうか？
当初、「ファイアウォール」「telnet」という単語が出てきたのでトランスポート層レベルでの疎通確認を意図していると解釈していました。
最初の質問文の「サーバ間通信において、正常に穴あけされているかどうか」という表現もそうです。
> curlでやるのが信憑性があるだろうか？
との事ですが、ツール自体の動作は十分信用に値すると思います。
疎通できないものを「できている」と表示すること(バグ)はないと思います。
どちらかというとfymartymさんが、この確認作業のゴールを明確に認識できていないので、どのツールをどう使うのか適切に選択できていないということなのではないでしょうか。
また、API側のパケットフィルタリングがLBでなされているにせよ、FWでなされているにせよ、(fymartymさんにとって)想定外のIPアドレスから443/tcpが接続できているのは確かだと思います。
> この確認作業のゴールを明確に認識できていないので、どのツールをどう使うのか適切に選択できていない
ご指摘の通りです。疎通確認をするという命題に当たった際、どの方法でどのような結果が返れば正常であるかということがわからずに今回のような質問に至りました。
こちらの理解が足りないために何度も丁寧にご教示頂き申し訳ありません。ありがとうございます。
本来確認すべきことは、fymartymさんが作ったjavaプログラムでAPIサーバに接続し、アプリケーション的に意図した応答が得られること、だと思うのです。
確認の方法として、自分側の動作状況だけで結論を出すのではなくAPIサーバ側のログと突合するという事も必要だと思います。
もしアプリケーション動作が上手くいかないのであれば、切り分けの定石として低いレイヤいから切り分けていけばいいと思います。
まずはNW的に到達性があるか、ポートの応答はどうか、Webサーバの動作は、SSLは…と。
おそらくその過程で、fymartymさんが意図しないホストからも443/tcpに接続できてしまったので混乱したのではないでしょうか。
ただ今回のケースでは、443/tcpに接続できてよいのか悪いのかはAPI(NW)側の管理者の意図と実装の問題です。
fymartymさんとしてはAPI側の担当者に淡々と事実を伝えればよいだけではないかと思います。
あとはツールの出力をどう読み解くかですが、今回のケースは至極単純で「接続できた」と表示されているのなら接続できているのです。
> 作ったjavaプログラムでAPIサーバに接続
> 443/tcpに接続できてよいのか悪いのかはAPI(NW)側の管理者の意図と設計の問題
仰る通りです。特にAPIでは、どこからでも画面までのアクセスを受け付けるが許可IP以外のログイン情報はリジェクトする、というようなことをしているところもあると聞きます。そのためには何らかスクリプトなどで確認するしかないのだと理解しました。
この度は何度もありがとうございました。質問するのにもある程度の理解がないとうまく説明できないというのを痛感しています。その部分を察して頂くような負担をおかけし、大変申し訳ない思いです。
0
ベストアンサー
ロードバランサを介している旨の追加情報のご提供ありがとうございます。ほかのかたが指摘しておられることと重なりますが、アクセス制御より前にロードバランサがTCP/443の接続を受け付けてしまっている可能性もありますね。
ですので単に疎通だけでなく、通信内容をきちんと確認できる方法で確認したほうがいいと思います。たとえばopensslのs_client(1)を使った場合、アクセス制限がなにもなければ次のような結果が得られるはずです。
$ openssl s_client -connect 相手先ホスト名:443 CONNECTED(00000003) <= 接続成功 ここに、証明書チェーンの詳細が表示される ここに、TLS (SSL) ハンドシェークの詳細が表示される TLSが確立すれば以下の内容が表示される --- GET /APIのURI HTTP/1.1 <= APIへのリクエスト (GET等) を入力 Host: 相手先ホスト名 ここにAPIからの応答が表示される closed
アクセス制限が行われていれば、上のどこかでアクセスを拒否されると思われます。
ちなみに
本来、サービスが正常動作しているかどうかの判断基準やそれを確認するための手順はサービスを利用する側で検討するものではなく、サービスを設計・提供している側が明示すべきものとも考えられます。もしも差支えなければ、先方の担当者に確認手順の提示を求めてもよいのではないかと (第8層から上はこの場のスコープ外かな)。
投稿2016/10/07 03:00
総合スコア4335
opensslでの確認方法のご教示ありがとうございます。
また、ブロック内で例示頂いていることが理解の助けとなり大変ありがたいです。
> 判断基準やそれを確認するための手順はサービスを利用する側で検討するものではなく、サービスを設計・提供している側が明示すべきもの
こちらもありがとうございます。以降、特段の制約がない限りは適切な確認方法について問合せるようにしたいと思います。
改めて追加修正のやりとりを見てもかなり私が無茶を申し上げていましたが、丁寧に最後までご回答頂いてありがとうございました。
0
ヘルスチェック用のURLを叩くのが良いと思います。
アプリケーション側で/statusがaliveという文字を返すように設計し、次のコマンドで
HTTPレスポンスコードが200を返す事と文字列がaliveであることを確認します。
curl -i https://example.com/status
接続先にWEBサーバ等が居ない場合は、接続先サーバで簡易WEBサーバをシェルで起動します。
次の例はポート8000で簡易Webサーバを起動します。
ポート1024以下でLISTENするにはroot権限が必要です。
while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; echo 'alive'; } | nc -l 8000; done
投稿2016/10/05 09:28
総合スコア6621
0
wgetやcurlでHTTPプロトコルの通信を投げるのはダメなのでしょうか
投稿2016/10/05 09:14
総合スコア5405
wget -S --spider https://XXX.XXX.XXX.XXX/としてみると、私用サーバからもConnecting to XXX.XXX.XXX.XXX:443... connected.と返り、curl -k -I https://XXX.XXX.XXX.XXX/としてみると、私用サーバからも200が返るので、ほかに何か適切な確認方法がないかと思っています。
あなたの回答
tips
プレビュー
