ASP.NET 練習帳

国内の ASP.NET サーバーに関して

CCNA/CCNP の問題集 http://www.pearsonitcertification.com/store/browse/practice-tests のエンジン新バージョンがリリースされたから明示的にインストールしろって案内メールが来た。

●旧バージョンにてエンジン アップデートのボタンを押してもダメだから、明示的に新バージョンをインストールしなさい
●旧バージョンをアンインストールする必要はない

で、新バージョンをインストールしたが、起動時にスプラッシュ ウィンドウが一瞬表示されるだけで、その後が無い。

サポートに問い合わせメール書いたら、その返事が笑う。「スプラッシュ ウィンドウをキャプチャして送れ」だってさ。

仕方がないので、解決策を探す。

How to: Configure Network Tracing に記載の呪文 XML を app.config に追記して https 通信内容を調べたら、アカウント名 (私のメールアドレス) が古いものを使っていることが分かった。

なぜ、古いアカウント名で認証を試みているのだろう。そもそも新バージョンにてアカウント名を入力した記憶が無いし。けどまあ、なんとなく解決方法が見えてきた。

解決方法



問題なく動作する旧バージョン (Pearson IT Certification Practice Test) をアンインストールし、スプラッシュ スクリーンを表示して直ちに黙って終了する新バージョン (Pearson Test Prep) もアンインストールする。

C:\users\$myname\AppData\Roaming\Pearson IT Certification Practice Test\ ディレクトリと C:\users\$myname\AppData\Roaming\Pearson Test Prep\ ディレクトリを消す。

新バージョン (Pearson Test Prep) をインストールする。

新バージョンを起動すると認証情報を問うてきた。

これにて解決。.NET Framework の知識が役に立ちました。









https://www.virtualbox.org/wiki/Network_tips


  • NIC にて tcp オフロードが行われていても、オフロードされていない状態でのキャプチャが可能。
  • キャプチャの on/off 切り替えは仮想マシン停止時に行う必要がある。
  • 少量をキャプチャした程度ではキャプチャ ファイルのサイズは増加しないので、見ていると心配になるが焦らずに我慢。
  • タイムスタンプは 1970/1/1
  • キャプチャ開始時、言い換えると仮想マシンの電源オン時に既存のキャプチャファイルの内容は空っぽにクリアされるので必要なデータは退避させておくこと。
  • 最も若い NIC をキャプチャする際は番号 1 を指定。

Both Juniper SRX and Check Point analyze the inner header of the ICMP packet before making a forwarding decision, while Palo Alto does not. As a result, both the Check Point and the SRX Firewalls drop the BlackNurse packets, while Palo Alto is forced to consume resources forwarding the traffic to the internal server.

AFFECTED

FGT (で、おそらく緩和策は無い)

NOT AFFECTED

Linux iptables

追記

FGT に関して。公式のアドバイザリが存在するが、役に立たないと思う。カスタムで IPS ルールを定義している個人ブログを見つけた。それなら緩和策として役に立つかもしれない。試してはいない。

症状


AWS EC2 の FortiGate 5.2.9 にて。FGT から Amazon Linux への ping は成功。Amazon Linux から FGT への ping は失敗。

解決策


System ⇒ Admin ⇒ Administrators の Restrict this Administrator Login from Trusted Hosts Only が有効の場合、ping も管理用アクセスとみなされるらしい。Trusted Hosts に Amazon Linux の IP アドレスを追加して Amazon Linux から FGT への ping を許可した。

...


理解しがたいことに、FGT への ping は WebUI への https アクセス、ssh アクセスと同列に扱われているようだ。


ルーター間 (vyos 二台) で ipsec vpn している際、末端の linux ホストが mtu をキャッシュしていることに気が付いた。

[user2@east2 ~]$ ip route get 192.168.15.105
192.168.15.105 via 192.168.16.104 dev enp0s3  src 192.168.16.106
    cache  expires 298sec mtu 1438●キャッシュの寿命残は 298 秒で mtu は (1500 でなく) 1438

で、このキャッシュを消すには echo 0 > /proc/sys/net/ipv4/route/flush もしくは ip route flush cache とする。

キャプチャしてわかったのだが、vyos が ICMP (type=3, code=4) で MTU of next hop = 1438 を linux ホストに伝えていたのだ。

このキャッシュした 1438 を有効活用している例を探したが見つからない。唯一 ping は有効?に活用していた。

[root@east2 ~]# ping -c 1 -s 1411 -M do 192.168.15.105●MTU 1438 に収まらない ping を実行一回目
PING 192.168.15.105 (192.168.15.105) 1411(1439) bytes of data.
From 192.168.16.104 icmp_seq=1 Frag needed and DF set (mtu = 1438)

--- 192.168.15.105 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
[root@east2 ~]# ping -c 1 -s 1411 -M do 192.168.15.105●再度、MTU 1438 に収まらない ping を実行
PING 192.168.15.105 (192.168.15.105) 1411(1439) bytes of data.
ping: local error: Message too long, mtu=1438●奇妙なメッセージ。この時、ping 送信は行われず、送信が無いので応答も無い。

--- 192.168.15.105 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

有効活用しているケースを知りたい。

PRIVATE から PUBLIC へ向けての通信など、いくつかが全許可になっているけど、練習なのでまあいいってことで。

参考にした資料は http://brocade.com/5400documentation の Firewall

vyos_zone_based_firewall
# SNAT
set nat source rule 300 outbound-interface eth0
set nat source rule 300 source address 192.168.103.0/24
set nat source rule 300 translation address 192.168.101.252

