https://ameblo.jp/h1debl0/ ブログの説明を入力します。 ja
今まではUntrustからTrustへポート制限をかけてVIPで接続してたんだけど、DMZを介してTrustとUntrustをつなげようと思った。

Untrust側のIPはプロバイダから固定でもらってるから、TrustからUntrustへ出るときはSrcNATかけてる。
だから同じようにDMZからUntrustへ出るんだからSrcNATをかければいいと思って設定したんだけど。。
つながらん・・orz

どうやら原因はNAT設定がちゃんとできていないことにあったらしい。

通常？NSでTrustからUntrustに出るときに設定するNATは「Interface-Edit-InterFaceMode」をNATにすればいいと思うんだけど、DMZの場合これではちゃんとNATがかからないらしい。

試しにTrust-Untrustで許可設定を入れたポリシーとDMZ-Untrustで許可設定を入れたポリシーでログを見てみた。
もちろんInterfaceModeは両方共NATで。

そうするとTrust-UntrustはSrcNATはかかってたけど、DMZ-UntrustはプライベートIPで通信されてた。
どうりでtcpdumpとってもパケットが出るばっかりで戻ってこないわけだ・・

というわけで今度はPolicesのDMZ-UntrstでNAT設定を入れた。
「Polices-Edit-Advanced-NAT-Source Translation」にチェック。

もう一度ポリシーでログを確認するとちゃんとSrcNATがかかって通信ができた。

めでたしめでたし。 ]]> https://ameblo.jp/h1debl0/entry-11505667258.html Fri, 05 Apr 2013 23:04:46 +0900 が、せっかくなのでもう少しいじくってみようと思います。

設定内容は60秒以内に3回アクセスしてきたIPアドレスをAttackerとしてリストへ保存し、以後遮断するといった内容。

設定内容

いじくった後の設定内容はこんな感じ。
root@bt:/proc/net/xt_recent# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: CHECK name: attacker side: source
tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: SSHConn side: source
SSHAttacker tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 60 hit_count: 3 TTL-Match name: SSHConn side: source

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain SSHAttacker (1 references)
target prot opt source destination
all -- anywhere anywhere recent: SET name: attacker side: source
DROP all -- anywhere anywhere

ぶっちゃけ自分のレベルではこんなものを見てもどんなコマンドでこういう設定が入ったのかわかりませんw
なのでメモとしてコマンドも載せます。

設定コマンド

まずは現在のiptables設定の初期化。
先に-Fの方を実行しないと怒られる事があるので注意。
# iptables -F　←チェイン配下のルール削除
# iptables -X　←ユーザ定義のチェイン削除

各テーブルの基本となる動作設定。
# iptables -P INPUT ACCEPT　←端末への通信をすべて許可
# iptables -P OUTPUT ACCEPT　←端末からの通信をすべて許可
# iptables -P FORWARD DROP　←端末を介する通信をすべて遮断

ブロックする条件に一致した通信を処理
# iptables -N SSHAttacker　←SSHAttackerチェインを追加
# iptables -A SSHAttacker -m recent --set --name attacker　←SSHAttackerチェインが呼び出されたとき、attackerリストへIPアドレスを追加。
# iptables -A SSHAttacker -j DROP　←追加直後の通信を遮断

SSH通信を処理
# iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --rcheck --name attacker -j DROP　←attackerリストに記載されたIPを遮断

# iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSHConn　←SSH接続をしてきたIPアドレスをSSHConnに追加
# iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSHConn -j SSHAttacker　←60秒以内に3回アクセスしてきた通信をSSHAttackerへ引き渡す。

これで動くはず。
設定コマンドが長いのでファイルにコマンドを羅列し、shなんかで流すと次から楽だと思います。


SSH接続されたときのフロー
１SSHの接続要求
２INPUTチェインにわたす。
３attackerリストに記載されたIPアドレスか確認。記載されていたら遮断。されていなければ次の処理。
４SSHConnリストへ追加、もしくは接続時間の更新。
５60秒以内に何回アクセスが来たか確認。
６3回未満なら通信を許可。3回目ならSSHAttackerチェインへわたす。
７SSHAttackerチェインにてattackerリストへ追加。
８遮断する。

こんな流れだと思ってます。
間違ってたら教えてくださいw

細かいとこも突っ込んで勉強したいけども他に勉強したいことがあるのでiptablesに関しては一旦終了。
次はLISPだ。
]]> https://ameblo.jp/h1debl0/entry-11501922231.html Sun, 31 Mar 2013 16:28:12 +0900
でもやっぱり/var/log/auth.logにはいろんなところからアクセスされている形跡があり、小心者の自分としては怖いものがあるのでiptablesの設定を入れてみようと思います。

