ルーター設定概要
常時接続環境においてルータの設定を正しく行うことにより、 攻撃側にはルータが最初の障壁となることができます。 ここでは、ルータの正しい設定と、 ルータレベルのフィルタリングの設定を取り上げます。
ルータにおけるセキュリティには何があるでしょうか。
ルータに対してルーティング情報以外何も設定していない状態であれば、攻撃する側からはルータは素通りできます。もし、ここで何らかの制限があれば、攻撃側の活動範囲を狭めることや、攻撃が行えないようにすることも可能です。
ルータで設定できる範囲は非常に限られています。
しかし、大抵の場合、ポートの利用を制限することを行うことができます。
特定のポートを利用させないことを「ポートを閉じる」と呼びます。
これは、自ネットワークに対する特定のポートを使用するパケットをルータが破棄します。
これによって、自ネットワークには特定のポートを使用した攻撃が使用できなくなります。たとえば、「外部のネットワークからポート23へのアクセスを禁止する」という設定
行うと、外部からのtelnet要求はルータで破棄されるということです。
ポートスキャンで、
外部からどのホストのどのポートが空いているかをチェックするとき、
ルータでパケットを破棄させることによって自ネットワーク内のホストが守られるということにもなります。
ポートを閉じるアプローチは二つあります。
其の一:危険な(弱点となる)ポートを閉じる
この二つは同じ結果を指しているようにも考えることができます。
しかし、実際に設定されたルータを見てみると、
この二つは大きく違う設定がなされる場合が多いのです。
また、使用するポートのみを開けるということは、一見単純作業のように見えます。
ところが、実は非常に奥の深いものなのです。 特に、TCP/IPの仕様について熟知していなければLAN側からのアクセスに意図しなかった制限がかかってしまうこともあります。
まず行わなければならないこと。それは危険なポートを閉じるということです。
たとえば、NetBIOSやNFSを使用したファイル共有といったものは代表例です。
これらは真っ先に閉じる設定が必要になります。
どうしても他のネットワークから利用したい場合はルータでは開けておき、
LAN側で対応する設定を行う場合もあります。
表1
閉じるべきポート |
|||
ポート |
プロトコル |
サービス |
解説 |
1 |
TCP/UDP |
マルチプレクサ |
|
11 |
TCP/UDP |
systat |
|
15 |
TCP |
netstat |
|
43 |
TCP/UDP |
whois |
|
67 |
TCP/UDP |
bootp |
外部に公開する必要はない |
69 |
TCP/UDP |
tftp |
外部からはフィルタリング |
69 |
TCP/UDP |
Oracle
SQL*Net |
オラクルを使用している場合はフィルタリング |
70 |
TCP/UDP |
gopher |
Gopherを使用しなければフィルタリング |
79 |
TCP/UDP |
finger |
ユーザ情報が漏れるためフィルタリング |
87 |
TCP/UDP |
link |
よく狙われる |
95 |
TCP/UDP |
supdup |
よく狙われるためフィルタリング |
109 |
TCP/UDP |
POP2 |
POP2を使用していることが問題 |
110 |
TCP/UDP |
POP3 |
APOPやSSHを使用したポートフオワーディングを推奨 |
137 |
TCP/UDP |
NetBIOS
ネームサービス |
必ずフィルタリング |
138 |
TCP/UDP |
NetBIOS
データグラムサービス |
必ずフィルタリング |
139 |
TCP/UDP |
NetBIOS
セッションサービス |
必ずフィルタリング |
111 |
TCP/UDP |
sunrpc |
プログラムの使用ポートが漏れるためフィルタリング |
161 |
TCP/UDP |
SNMP |
外部には公開すべきではない |
162 |
TCP/UDP |
SNMP
TRAP |
外部には公開すべきではない |
177 |
TCP/UDP |
xdmcp |
Xのログインに使用するxdmが使用する |
201 |
TCP/UDP |
AppleTalk
ルーティングメンテナンス |
|
204 |
TCP/UDP |
AppleTalk
Echo |
|
202 |
TCP/UDP |
AppleTalk
ネームバインディング |
|
206 |
TCP/UDP |
AppleTalk
ゾーン情報 |
|
213 |
TCP/UDP |
IPX |
|
220 |
TCP/UDP |
imap3 |
使用していなければフィルタリング |
445 |
TCP/UDP |
Microsoft
DS |
|
512 |
UDP |
biff |
必ずフィルタリング |
512 |
TCP |
exec |
必ずフィルタリング |
513 |
TCP |
login |
必ずフィルタリング |
513 |
UDP |
who |
必ずフィルタリング |
515 |
TCP/UDP |
printer |
外部にプリンタを公開する必要はない |
517 |
TCP/UDP |
talk |
|
518 |
TCP/UDP |
ntalk |
|
520 |
UDP |
route |
|
540 |
TCP/UDP |
uucp |
使用しないのであればフィルタリング |
1025 |
TCP/UDP |
listner |
|
1433 |
TCP/UDP |
Microsoft
SQL Server |
SQL
Serverを使用している場合はフィルタリング |
1434 |
TCP/UDP |
Microsoft
SQL Monitor |
SQL
Serverを使用している場合はフィルタリング |
2049 |
TCP/UDP |
NFS |
必ずフィルタリング |
2766 |
UDP |
listen |
|
3268 |
TCP/UDP |
Microsoft
GC |
グローバルカタログ |
3269 |
TCP/UDP |
Microsoft
GC |
グローバルカタログ |
5631 |
TCP/UDP |
pcANYWHERE
data |
|
5631 |
TCP/UDP |
pcANYWHERE
stat |
|
6000-6063 |
TCP/UDP |
X11 |
Xで使用するポートは全て塞ぐ |
これは、一見単純な設定のように思えます。
しかし、単純に設定を行うとLAN側からも通信できない等の現象を引き起こします。
この作業は、実はTCP/IPを理解していないと行えない設定作業なのです。
セキュリティポリシーを考える段階で充分に検討を行ってください。
ルータにおけるセキュリティ設定において心がけておくことがあります。
それは「ルータのセキュリティはサイト全体のセキュリティの一要素にすぎない」ということです。
前述のリモートアクセスの回線をバックドアとして利用する場合や、
もしルータに致命的なセキュリティホールが見つかった場合などを考慮し、
そのLAN側でも防御を行うべきでしょう。
しかし、もし守るべきデータがルータレベルのもので十分であると判断した場合や、
利便性を考慮し別に設置するFirewallで賄うということであれば相応の設定で構わないでしょう。
比較的よく設定されるケースは、ルータとFirewallで設定の役割を分けているものです。たとえば、LAN全体における共通の設定かつ危険なポートに関してはルータで設定。
それ以外はFirewallで設定という使い分けです。
ルータで設定すると、そのネットワーク全体に影響を及ぼします。
また、ルータのOSによってはサイトの技術者では対応できない場合もあります。
このため、重大な問題を引き起こすもので設定が滅多と変わらないものをルータで設定するということが行われています。
攻撃を仕掛ける場合や踏み台として利用する場合の代表的な手法がIPアドレスの偽装です。
特に、RFC1918によって決められているプライベートIPアドレスやループバックアドレス(127.0.0.1)に偽装するものが多く見受けられます。
インターネット上では、プライベートアドレスを発信元とされているTCP/IPのパケットは全てフィルタリングしてしまうというポリシーを設定することができます。
これによって、プライベートIPアドレスを発信元としてIPアドレスを偽装しているパケットを拒否することができます。
また、インターネット上だけでなく、ルータが受け取るIPアドレスでループバックアドレスが発信元であるパケットはあり得ないため、これも拒否することができます。
では、実際にそのフィルタルールを作成してみましょう。
ここで作成したフィルタは外部から内部へ向かうパケットでプライベートアドレスとループバックアドレスは拒否するというものです。
ip filter 1 reject 10.0.0.0/8 * * * *
ip filter 2 reject 172.16.0.0/12 * * * *
ip filter 3 reject 192.168.0.0/24 * * * *
ip filter 4 reject 127.0.0.1 * * * *
ここに示した4つのフィルタリングルールは、外から中に対してだけではありません。
中から外に対しても設定しておく必要があります。
大抵の場合、プライベートIPアドレスは接続している上流のIPSなどでは、
プライベートIPアドレスを他に流さないよフィルタリングされています。
しかし、サイトのポリシーとして、自サイトが踏み台になったときにや、
上流がルーティングしてしまったとき、 プライベートIPアドレスで偽装したパケットを外に出さないようにしておくことが望ましいでしょう。
「上流がフィルタリングしているはずだから不要だ」ではなく、
自サイトから出さないという努力が必要なのです。
しかし、単純に拒否してしまうと、内部からのパケットも対象となってしまいます。この場合は、内部からサービスを提供しているポートは許可しておくことで解決できます。
「自アドレスを拒否する」ということは、一見矛盾しているようにも思えます。
しかし、前述のプライベートIPアドレスが発信元として設定されているパケット同様、
自アドレスを設定して送信してくる場合があります。
この場合、LAN側から外部に対してデータが流れる場合はありますが、
外部からLANに流れることはありません。 そのIPアドレスは自サイトにのみ存在するIPアドレスだからです。
これらのことから、 自サイトのIPアドレスが発信元となっているパケットが外部から届いた場合、
攻撃のためであると判断することができます。
ip filter 5 reject 111.222.333.0/24 * * * *
ソースルーティングが指定されているIPパケットを受け取った場合を考えてみましょう。
小規模サイトでは様々な利用形態が考えられます。 もし、SOHO環境などで組織から指示が出ているといったケースを除けば、
ソースルーティングは行わないようにしておくことが懸命です。
もし、これで問題が発生するようであればその相手と相談して有効にするかを検討してください。
ip filter source-route on
ルーティング情報もソースルーティング同様に関係する組織から指示が出ていない限りは拒否しておいたほうが無難です。
しかし、もし接続においてダイナミックルーティング等が行われていた場合、これを拒否すると接続のトラブルとなるため、十分に検討しておく必要があります。
ip filter routing protocol none
赤色の部分はルータのIPアドレスを設定します。
ip
filter 6 reject * 172.16.255.254
tcp,udp * 23 |
ip
filter 7 reject * 172.16.255.254
tcp,udp * 80 |
ここでは、172.16.255.254
のIPアドレスを持つルータに対し、 外部からのtelnetとHTTPを拒否している例です。
同じ要領で、LAN側の特定のホストに対し、 たとえばtelnetは禁止するという設定を加えることができます。
攻撃する側がポートスキャンを行う場合、稼動しているホストを絞り込みます。
もちろん、この作業を行わなくとも攻撃の対象となるサイトが所持しているIPアドレス全てにポートスキャンを行うことも可能ですが、稼動していないホストに対して行うことは効率が良くありません。
そこで、ポートスキャンを行う前に予め使用されているIPアドレス(マシンが接続されて稼動しているもの)を探しておきます。この時に、手っ取り早く確実に確認する方法がpingを使う方法です。
このpingで使用されるICMPをフィルタリングすることによって、
ICMPレベルでホストの存在を隠すことができます。
ただし、ルータによっては、ICMPそのものを拒否してしまうため、
LANからのpingも通らない可能性もあります。
設定を行うには十分注意して行ってください。
ip filter 8 reject * * icmp-info * *
Firewallから外に出るため、
LAN側のクライアントからはProxyを経由してインターネット上の各ホストに接続させる場合が多いでしょう。
これらは総称してProxyと呼ばれます。
攻撃する側も、これらは格好の材料となります。しかし、Proxyを攻撃するのではなく、
Proxyを踏み台として別のサイトを攻撃するのです。
これによって、攻撃する側は足跡を見つかりにくくするのです。
これは、Proxyの中でも、外部から外部に対して使えるようになっているProxyを指し、
「串」や「漏れ串」という隠語が使われています。
まず行わなければならない設定は、
それぞれのProxyに対してLAN側から外へのアクセスのみを許可するという設定です。
しかし、これだけでなく、ルータでも設定することが望ましいでしょう。
ルータからは、特定のホスト(Proxyとなっているホスト)からのHTTPのみを許可するといった設定です。
ここでは、Proxyサーバが111.222.333.444というIPアドレスを持ち、
ProxyとしてだけでなくDNSなども動作しているとします。
ip filter 10 pass 111.222.333.444/24 * tcp,udp 53,80 *
これによって、111.222.333.444のホストから外部に対するポート53(DNS)と
ポート80(HTTP)を通過させることができます。
また、これは、特定のホストから特定のプロトコルのみしか外部に出さないという設定を行うときにも有効です。
ここまでの設定は、ネットワークやサービスの種類に依らない共通となる基本設定です。
これをまとめると次のようになります。
ip
filter 1 reject 10.0.0.0/8 * * * * |
ip
filter 2 reject 172.16.0.0/12 * * * * |
ip
filter 3 reject 192.168.0.0/24 * * * * |
ip
filter 4 reject 127.0.0.1 * * * * |
ip
filter 5 reject 111.222.333.0/24 * * * * |
ip
filter 6 reject * 172.16.255.254
tcp,udp * 23 |
ip
filter 7 reject * 172.16.255.254 tcp,udp
* 80 |
ip
filter 8 reject * * icmp-info * * |
ip
filter 10 pass 172.160.0.0/16 * tcp,udp 53,80 * |
ip
filter source-route on |
ip
filter routing protocol none |
ルータ以外にFirewallを設置する場合、
ルータのセキュリティポリシーとFirewallのセキュリティポリシーを如何に分離させるかでLANからの利便性が大きく変わります。
利便性とセキュリティは相反する性質を持っており、
利便性が高くなるとセキュリティレベルが落ちることになります。
逆に、セキュリティレベルを高くすると、
利便性に問題が出てくることになります。
特に、ルータレベルで設定を行うとLAN全体に影響するため、
Firewallを設置している場合は、LAN全体を守るための設定などを行うことで良いでしょう。
冒頭で紹介した危険なポートの一例を挙げましたが、
これ以外にもOSやアプリケーションよにって危険なポートは存在します。
今回は、これらのポートを塞ぐ場合として考えてみます。
LANにはWindows系のOSを使用している場合も少なくないうえ、
NetBIOSを利用した攻撃も後を絶ちません。 まず、このNetBIOSのパケットをルータで拒否してみます。
ip filter 11 reject * * udp,tcp 137-139 *
NetBIOSでは、ポート137,138,139を使用しているということは有名なため、
ご存知の方も多いでしょう。