2007/01/15
ネットワーク構成
PLANEX BRL-04FMX を使って宅内ネットワークを構築してからずいぶん経ったが、サーバーを公開してからファイアウォールを中心に見直している。
まず、物理ネットワークは以下のように変わっていない。部屋Bにサーバーとなる Dell PowerEdge SC430 があり、部屋Aと部屋Cにクライアントがある。それぞれは1000BASE-TスイッチングHUB「corega CG-SW05GTPLB」を通って部屋Xの PLANEX BRL-04FMX に集約され、そこからマンション共有のルーターを経由してインターネットにつながっている。
論理ネットワークは以下のようになっている。まず、PowerEdge SC430 は 宅内専用サーバーとしてoscar.rewse.jpとなり、その上に VMware Server を使って公開用のzulu.rewse.jpを構築している。クライアントは複数台があるが、ここでは一台として省略している。
BRL-04FMXはLANネットワークを二つ構成できるので、宅内専用ネットワーク192.168.0.0/24と公開経路ネットワーク192.168.1.0/24を構成した。これはかなり便利な機能で、BRL-04FMXはLAN側に192.168.0.1と192.168.1.1を持ち、それぞれにフィルタリングの設定が行える。そのため、INでNAPTされておらず（NAPTをクラックしないとたどり着けない）クライアントしか使わない192.168.0.1はゆるめのフィリタリングにしており、NAPTされていて公開サーバーの使う192.168.1.1はきつめのフィルタリングを設定してある。
また、zulu.rewse.jpはIPエイリアスを使って、eth0に192.168.1.104と192.168.0.104の二つのIPアドレスを持っており、信頼できる192.168.0.0/24ネットワークからはファイアウォールを経由せずにアクセスすることができる。192.168.0.0/24と192.168.1.0/24は相互接続することも可能だが、今回はなにも通さないフィルタを設置し、192.168.0.0/24と192.168.1.0/24は完全に分離されたネットワークにしてある。
まずは192.168.0.1直前にあるフィルタリングの設定を公開しよう。まずは192.168.0.1へのINだ。
| ISP→192.168.0.1 | |||||||
|---|---|---|---|---|---|---|---|
| ID | 動作 | プロトコル | tcpフラグ | 送信元アドレス | 送信元ポート | 送信先アドレス | 送信先ポート |
| 1 | discard(log) | * | 127.0.0.1 | * | * | * | |
| 2 | discard | * | 192.168.0.0/16 | * | * | * | 3 | discard(log) | * | 172.16.0.0/12 | * | * | * |
| 4 | discard(log) | * | 10.0.0.0/8 | * | * | * | |
| 10 | pass | udp&tcp | * | 53 | * | * | |
| 11 | pass | udp | * | 123 | * | * | |
| 12 | pass | udp | * | 500 | * | * | |
| 13 | pass | udp | * | 4500 | * | * | |
| 14 | pass | udp | * | 5060-16403 | * | 5060 | |
| 15 | pass | udp&tcp | * | 5060-16403 | * | 5190 | |
| 16 | pass | udp | * | 5060-16403 | * | 5678 | |
| 17 | pass | udp | * | 5060-16403 | * | 16384-16403 | |
| 18 | pass | udp | * | * | * | 6970-6999 | |
| 60 | pass | icmp | * | * | * | * | |
| 61 | discard(log) | udp | * | * | * | * | |
| 62 | discard(log) | tcp | [e]syn. | * | * | * | * |
| 64 | pass | tcp | * | * | * | * | |
ISP側からループバック・アドレスやプライベートIPアドレスが来るわけないので、万が一来た場合は偽装パケットと見なし、破棄（ログ）するのがID#1から#4までだ。
ID#10でDNS、ID#11でNTPを通過させる。ID#12と#13は会社の用意しているVPNに接続するときに必要で、ID#14から#17までは iChat AV（AIM）関連だ。詳しくは「Apple: Article#93208 ファイアウォールや NAT ルータとともに iChat AV を使用する」を参考にしてしてほしい。ID#18はQuickTimeや Windows Media Player、RealPlayerでのストリーミング映像受信用に開けてある。
ID#60でpingを通過。ID#61で原則UDPは破棄（ログ）。ID#62でTCPフラグがsynだけのパケット、つまり接続要求は原則破棄（ログ）し、ID#64でsynだけ以外のTCPは原則通過としている。
次は192.168.0.1からのOUTだ。
| 192.168.0.1→ISP | |||||||
|---|---|---|---|---|---|---|---|
| ID | 動作 | プロトコル | tcpフラグ | 送信元アドレス | 送信元ポート | 送信先アドレス | 送信先ポート |
| 1 | discard(log) | * | * | * | 127.0.0.1 | * | |
| 2 | discard | * | * | * | 192.168.0.0/16 | * | |
| 3 | discard(log) | * | * | * | 172.16.0.0/12 | * | |
| 4 | discard(log) | * | * | * | 10.0.0.0/8 | * | |
| 10 | discard(log) | udp&tcp | * | * | * | 135 | |
| 11 | discard(log) | udp&tcp | * | * | * | 137-139 | |
| 12 | discard(log) | udp&tcp | * | * | * | 445 | |
| 13 | discard(log) | tcp | * | * | * | 548 | |
| 50 | discard(log) | tcp | * | * | * | 1243 | |
| 51 | discard(log) | tcp | * | * | * | 12345 | |
| 52 | discard(log) | tcp | * | * | * | 27374 | |
| 53 | discard(log) | tcp | * | * | * | 31785 | |
| 54 | discard(log) | tcp | * | * | * | 31789 | |
| 55 | discard(log) | tcp | * | * | * | 31791 | |
| 64 | pass | * | * | * | * | * | |
ID#1から#4まではIN同様、偽装パケット対策だ。また、ID#2はLAN内で完結するべきパケットが外に漏れることを防ぐことにもなる。
ID#10から#12まではWindowsファイル共有がルーターの外側まで探しに行っちゃうの対策。同様に、ID#13でMacファイル共有（AFP over TCP/IP）で使われるTCP/548をルーターで破棄（ログ）している。
ID#50から#55までは、万が一ウイルスに感染したときにバックドアを開かせたりウイルスの二次配布を防ぐために事前に破棄（ログ）してある。
そしてすべてのパケットはID#64で原則通過している。
公開サーバーの経路としてしか使われないため、きつめに設定してある192.168.1.1直前のフィリタリングを見てみよう。まずは192.168.1.1へのINだ。
| ISP→192.168.1.1 | |||||||
|---|---|---|---|---|---|---|---|
| ID | 動作 | プロトコル | tcpフラグ | 送信元アドレス | 送信元ポート | 送信先アドレス | 送信先ポート |
| 1 | discard(log) | * | 127.0.0.1 | * | * | * | |
| 2 | discard(log) | * | 192.168.0.0/16 | * | * | * | |
| 3 | discard(log) | * | 172.16.0.0/12 | * | * | * | |
| 4 | discard(log) | * | 10.0.0.0/8 | * | * | * | |
| 5 | discard | * | 192.168.1.0/24 | * | * | * | |
| 10 | pass | tcp | * | 21 | * | * | |
| 11 | pass | tcp | * | 25 | * | * | |
| 12 | pass | udp&tcp | * | 53 | * | * | |
| 13 | pass | tcp | * | 80 | * | * | |
| 14 | pass | tcp | * | 143 | * | * | |
| 15 | pass | tcp | * | 443 | * | * | |
| 30 | pass | tcp | * | * | * | 22 | |
| 31 | pass | tcp | * | * | * | 80 | |
| 32 | pass | tcp | * | * | * | 443 | |
| 60 | pass | icmp | * | * | * | * | |
| 64 | discard(log) | * | * | * | * | * | |
ID#1から#4までは192.168.0.1同様、偽装パケット対策で、ID#5はLAN内で完結するべきパケットが外に漏れることを防いでいる。
ID#10から#16まではクライアントとして使うポートだ。それぞれ順に FTP / SMTP / DNS / HTTP / IMAP / HTTPS となる。
ID#30から#32まではサーバーとして提供しているポートだ。それぞれ順に SSH / HTTP / HTTPS となる。
ID#60でICMPは通し、ID#64でUDPとTCPを原則破棄（ログ）している。192.168.0.1はよく分からないのは通していたが、192.168.1.1はよく分からないのは通さないというポリシーの差がある。
続いて192.168.1.1からのOUTだ。
| 192.168.1.1→ISP | |||||||
|---|---|---|---|---|---|---|---|
| ID | 動作 | プロトコル | tcpフラグ | 送信元アドレス | 送信元ポート | 送信先アドレス | 送信先ポート |
| 1 | discard(log) | * | * | * | 127.0.0.1 | * | |
| 2 | discard(log) | * | * | * | 192.168.0.0/16 | * | |
| 3 | discard(log) | * | * | * | 172.16.0.0/12 | * | |
| 4 | discard(log) | * | * | * | 10.0.0.0/8 | * | |
| 5 | discard | * | * | * | 192.168.1.0/24 | * | |
| 10 | pass | tcp | * | * | * | 21 | |
| 11 | pass | tcp | * | * | * | 25 | |
| 12 | pass | udp&tcp | * | * | * | 53 | |
| 13 | pass | tcp | * | * | * | 80 | |
| 14 | pass | tcp | * | * | * | 143 | |
| 15 | pass | tcp | * | * | * | 443 | |
| 30 | pass | tcp | * | 22 | * | * | |
| 31 | pass | tcp | * | 80 | * | * | |
| 32 | pass | tcp | * | 443 | * | * | |
| 60 | pass | icmp | * | * | * | * | |
| 64 | discard(log) | * | * | * | * | * | |
OUTはINのちょうど鏡のようにポートが開いており、要求と応答の双方が通れるようにだけしてある。
これにNAPTを組み合わせることで外部からzulu.rewse.jpにたどり着くことができる。NAPTも見てみよう。
| NAPT | |||||||
|---|---|---|---|---|---|---|---|
| ID | プロトコル | リモートIPアドレス | リモートポート | 外部IPアドレス | 外部ポート | 内部IPアドレス | 内部ポート |
| 1 | tcp | * | * | 61.117.148.132 | 10000 | 192.168.1.104 | 22 |
| 2 | tcp | * | * | 61.117.148.132 | 80 | 192.168.1.104 | 80 |
| 3 | tcp | * | * | 61.117.148.132 | 443 | 192.168.1.104 | 443 |
シンプルな設定であるが、ID#1で設定されているSSHだけはちょっと手を加えている。zulu.rewse.jpのSSH自体はTCP/22でリスンしているものの、ルーターはTCP/10000でリスンしており、zulu.rewse.jpのTCP/22に転送している。外部からはTCP/22はふさがれているので「とりあえずTCP/22が開いているかどうかつついてみよう」というクラッキングの第一歩を防いでいる。なお、TCP/10000というのは仮の値で、実際にはさらに違う値にしている。
これで基本的なセキュリティ対策はとられているが、念のため、zulu.rewse.jpにはiptablesでファイアウォールを設置し、ルーターとiptablesの二重のファイアウォールを通らないとアクセスできないようにしている。
iptablesを手動で設定するのは嫌なので、麦酒堂: dhcp / iptables を組み合わせた仮想的なネットワーク分離 で公開されているreftablesをベースとしたシェル・スクリプト「setiptables」を記述した。
ポイントはdividetoFirstChain()だ。192.168.1.104からまたは宛てのパケットはフィリタリングのきついGLOBAL_OUTPUT / GLOBAL_INPUTにチェーンされ、192.168.0.104からまたは宛てのパケットはフィルタリングされていないLOCAL_OUTPUT / LOCAL_INPUTにチェーンされている。
なお、麦酒堂ではフィルタリングされたパケットはすべてLOGGED_DROPチェーンに行ってしまうが、それだと何の理由でフィルタされたのかが分かりにくいので、NOT_ESTABLISHED / FRAGMENTED / PRIVATE_IP / TERMINATIONチェーンに分け、ログに接頭辞をつけるようにしてある。
setiptablesを実行した結果は以下のとおり。
# iptables -L -n -v Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 FRAGMENTED all -f * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 1 64 GLOBAL_INPUT all -- * * 0.0.0.0/0 192.168.1.104 11 572 LOCAL_INPUT all -- * * 0.0.0.0/0 192.168.0.104 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 1 52 GLOBAL_OUTPUT all -- * * 192.168.1.104 0.0.0.0/0 12 3808 LOCAL_OUTPUT all -- * * 192.168.0.104 0.0.0.0/0 Chain FRAGMENTED (1 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/hour burst 5 LOG flags 0 level 6 prefix `[FRAGMENTED] ' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain GLOBAL_INPUT (1 references) pkts bytes target prot opt in out source destination 0 0 PRIVATE_IP all -- * * 127.0.0.1 0.0.0.0/0 0 0 PRIVATE_IP all -- * * 10.0.0.0/8 0.0.0.0/0 0 0 PRIVATE_IP all -- * * 172.16.0.0/12 0.0.0.0/0 0 0 PRIVATE_IP all -- * * 192.168.0.0/16 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0 0 0 DROP all -- * * 0.0.0.0/0 255.255.255.255 0 0 NOT_ESTABLISHED udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ! ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 NOT_ESTABLISHED tcp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ! ESTABLISHED 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:21 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:25 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:53 1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:143 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:443 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 TERMINATION all -- * * 0.0.0.0/0 0.0.0.0/0 Chain GLOBAL_OUTPUT (1 references) pkts bytes target prot opt in out source destination 0 0 PRIVATE_IP all -- * * 0.0.0.0/0 127.0.0.1 0 0 PRIVATE_IP all -- * * 0.0.0.0/0 10.0.0.0/8 0 0 PRIVATE_IP all -- * * 0.0.0.0/0 172.16.0.0/16 0 0 PRIVATE_IP all -- * * 0.0.0.0/0 192.168.0.0/24 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 NOT_ESTABLISHED udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ! ESTABLISHED 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 1 52 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 NOT_ESTABLISHED tcp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ! ESTABLISHED 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:443 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 TERMINATION all -- * * 0.0.0.0/0 0.0.0.0/0 Chain LOCAL_INPUT (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0 0 0 DROP all -- * * 0.0.0.0/0 255.255.255.255 11 572 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 TERMINATION all -- * * 0.0.0.0/0 0.0.0.0/0 Chain LOCAL_OUTPUT (1 references) pkts bytes target prot opt in out source destination 12 3808 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 TERMINATION all -- * * 0.0.0.0/0 0.0.0.0/0 Chain NOT_ESTABLISHED (4 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/hour burst 5 LOG flags 0 level 6 prefix `[NOT_ESTABLISHED] ' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain PRIVATE_IP (8 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/hour burst 5 LOG flags 0 level 6 prefix `[PRIVATE_IP] ' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain TERMINATION (4 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/hour burst 5 LOG flags 0 level 6 prefix `[TERMINATION] ' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
1 Trackback
安全なネットワーク構成について考える
ハードウェア構成 で書いた機器を使用し、サーバを外部公開する際の安全...
Track from Your Website
http://rewse.jp/fukugan/trackback/tb.php?id=860
8 Comments
Re: ネットワーク構成
はじめまして。とても参考になる記事をありがとうございます。今ここで書かれているものとほぼ同じ機器構成(ルータにBRL-04FMX、ギガハブ、サーバにSC430)で、SC430上で動くVMの一つの外部公開を考えています。あまりにも構成が似ていて驚きました。
BRL-04FMXのセカンダリLANモードを利用されているようですが、もし外部公開のサーバが乗っ取られた場合、IPアドレスをプライマリLANの範囲内へ変更されるだけで簡単に内向きネットワークに侵入出来てしまいますよね。
BRL-04FMXのVLANを使えばネットワークを完全に分離可能ですが、その場合はBRL-04FMXのLAN側の速度が100mbpsのため、サーバと内向きネットワーク間の転送速度が落ちてしまいます。私はSC430をファイルサーバとしても利用しているため、ここは譲れません。LAN側転送速度が1000mbpsのルータを使えばいいのですが、まだ価格が高くて手が出ません。現在、以下の方法を検討中です。
1.SC430に物理NICを一枚追加し、SC430上でホストOSのネットワークと外部公開用VMの仮想ネットワークを完全に分離する。
2.BRL-04FMXのVLAN機能で、外部公開用VMのネットワークと内向きネットワークをグループ分けする。
この方法の場合、追加投資は最小限にセキュリティを高められると思うのですが、何かご意見などがあればお聞かせいただけないでしょうか？
よろしくお願いします。
From : juyama @ 2007-03-31 02:12:24 編集
Re: ネットワーク構成
型番からなにから一緒とは驚きです
ご指摘のとおり、現状の私の構成では外部公開サーバーが乗っ取られてしまうと、すべての内部にアクセスできてしまいますので、NIC二枚さしてVLAN切るってのはかなり良さそうですね。
ただ、私の環境では、各部屋間で一本のEthernetが壁内を通っているだけという状態なので、部屋Xと部屋Bの物理経路が一本しかないんです。
部屋Aは唯一二本Ethernetがあるのですが、この部屋はリビング・ダイニングなのでそこそこ大きいにも関わらずEthernetは対角線上にあるため、SC430の部屋Aへの移動 + 部屋の二辺分のEthernet配線というのが萎えます……。
ただ、いっそのこと外部向けネットワークは無線LANとかPLC経由にしちゃうってのもちょっと検討してみてもいいかもしれません。可用性に不安がありますが。
From : ガヂェット @ 2007-03-31 12:18:40 編集
Re: ネットワーク構成
なるほど、物理的な制約があるのですね。私は幸いすべての機器が同室にあるので、SC430にNICを追加してVLANで切る方法で試してみようかと思います。ちょうど昨日NICを購入し、今いろいろ試している最中です。外向けネットワークを無線化するのは不安が、、、でも以外と良いアイデアかもしれませんね。PLCは澤ったことがないのでわかりませんが。
実は今日NICと一緒に320GBのHDD2台買いました。RAID1を構築する予定です。SoftwareRAIDは初めてなので調べていたところ、またこのblogの記事に行き着きました。。さらにレンタルサーバからの移行なども、、状況がほんとうに似すぎです。w 私はさくらではなくxreaですが。
他の記事も含めて、本当に参考にさせていただいております。(ここまで似ていると真似と言えるかもしれませんw) また何かあれば報告させていただきたいと思います。どもありがとうございました。
From : juyama @ 2007-04-01 01:52:47 編集
Re: ネットワーク構成
VLANのグループ間もルーター経由で問題なく通信できることをマニュアルで確認しました。VLANのグループ間をカリカリにフィルターすれば、かなり安全そうですね。極端な話、VMware Server Console 経由ならばフィルターをすべて閉じちゃってもいいのかもしれません。
juyamaさんがうまく行きましたらここに報告お願いできないでしょうか。そしたら私もマシン移設含めてNIC2枚 + VLANにしたいと思います！
無線LANはLinux用ドライバ探してるだけで嫌になりました :-p イーサネット・コンバーターは高いし。
From : ガヂェット @ 2007-04-01 02:16:21 編集
Re: ネットワーク構成
今マニュアルを(初めて)読んでみました。下記のURLに置かれている、BRL-04FMX_v1.1.pdf です。
http://www.planex.co.jp/......
この97ページの 11.VLA についての記述があります。少し長いですが引用させてください。
「本製品のLAN側スイッチングハブはポートベースVLAN機能を持っています。これは相互通信を許可するポート間でグループを作り、異なるグループとの通信を完全に遮断する機能です。本製品のLAN側ポートは最高4つのVLANグループに分割できます（4グループの場合は全ポート独立）。」
実際に試してみたのですが、VLANの異なるグループ間は通信出来ませんでした。また、以下のような注釈があります。
「VLANで遮断していても、本製品のルーティングによりプライマリLANネットワークとセカンダリLAN（DMZ）ネットワークのルーティングは潜在的に可能です（デフォルトでは通過フィルタを設定していないので不可）。完全に遮断したい場合は、lan0とlan1間のフィルタが何も設定されていないことを確認しておいてください。フィルタエントリが存在しない場合、すべてのパケットは破棄されます。」
つまり、VLANでグループ分けすれば、基本的にグループ間のネットワークは完全に分離される。ただしセカンダリLANモードを利用し、LAN0とLAN1間のフィルタの設定することで、任意のパケットのみ通すことが出来る。ということではないでしょうか？
おっしゃるように、VMware ServerConsoleを使えば、グループ間のフィルタを完全に閉じても問題ありませんね。VLAN、セカンダリLANモードを使用した上で、sshのみ通すような設定にすると便利かもしれませんね。
まだ色々と試行錯誤している最中です。私はネットワーク、LINUXの知識が甘く、まだまだ勉強過程です。また何か報告出来ることがあれば、こちらに書かせていただきます！
From : juyama @ 2007-04-01 15:17:50 編集
Re: ネットワーク構成
そうですね、私のもその認識です。
私の場合も、メイン機がMacですぐに VMware Server Console が使えないので、内部LAN→外部向けLANのSSHだけは開放することになると思います。
From : ガヂェット @ 2007-04-02 09:05:20 編集
Re: ネットワーク構成
こんにちは、以前コメントさせていただいた者です。こちらの記事を参考にさせていただきながら、サーバの外部公開を行いました。
http://juyama.net/......
アドバイスどうもありがとうございました！
From : juyama @ 2007-04-29 16:54:18 編集
Re: ネットワーク構成
私の場合、1000Base-Tハブ + 100Base-TXボードの投資になりますが、メール・サーバー構築が終わったらやってみようという気になりました。ありがとうございます。
From : ガヂェット @ 2007-05-02 11:44:36 編集