# SNAT
set nat source rule 400 outbound-interface eth0
set nat source rule 400 source address 192.168.102.0/24
set nat source rule 400 translation address 192.168.101.252

# DNAT
set nat destination rule 100 destination address 192.168.101.252
set nat destination rule 100 destination port smtp,http
set nat destination rule 100 translation address 192.168.103.250
set nat destination rule 100 protocol tcp
set nat destination rule 100 inbound-interface eth0

# ゾーン (DMZ, PRIVATE, PUBLIC) を作る
set zone-policy zone DMZ interface eth2
set zone-policy zone PRIVATE interface eth1
set zone-policy zone PUBLIC interface eth0

# DMZ から PRIVATE へ
# established と related を認める
set firewall name DMZ_TO_PRIVATE rule 10 action accept
set firewall name DMZ_TO_PRIVATE rule 10 state established enable
set firewall name DMZ_TO_PRIVATE rule 10 state related enable
set firewall name DMZ_TO_PRIVATE rule 10 protocol all
set zone-policy zone PRIVATE from DMZ firewall name DMZ_TO_PRIVATE

# PUBLIC から PRIVATE へ
# established と related を認める
set firewall name PUBLIC_TO_PRIVATE rule 10 action accept
set firewall name PUBLIC_TO_PRIVATE rule 10 state established enable
set firewall name PUBLIC_TO_PRIVATE rule 10 state related enable
set firewall name PUBLIC_TO_PRIVATE rule 10 protocol all
set zone-policy zone PRIVATE from PUBLIC firewall name PUBLIC_TO_PRIVATE

# PRIVATE から DMZ へ
# 全てを認める
set firewall name PRIVATE_TO_DMZ rule 10 action accept
set zone-policy zone DMZ from PRIVATE firewall name PRIVATE_TO_DMZ

# PUBLIC から DMZ へ
# established と related を認める
# smtp と http を認める
set firewall name PUBLIC_TO_DMZ rule 10 action accept
set firewall name PUBLIC_TO_DMZ rule 10 state established enable
set firewall name PUBLIC_TO_DMZ rule 10 state related enable
set firewall name PUBLIC_TO_DMZ rule 10 protocol all
set firewall name PUBLIC_TO_DMZ rule 20 action accept
set firewall name PUBLIC_TO_DMZ rule 20 destination port smtp,http
set firewall name PUBLIC_TO_DMZ rule 20 protocol tcp
set zone-policy zone DMZ from PUBLIC firewall name PUBLIC_TO_DMZ

# DMZ から PUBLIC へ
# 全てを認める
set firewall name DMZ_TO_PUBLIC rule 10 action accept
set zone-policy zone PUBLIC from DMZ firewall name DMZ_TO_PUBLIC

# PRIVATE から PUBLIC へ
# 全てを認める
set firewall name PRIVATE_TO_PUBLIC rule 10 action accept
set zone-policy zone PUBLIC from PRIVATE firewall name PRIVATE_TO_PUBLIC

tldr

iptables で --state なフィルタを書く際は RELATED を忘れずに許可すべし。

case 1

手元 PC (host1) にて telnet で smtp する。
[root@host1 ~]# telnet 192.168.11.201 25
Trying 192.168.11.201...
telnet: connect to address 192.168.11.201: Connection refused
即座に応答が帰ってくる。 この時、接続先ホスト 192.168.11.201 では 25 番を listen しておらず、加えて firewalld は停止状態である。 手元 PC と接続先ホストの間にはファイアウォールがあり、ESTABLISHED と RELATED を ACCEPT する設定にしてある。
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ファイアウォールで採取したキャプチャには [R.] が含まれている。
12:40:32.809470 IP 192.168.11.202.44840 > 192.168.11.201.smtp: Flags [S], seq 1346627739, win 29200, options [mss 1460,sackOK,TS val 6168822 ecr 0,nop,wscale 7], length 0
12:40:32.809867 IP 192.168.11.201.smtp > 192.168.11.202.44840: Flags [R.], seq 0, ack 1346627740, win 0, length 0

case 2

case 1 の続き。 接続先ホストにて firewalld を稼働させる。
[root@host2 ~]# systemctl start firewalld.service
手元 PC (host1) にて telnet で smtp する。
[root@host1 ~]# telnet 192.168.11.201 25
Trying 192.168.11.201...
telnet: connect to address 192.168.11.201: No route to host
即座に応答が帰ってくる。 ファイアウォールで採取したキャプチャには admin prohibited (type=3, code=10) が含まれている。
12:56:13.898687 IP 192.168.11.202.44844 > 192.168.11.201.smtp: Flags [S], seq 1872229748, win 29200, options [mss 1460,sackOK,TS val 7109911 ecr 0,nop,wscale 7], length 0
12:56:13.899173 IP 192.168.11.201 > 192.168.11.202: ICMP host 192.168.11.201 unreachable - admin prohibited, length 68

case 3

case 2 の続き。 ファイアウォールの設定を以下のようにする。 (ESTABLISHED,RELATED を ESTABLISHED に変更)
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
手元 PC (host1) にて telnet で smtp すると、長時間 (だいたい二分) 待たされた後でタイムアウトと表示される。 RELATED が許可されていない場合、admin prohibited が送信元に届かないのだ!
[root@host1 ~]# telnet 192.168.11.201 25
Trying 192.168.11.201...
telnet: connect to address 192.168.11.201: Connection timed out

↑このページのトップヘ