今回設定する内容
tcp/22ポートに通信が来た際、1分間に3回失敗したら攻撃として認識し、以後アクセスをドロップする。

まず、iptablesってなんやねんというところですが、ただ単にfilterしてくれる機能と覚えてます。NATもしてくれるらしい。
さらにrecentによって動的なアクセス制御が可能になります。

まず現在の設定の確認。
# iptables -L

root@bt:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


見ての通りからっけつの状態です。

内容を見てみると、INPUT・FORWARD・OUTPUTとあります。
これらのことをテーブルと言います。
また、度々チェインという単語が出てくると思いますが、チェインはそのテーブルにかかれたルールのことをさします。

INPUTテーブルに記述されたチェインは、宛先が自身の通信。
OUTPUTテーブルに記述されたチェインは、送信元が自身の通信。
FORWARDテーブルに記述されたチェインは、宛先が他端末の通信。

今回はSSHサーバにiptablesの設定をするので、INPUTテーブルにチェインを追加します。

追記
どうやらテーブルとチェインについて勘違いしてたみたいです。
INPUT・OUTPUT・FORWARDがチェインと呼ばれるもので、テーブルはもう一つ上の階層みたい。
で、テーブルはfilter・nat・mangleの三つ。
今回設定するのはfilterテーブルのINPUTチェインとなる。


# iptables -A INPUT -p tcp --syn --dport 22 -m recent --name attacker --set

-A INPUT ←INPUTへ追記する。
-p tcp ←tcpプロトコルを指定する。
--syn ←3wayハンドシェイクの起点となるパケットを対象とする。
--dport 22 ←Destination Port(宛先ポート)が22番の通信を対象とする。
-m recent ←recentモジュールの呼び出し。
--name attacker ←対象リストを呼び出し。
--set リストへアドレスを追加。


# iptables -A INPUT -p tcp --syn --dport 22 -m recent --name attacker --update --seconds 60 --hitcount 3 -j DROP

--update ←条件に一致したときタイムスタンプの更新
--seconds 60 ←60秒
--hitcount 3 ←3回
-j DROP ←パケットを遮断する。

もう一度設定を確認。

root@bt:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN recent: SET name: attacker side: source
DROP tcp -- anywhere anywhere tcp dpt:ssh flags:FIN,SYN,RST,ACK/SYN recent: UPDATE seconds: 60 hit_count: 3 name: attacker side: source

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


ちゃんと入ってそう。

ここで一つ自分が認識している勘違いに気づいた。
一定の条件にヒットしたものをattackerに記載して、それを弾くと思ってたんだけど、実際の動きは通信がきたものをすべてattackerに記録するみたい。
で、attackerに入っている記録を元に条件に当てはめて通信を許可するかどうかを判断するらしい。
いくつか検証してみないとなぁ。

まぁとりあえず以上の設定でauth.logは綺麗になってくれるはずです。
ちなみにattackerのリストです。
# cat /proc/net/xt_recent/attacker

早速IPがいくつか登録されていました。
これでちょっと様子をみてみようかな。 ]]> https://ameblo.jp/h1debl0/entry-11500923466.html Sat, 30 Mar 2013 01:57:23 +0900 環境は[蔵]-[global]-[fw]-[鯖]でFWにはxxx.xxx.xxx.xxx:22に接続が来たものはVIPを使ってSSH鯖に流す。

大まかなインストールフロー
鯖操作
１鯖へSSHサービスのインストール
２SSHサービスのconfファイル設定
３ホスト認証用のキー作成
４キーを正しく配置

蔵操作
５蔵へSSH蔵のインストール
６ユーザ認証用のキー作成
７キーを正しく配置

鯖操作
８鯖でサービスの開始

蔵操作
９蔵から接続

では早速SSHの導入

鯖側
まずはSSH鯖サービスのインストール
# apt-get install openssh-server

sshdの設定
# vim /etc/ssh/sshd_config
#HostKey /etc/ssh/ssh_host_dsa_key　←dsa使わないのでコメントアウト
PermitRootLogin without-password　←rootへのパスワード認証以外を許可
PasswordAuthentication no　←パスワード認証を禁止

なんか他にもいじくった気がするけど、結局上の変更だけで問題ないはずw

ホスト認証用のファイルを作成
どうやらssh接続をするときは二つのプロセスを踏むらしい。
1.ホスト認証
　蔵から鯖への接続先が正しいか。
2.ユーザ認証
　鯖は接続された蔵の接続を許可していいか。

まずはホスト認証で使う認証キーを作成
これは通常インストール時に自動的に作られるけど、なかったら作る。
後、/var/log/auth.logでCould notうんたらかんたらっていうssh_host_rsa_keyが
読み込めません的な時も再度作る。
# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

