「漏れ漏れくん」のプロキシ判定で、Anonymous(A)と言われるには
独自のプロキシサーバーを作ると、何かと便利なのだが、ちょっと気になるのは、自分の作ったプロキシがどの程度匿名性に優れているかということになってくるのだが、ちょいと気になったら、以下を参照して、プロキシ判定をしてみると良い。
これらの判定システムは、それぞれ独自の機構で動作しており、それぞれが、異なった判定をするのだが、せっかく作った独自のプロキシの判定が悪いと悲しい。
と、言うことで、今回は、Proxy判定で、完全っぽい匿名串を作るお話。
いろいろなプロキシの設定方法があるが、今回は、サイド記事でも取り上げた、squidによる匿名串の作り方を書いてみたいと思う。
squidの導入手順
CentOSなら、概ね、yumでインストールできるので、それで、インストールすると良いが、CentOS 5とCentOS 6とで、インストールされるsquidバーッジョンが異なってくるので、その点、少しテクニックがいる。
・CentOS 5系 → Squid 2.xx.xx
・CentOS 6系 → Squid 3.xx.xx
どちらでも、同様に動作して欲しいところなのだが、若干判定が異なってくるので、CentOS 6系で、「漏れ漏れくん」が良い結果を出さない場合もあったりして、少しガッカリするのだが、そんな場合も、実はあまり気にする必要は、無いようで、動作環境さえ整えれば、Anonymous(A)判定前後は出るようになる。まずは、squidの導入
# yum install squid ← これだけで良い。レポジトリにrpmforgeや、epelなどが使えるが、どれも同じ。
次に、環境設定
# cd /etc/squid
# vi squid.conf
とし、まずは、概ねのお決まりを設定Ver.2系では、ドキュメント形式のsquid.confが、Ver.3系では、必要最小限のsquid.confがインストールされているので、それを適宜編集する。
Ver.2は、Documented Versionなので、行数は、多くて設定しにくい印象があるが、要約すれば、以下の点を編集すれば、基本的には動作する。
#
# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1 削除
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 削除# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
以下をコメントアウト
#acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
#acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#acl localnet src fc00::/7 # RFC 4193 local private network range
#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl localnet src xxx.xxx.xxx.0/24←ネットマスクは適宜に（アクセス許可するIPアドレスを指定）
中略
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
http_access allow localnet← 追加（上記のドレスとセットで指定）
# And finally deny all other access to this proxy
http_access deny all ← ここはいじらなくて良い完全なOpenプロキシにしたいという奇特な人は、 allow all
# Squid normally listens to port 3128
http_port 3128 ← 変えたい人は、空いてるポートへ変更
中略
# Uncomment and adjust the following to add a disk cache directory.
cache_mem 16 MB← 追記
maximum_object_size 16384 KB ← 追記
cache_dir ufs /var/spool/squid 100 16 256 version3を使う場合は、100を1000あたりに変更
※ chace_mem < checheファイルの関係になっていること
※Ver.2はDefaultのままでOK、Ver.3は、 100→500あたりに指定
例） chache_dir ufs /var/spool/squid 500 16 256 これをしないと、Ver.3は走らないので注意以上で、概略設定が終わるので、squiを走らすための設定を行う。
FireWall (iptables）の編集
-A SERVICE -p tcp -m tcp –dport 3128 -j ACCEPT ← 追加 ポートオープンsquidの起動
# squid -z ←chacheファイルの作成（初期化） 本体は、/var/spool/squid/以下に作成される。
# service squid start
次回移以降の為の自動起動有効化（daemonプロセスの有効化）
# chkconfig squid on ←起動を手動にしたい場合は、 #chkconfig squid off
匿名化
匿名串への対応は、いろいろとあるが、以下を追加すれば、匿名串になる。
Ver.2系
header_access X-Forwarded-For deny all
header_access Via deny all
header_access Cache-Control deny all
Ver.3系
request_header_access X-Forwarded-For deny all
request_header_access Via deny all
request_header_access Cache-Control deny all
reply_header_access X-Forwarded-For deny all
reply_header_access Via deny all
reply_header_access Cache-Control deny all
「漏れ漏れくん」などのの判定の為のチェック
- FQDNとIPアドレスの一致
逆引きが一致しないと、Anonymous（A)判定はまず無理。
逆引きが全く設定されていないサーバーの場合は、逆引き設定はいらない。
設定が反映すれば、基本的には、Anonymous(A)なので、気にしなくても良いが、場所によっては跳ねられる場合がある。
匿名性との兼ね合いになるので、ここは、気持ち次第。- できるだけ、WebServer特有のポートは開けない。
mailポートは塞いでおいたほうが、判定が良好になる。
所によっては、簡単なポートスキャンや、SSLポートを見に行くので、443ポートを開けたい場合は、server.crtなどの情報へのCNとホスト名の一致、逆引きFQDNの一致が必要
CN=www.hogehoge.com
hostname=hogehoge.com
逆引きFQDN=wwwhoge.hoge.ne.jp
などと、別の名前を返すサーバーは、まず、Anonymous(A)にはならない。
上記を全て一致させること。
例）
CN=hogehoge.com
hostname=hogehoge.com
逆引きFQDN=hogehoge.com- IPアドレスが、できるだけ新しいものであること。
RBLなどへ登録されてしまっていると、まず、判定は低下する。
これは、どうにもならないので、判定が悪くても気にしなくてＯＫ※IPアドレスチェックは厳しいので、もし、判定が、B-とか出ても、先に述べたENV Checker -環境変数チェッカーなどで、たぶんAnonymous(A)ですと言われれば、基本的には、環境変数を吐き出していないので、匿名串としては、良好と考えて良いかもしれない。
以上をパスすれば、匿名串の完成であるわけだが、何が匿名串なのかという疑問点も残るので、設定はほどほどにして、自分がアクセスしているロケーションが分からなければ良い。程度にしておいても、実用上問題ない。
プロキシの効用
プロキシを使って何が嬉しいか
- キャッシュの利用により、アクセスが早くなる。
- 自分のマシンが危険に晒されるリスクが低減し、ハッキングなどによって左右されるアクセススピードの低下を防ぐ事ができる。
- 地域限定サービスへのアクセスができる。
- 地方でも、首都圏のラジコが聞ける。
- 米国にプロキシを作れば、yuku,veohなんかが見れる。
同様に、Napsterや、Amazon cloudなどの完全サービスが受けられる？
同様に日本からはアクセスが困難な貴重な資料に到達する確率が上がる。- Webメール経由でメール発信すれば、発信元アドレスが特定できない。
- リバースプロキシを作れば、どこでもドアが作れる・・？
デメリット
- 逆にアクセスできないサイトに出くわすことがある。
- 頻繁に変わるサイトへの情報は、最新にならない可能性がある。
- プロキシサーバーのバックボーン次第で、逆にスピードが低下してしまう。
良いことばかりではないが、メリットのほうが、多いかも知れませんね。
プロキシは、悪用禁止だが、クライアントアクセスに対しては、安全性が高まるので、清く正しく利用すれば、便利ですかね。適当なオープンポート経由でアクセスできるようなプロキシを作れば、基本、社内検閲を逃れられるので、会社がアクセスを禁止しているサイトへのアクセスも可能になるかも（80番ポートじゃだめだけどね・・）。しかし、見つかると、大目玉を食らうので、利用はほどほどにしておいたほうが吉。トンネル掘ってもいいけど、これも、たぶんアウト。めっかったら、ただじゃすまないかな。
適宜、ほどほどに。
1 Comments.