■Snortに「Emerging Threats(ET)」ルールを導入する。
Tor通信のブロックの対処自体は古くから存在する。
なりすましの行われた後のトロイやウイルスを防げるわけではないが、
内から外へTor通信は行わせないことは出来る。
「Emerging Threats Pro(ET Pro)」は「Kaspersky Lab」でも使用されており、
商用レベルの侵入検知（IDS）/侵入防止（IPS）用の各ライセンスの異なる
Snort ルールセットおよび Suricata が開発されている。
Kaspersky Lab、Emerging Threats Pro とのパートナーシップを発表
http://www.kaspersky.co.jp/news?id=207582754
The Emerging Threats Open Source Community
http://www.emergingthreats.net/open-source/open-source-overview/
Emerging Threats Rule Documentation Wiki
http://doc.emergingthreats.net/
■SnortやSquidGuard、iptablesと連携して、以下のような対応をしてきた。
はてなオプトイン問題はSquidGuardだけだが、Sqnortでも可能。
今回はTorにも対応したい。
ApacheKiller
Java の新しいゼロデイ脆弱性（CVE-2012-4681）
Tポイントツールバー
Snort動作テスト用のICMPのローカルルール
はてなオプトイン問題(bookmark_button.js)
Debian Lenny にsquidGuardを導入
http://d.hatena.ne.jp/labunix/20120311
■Snort導入環境は以下。postgresの導入前にSnortユーザがあると楽。
Lenny 侵入検知システムsnortでApachekillerを検出
http://d.hatena.ne.jp/labunix/20110917
CVE-2012-4681をSnortで検出、アラート、SquidGuardとiptablesでブロック
http://labunix.hateblo.jp/entry/2012/08/29/215603
Squeezeにsnort-pgsqlの導入
http://d.hatena.ne.jp/labunix/20120815
Snortのalertログで遊ぶ(テスト用ICMPローカルルール)
http://d.hatena.ne.jp/labunix/20120821
Tポイントツールバーのブロック色々
http://labunix.hateblo.jp/entry/2012/08/11/175214
$ dpkg -l | grep snort | grep ^ii | awk '{print $2}'
snort-common
snort-common-libraries
snort-pgsql
snort-rules-default
$ dpkg -L oinkmaster | grep 'etc/'
/etc/oinkmaster.conf
■DB連携すると、デフォルトのSnortのログメールが使えなくなるので。
snort-mysql/snort-pgsqlのレポートメール
http://d.hatena.ne.jp/labunix/20120817
■mysqlの方が良い方は下記で。
snort-mysqlの導入、DNSバージョンチェック、シグニチャの確認
http://d.hatena.ne.jp/labunix/20120809
■Snortの警告はカスタマイズするか、そもそもパケットの流量を絞る。
出来ればその両対応を行った方が良い。
正常性の確認も忘れずに。
Snortの警告の対応方法のテンプレート
http://d.hatena.ne.jp/labunix/20120512
Snortの動作中に統計を見る(正常性チェック)
http://d.hatena.ne.jp/labunix/20120811
bash+snort-pgsqlで健康状態、統計情報の確認。
http://d.hatena.ne.jp/labunix/20121122
■ETルールで必要なのは以下の2つのルールファイルと各mapファイルです。
emerging-policy.rules(Torノード間の接続)
emerging-tor.rules(Torノード出口との接続)
「Emerging Threats(ET)」、または「Emerging Threats(ET) Pro」の
ライセンスについては最後にも記載する。
$ /usr/sbin/snort -V 2>&1 | grep Ver | sed s/".*V"/"V"/g
Version 2.8.5.2 (Build 121)
■ETルールの「2.8.5」のルールをダウンロードします。
Torノード出口との接続に関するルールと、
Torノード間の接続に関するルール、
設定ファイルとmapファイルがあることが分かります。
$ wget http://rules.emergingthreats.net/open/snort-2.8.5/emerging.rules.tar.gz
$ tar zxvf emerging.rules.tar.gz
$ find rules/ -type f -print | grep "tor\|policy\|conf\$\|map\$" | sort -t \. -k 2
rules/emerging.conf
rules/gen-msg.map
rules/sid-msg.map
rules/unicode.map
rules/emerging-policy.rules
rules/emerging-tor.rules
■Torについて
詳しくは下記を参照してもらうものとする。
Tor
http://ja.wikipedia.org/wiki/Tor
Torの善悪は置いておくとして、意図しないセグメント以下のマシンがTorを使うのは困る。
上記のセグメントの出入り口の分断には、Snortで監視するNICを指定すればよい。
■Torクライアントからのアクセス
SSLだとしてもドメインURLの接続にはSquid/SquidGuardで対処可能。
■TorディレクトリサーバとTorクライアント間の通信
TorクライアントはTorディレクトリサーバに平文で接続するか、SSLで接続する。
Torサーバから無作為にTorノードを選択し、通信はセッション鍵で暗号化されてTorノード出口から出る。
TorクライアントはP2P型Socksプロキシとして動作する。
IEはSoksプロキシに対応していないのでTorクライアントとしては対処不要。
ChromeやFirefoxはSocksプロキシに対応しているのでTorクライアント対応を行う。
「tor.eff.org」または、「eff.org」、「www.torproject.org」
Torドメイン any -> HOME any
HOME any -> Torドメイン any
■上記はデフォルトのルール(community-misc.rules)で検出可能である。
TorディレクトリサーバとTorクライアント間の通信で、
対象とするポートは変更可能な為、絞ることは出来ないが、
コンテンツ中の可読文字を見ると、特徴的な通信を行う事が分かる。
$ sudo grep -A 2 " TOR " /etc/snort/rules/* | sed s/".*msg\:\|;.*\|([0-9]*)\|^#.*"//g
/etc/snort/rules/community-misc.rules:# TOR Rules by Dan Ramaswami
"COMMUNITY MISC DLR-TOR Directory server response"
"COMMUNITY MISC DLR-TOR Client Traffic"
$ sudo grep -A 2 " TOR " /etc/snort/rules/community-misc.rules | \
sed s/";\|("/"&\n"/g | grep HOME | sed s/"alert \|("//g
tcp $EXTERNAL_NET any -> $HOME_NET any
tcp $HOME_NET any -> $EXTERNAL_NET any
$ sudo grep -A 2 " TOR " /etc/snort/rules/community-misc.rules | \
sed s/";\|("/"&\n"/g | grep content | sed s/".*\:\"|\||\";"//g
54 4f 52
06 03 55 04 03
20 3C 69 64 65 6E 74 69 74 79 3E
54 4f 52
06 03 55 04 03 14
63 6c 69 65 6e 74 20 3C 69 64 65 6E 74 69 74 79 3E
$ sudo grep -A 2 " TOR " /etc/snort/rules/community-misc.rules | \
sed s/";\|("/"&\n"/g | grep content | sed s/".*\:\"|\||\";"//g | \
sed s/" \|^"/"%"/g | nkf --url-input
TOR
U
<identity>
TOR
U
client <identity>
■Torディレクトリサーバで無作為に選択されたTorノードへの参加については、
「The Onion Router」や、「Hidden Service」と呼ばれるルール、
また類似したメッセージのルールで対応可能。
Snortのデフォルトに無い、「Emerging Threats(ET)」のオープンルール、
「emerging-policy.rules」を使用する。
$ grep " TOR " rules/emerging-policy.rules | \
sed s/".*msg\:\|([0-9]*)\|^#.*\|\;.*\( sid\:[0-9]*\; rev\:[0-9]*\).*"/"\1"/g | sort -u
"ET POLICY DNS Query for TOR Hidden Domain .onion Accessible Via TOR" sid:2014939; rev:1
"ET POLICY TOR .exit Pseudo TLD DNS Query" sid:2014941; rev:3
"ET POLICY TOR 1.0 Inbound Circuit Traffic" sid:2002952; rev:5
"ET POLICY TOR 1.0 Outbound Circuit Traffic" sid:2002953; rev:5
"ET POLICY TOR 1.0 Server Key Retrieval" sid:2002950; rev:6
"ET POLICY TOR 1.0 Status Update" sid:2002951; rev:5
■Torノード出口
上記2種類で内⇒外の最低限は対応可能だと考える。
また、外⇒内についても、既知の固定IPのTorノードはIP指定で拒否が可能。
本質的には、すべてのTorノードを拒否出来なければ意味が無いのだが、
既知のTorノード出口には最低限対応しておきたい。
「emerging-tor.rules」では、既知のTorノードとして810のIPアドレスの
すべてのポートが対象、内向きのTCP/UDP通信の各ルールがある。
$ sed s/".*msg\:\|([0-9]*)\|^#.*\|\;.*\( sid\:[0-9]*\; rev\:[0-9]*\).*"//g rules/emerging-tor.rules | sort -u
"ET TOR Known Tor Exit Node TCP Traffic "
"ET TOR Known Tor Exit Node UDP Traffic "
$ grep "Tor Exit Node" rules/emerging-tor.rules | \
sed s/".*\[\|\].*"//g | \
sed s/","/"\n"/g | \
grep ^[0-9] | \
sort -u | \
wc -l
810
$ grep "Tor Exit Node" rules/emerging-tor.rules | \
sed s/".*\]\|(.*"//g | \
sort -u | \
sed s/"^ "/" [Tor ノード出口] "/g
[Tor ノード出口] any -> $HOME_NET any
■「emerging.conf」は、「/etc/oinkmaster.conf」と同様に記載すればよい。
デフォルトではすべてコメントアウトされている。
$ wc -l rules/emerging.conf
93 rules/emerging.conf
$ grep -v "^#\|^\$" rules/emerging.conf | wc -l
0
■ルールのコピー。
$ find rules/ -type f -print | grep "tor\|policy" | sudo cp -pi `xargs` /etc/snort/rules/
$ sudo ls /etc/snort/rules/emerging*.rules | grep "tor\|policy"
/etc/snort/rules/emerging-policy.rules
/etc/snort/rules/emerging-tor.rules
$ sudo grep emerging /etc/snort/snort.conf
include $RULE_PATH/emerging-policy.rules
include $RULE_PATH/emerging-tor.rules
$ sudo /etc/init.d/snort restart
■失敗する場合は以下で。
「-D」デーモンとしてや、「-i」インターフェイス指定などのオプションも付けられる。
$ sudo dpkg-reconfigure snort-pgsql
■各mapファイルをチェックする。
$ diff -y --width=80 rules/gen-msg.map /etc/snort/gen-msg.map | grep "<\$\|>"
116 || 406 || snort_decoder: Invalid <
119 || 20 || http_inspect: MAX HEADER <
119 || 22 || http_inspect: CHUNK SIZE <
129 || 13 || stream5: TCP 4-way hands <
129 || 14 || stream5: TCP Timestamp i <
139 || 1 || sensitive_data: sensitive <
$ diff -y --width=80 rules/unicode.map /etc/snort/unicode.map | grep "<\|>"
$ diff -y --width=80 rules/sid-msg.map /etc/snort/sid-msg.map | grep "<\$\|>" | wc -l
13771
■mapファイルのマージ
※unicodeは「sort -u」でマージすると失敗する。
$ find /etc/snort/ -type f -name "*.map" | \
grep "gen\|\/sid\|unicode" | \
for bak in `xargs`;do \
sudo cp -pi "$bak" "${bak}.bak"; \
done
$ ls /etc/snort/*.bak
/etc/snort/gen-msg.map.bak /etc/snort/unicode.map.bak
/etc/snort/sid-msg.map.bak
$ for list in gen-msg.map sid-msg.map;do \
sort -u "/etc/snort/${list}.bak" ~/rules/$list | sudo tee "/etc/snort/${list}" > /dev/null; \
done
■「ICMP Test」のrev番号を上げて確認。
$ grep ^alert /etc/snort/rules/local.rules
alert icmp any any -> any any (msg:"ICMP Test"; sid:200003851; rev:2;)
$ echo "select * from signature;" | sudo -u snort psql -U snort -d snort -A -F\, | grep "^s\|ICMP"
sig_id,sig_name,sig_class_id,sig_priority,sig_rev,sig_sid,sig_gid
1,ICMP Test,,,1,200003851,1
8,ICMP Test,,,2,200003851,1
■通常の443通信を行っても検出されない。
これはSquid/SquidGuardで対応した方が良さそう。
$ w3m -dump_head https://www.torproject.org/
SSL error: error:00000000:lib(0):func(0):reason(0)
w3m: Can't load https://www.torproject.org/.
$ w3m -dump_head https://tor.eff.org
SSL error: error:00000000:lib(0):func(0):reason(0)
w3m: Can't load https://tor.eff.org.
$ w3m -dump_head https://eff.org
HTTP/1.1 200 OK
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze14
X-Drupal-Cache: MISS
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Mon, 24 Dec 2012 17:14:55 +0000
Cache-Control: public, max-age=1800
ETag: "1356369295-1"
Content-Language: en
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Strict-Transport-Security: max-age=2628000
Content-Type: text/html; charset=utf-8
Content-Length: 8385
Date: Mon, 24 Dec 2012 17:35:42 GMT
X-Varnish: 1158414935 1158384666
Age: 1246
Via: 1.1 varnish
Connection: close
■名前解決後の分もSquid/SquidGuard対応。
$ dig onion.to | grep ^onion
onion.to. 300 IN A 209.141.39.51
onion.to. 300 IN A 37.247.50.149
onion.to. 300 IN A 209.141.39.180
$ dig onion.to NS | grep ^onion
onion.to. 10800 IN NS dns1.easydns.com.
onion.to. 10800 IN NS dns2.easydns.net.
onion.to. 10800 IN NS dns3.easydns.org.
onion.to. 10800 IN NS dns4.easydns.info.
■「unable to get local issuer certificate」は、
ルート証明書のファイルをOpenSSLコマンドに教えていないためです。
これも、Squid/SquidGuard対応。
$ openssl s_client -connect eff.org:443 -showcerts > tor.ssl
depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
$ openssl s_client -connect tor.eff.org:443 -showcerts >> tor.ssl
depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
$ openssl s_client -connect www.torproject.org:443 -showcerts >> tor.ssl
depth=1 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
verify error:num=20:unable to get local issuer certificate
verify return:0
$ grep "Cipher\|Key\|Session" tor.ssl | sort -u
Cipher : DHE-RSA-AES256-SHA
Cipher : RC4-SHA
Key-Arg : None
Master-Key: 15B2751AD139459916E9B71CFD531A0F74CEDACC5DF7DDA4F8EE1065C231D1C3B5C12809BD341BD39C336D7327738787
Master-Key: CD44D55898C545EDAACDE476723CC98FB00F96DB8465356F5DA0EF3828ABFCD6EE9A411A8CAF04416A6F7491DE7B5DA9
Session-ID-ctx:
Session-ID: BC042E8133DC3EF44BA1048BE9F209186DAC18AFF1FFB5AFCB1E2D57726DF614
Session-ID: D8E2E637E845C030B6194F1FAED15CCF794A1054EFA1363FB5517625A7A3DB3E
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
New, TLSv1/SSLv3, Cipher is RC4-SHA
SSL-Session:
□「Emerging Threats(ET)」、「Emerging Threats(ET) Pro」のライセンスについて
「open」ディレクトリは下記のように
GPLv2、BSD、ETProの3つのライセンスが混在している。
$ w3m -dump http://rules.emergingthreats.net/open/snort-2.8.6/LICENSE | \
grep Rules | sed s/" under\|covered "/"\n&"/g
under the GPLv2.
covered under the BSD License
covered by the license
□エキサイト翻訳結果が以下です。
大体意味は通ると思いますので、修正なしで掲載します。
不明点は別の項でカバーされていると感じましたので、他はご一読下さい。
エキサイト翻訳
http://www.excite.co.jp/world/english/
15. フリー・ソフト。
この製品は、ユーザがあるプログラムをコピーし、修正し、再分配することを他の権利中に、
可能にするGNU一般ライセンス(GPL)あるいは他の同様のフリー・ソフト・ライセンスの下の
ユーザに許可される(あるいはサブライセンスを与えられた)いくつかのソフトウェア・プロ
グラム、あるいはその部分を含んでいて、ソース・コード(「オープンソース・ソフトウェア
」)にアクセスするかもしれません。
GPLは、GPL(それは実行可能なバイナリフォーマット中の誰かに配布される)の下でカバーさ
れた任意のオープンソース・ソフトウェア用のそれを要求します、ソース・コード、さらに
それらのユーザに利用可能になります。
GPLの下でカバーされた任意のオープンソース・ソフトウェアについては、ソース・コードは
このCDあるいはダウンロード・パッケージで利用可能になります。
いずれかのオープンソース・ソフトウェア・ライセンスがその新興脅威を要求する場合、プロ
、LLC、オープンソース・ソフトウェア・プログラムを使用するか、コピーするか、修正する
権利を提供する、それはこの合意中で与えられた権利よりその後広い、そのような権利は権利
と制限にここに優先するものとします。