root@bt:/etc/ssh# ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
c9:c4:ab:02:42:0f:d4:96:91:35:78:0c:9b:48:1c:b7 root@bt
The key's randomart image is:

何回か質問されますが全部エンターでスルーしてください。
そうすると2つのファイルが出来上がる。
ssh_hostから始まるファイルが今回ssh-keygenで作成されたファイル


root@bt:/etc/ssh# ll
合計 28
drwxr-xr-x 2 root root 4096 2013-03-28 13:46 ./
drwxr-xr-x 146 root root 12288 2013-03-28 13:56 ../
-rw------- 1 root root 1671 2013-03-28 13:46 ssh_host_rsa_key
-rw-r--r-- 1 root root 389 2013-03-28 13:46 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root 2465 2013-03-28 13:45 sshd_config


ssh_host_rsa_keyは鯖が秘密鍵として持っておく。
ssh_host_rsa_key.pubは蔵が初回接続したときに取得し、公開鍵として蔵に保存される。
その時の蔵側のファイルは/root/.ssh/known_hostsとなる。
.pubとknown_hostsの中身を見ると「おー」ってなると思う。ってかなった。
※ここのknown_hostsは後で作成されます。

ここからは蔵側の操作
蔵側
SSH蔵サービスのインストール
# apt-get install openssh-client

ユーザ認証で使う認証キーを作成
# ssh-keygen -t rsa
鯖と同様に何回か聞かれます。
・認証キー保存場所　←エンター
・パスワード　←好きなパスワード
・パスワード再入力　←同じパスワード
root@hide:/etc/ssh# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
24:25:a6:78:88:eb:8f:ff:43:25:89:52:2f:41:72:13 root@hide
The key's randomart image is:

二つの認証キーが出来上がる。
root@hide:~/.ssh# ll
合計 16
drwx------ 2 root root 4096 3月 28 13:50 ./
drwx------ 15 root root 4096 3月 28 13:51 ../
-rw------- 1 root root 1766 3月 28 13:50 id_rsa
-rw-r--r-- 1 root root 391 3月 28 13:50 id_rsa.pub
root@hide:~/.ssh#


パーミッションの設定
これしないと怒られる。
# chmod 600 /root/.ssh/id_rsa

id_rsaは秘密鍵としてそのまま蔵においておく。
id_rsa.pubは共有鍵として鯖にscpやusbを使って移動させる。

ここからまた鯖側の操作
鯖側
蔵から持ってきたid_rsa.pubをauthorized_keysにリネームして/root/.ssh/に移動。
# mv id_rsa.pub /root/.ssh/authorized_keys

※既にauthorized_keysがある場合はリダイレクトで追記する。
# cat id_rsa.pub >> authorized_keys
間違っても>>を>にしないように気をつけてください。
めんどくさいことになります。

最後に蔵と同様にパーミッションの設定。
# chmod 600 /root/.ssh/authorized_keys
# chmod 600 /etc/ssh/ssh_host_rsa_key

念願のsshサービス開始
# service ssh start

蔵から接続
# ssh xxx.xxx.xxx.xxx
ここでさっき言ったknown_hostsが登場します。
初回接続時は鯖からホスト認証の公開鍵を引っ張ってきます。

The authenticity of host xxx.xxx.xxx.xxx can't be established.
RSA key fingerprint is xx:xx:xx........
Are you sure you want to continue connecting (yes/no)?
yesでエンターを押すと一度切られる。

再接続
# ssh xxx.xxx.xxx.xxx
Enter passphrase for key '/root/.ssh/id_rsa':
さっき入力したパスワードを入力してエンターでSSH接続完了


まとめ
とりあえずSSHの大雑把なフローはこんな感じかな？
１蔵から鯖へSSH接続の要求がくる。
この時蔵のknown_hostsと鯖のssh_host_rsa_keyを使って認証を行い、ホストが正しいことを証明。

２次に鯖が許可をしていい蔵か確認をする。
この時蔵のid_rsaと鯖のauthorized_keysを使って認証を行い、許可しているユーザであることを証明。

余談
結構外部から22番ポートへのアクセスがきます。
確認の方法はログを見てください。
# tail -f /var/log/auth.log

今回RSAをなぜ導入したかと言うと、中国からのブルートフォースアタックを受けてrootを
のっとられたためです。
始めて外部にたいしてポートを開けたときは「個人のIPだし大丈夫だろーHAHAHA」とか
甘い考えを持っていたんですがのっとられて初めてセキュリティに対する考えが変わりました。

みなさんも気をつけてください。

以上でつ。 ]]> https://ameblo.jp/h1debl0/entry-11499784455.html Thu, 28 Mar 2013 12:28:42 +0900