俺の日記帳　第二冊目

1 ：login:Penguin：2007/05/03(木) 12:29:53 ID:CbgoHqlv.net

批判は受け付けない。

411 ：カミナリ桃 ◆hzkudVaLnM ：2010/12/20(月) 00:33:53 ID:06Ck40yW.net

この前Ubuntu10.04でapparmor関連のパッケージが更新されたんだけど、
どうやらその後からaa-logprofをするとエラーがでる。

$ sudo aa-logprof
Reading log entries from /var/log/messages.
Updating AppArmor profiles in /etc/apparmor.d.
Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Immunix/SubDomain.pm line 2745, <$LOG> line 4.
Use of uninitialized value in split at /usr/share/perl5/Immunix/SubDomain.pm line 2748, <$LOG> line 4.
Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Immunix/SubDomain.pm line 2745, <$LOG> line 5.
Use of uninitialized value in split at /usr/share/perl5/Immunix/SubDomain.pm line 2748, <$LOG> line 5.
Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Immunix/SubDomain.pm line 2745, <$LOG> line 6.
Use of uninitialized value in split at /usr/share/perl5/Immunix/SubDomain.pm line 2748, <$LOG> line 6.
Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Immunix/SubDomain.pm line 2745, <$LOG> line 7.
Use of uninitialized value in split at /usr/share/perl5/Immunix/SubDomain.pm line 2748, <$LOG> line 7.
※以下、上記のエラーがひたすら繰り返し…

ちょっとUbuntuスレで質問してみるか…

412 ：今年のまとめ、その2/3：2010/12/20(月) 00:46:36 ID:j4rBj8iP.net

ループバックの許可は、"iptables -A OUTPUT -o lo -j ACCEPT"とすることが多いようだ（INPUTも）。
それを次のようにしてみた。
iptables -A OUTPUT -p all -o lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT （INPUTも同様に）

すると、icmpがマッチできなくなった。送信元や送信先アドレスが"127.0.0.1"ではないためだ。
許可には、あえて細かく書くと、例えば次のものが必要になる（発生頻度は非常に低い。）。
iptables -A OUTPUT -p icmp --icmp-type 3 -o lo -s $WAN_IP -d $WAN_IP -m state --state RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 3 -o lo -s $LAN_IP -d $LAN_IP -m state --state RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 3 -o lo -s $WAN_IP -d $CLIENT_IP -m state --state RELATED -j ACCEPT

また、PCルーターのeth1（LAN側）にクライアントがsshで接続中に、次のようなパケットが発生することがある。
iptables風に書くと、OUTPUT -o $WAN_IF -s $LAN_IP -d $SSH_CLIENT_IP --sport 22
"OUT=eth0"だが、"SRC=eth1のアドレス"になっている。ESTABLISHEDで、ネットワークの再起動時に発生する。

Linuxをさわり始めた頃は、インターフェイスとアドレスは必ず一致するものと思い込んでいた。
"OUT=eth0"なら"SRC=eth0のアドレス"というふうに。だが、実際には違った。
かといって、IPスプーフィングの発信元になるような許可はできない。

なぜ、インターフェイスとアドレスが一致しないのだろう。
そう疑問に思う一方で、上のloのような挙動は当然ではないのか？とも思う。
何にせよ、基本が理解できていないんでしょうな。

413 ：今年のまとめ、その3/3：2010/12/20(月) 00:52:07 ID:j4rBj8iP.net

その2/3にも出てきたicmpのtype3だが、そのステートフル性についても分かっていない。
icmpのtype3の受信で、INVALIDと判定されてしまうものがあるのだ。
（外部からのパケットのみ。その2/3に書いた、loがらみのものは全てRELATED。）

中継してくれたルーターからの返答が、ごく一部とはいえ、どうしてINVALIDとなるのだろう。
こちらにも原因があると思うのだが、分からない。
とりあえず今は、icmp（3・4・11・12番）はステートフル性を用いずに運用し、
他のもの、例えば、いきなりの0番はINVALIDで弾いている。

…と、発生頻度が低いので後回しにしたものの中から3つばかり。

おわりに
・週末たまにちょこっと弄る程度じゃ、1年かけてもこんな程度しか勉強できんかった。
　Linux自体初めてだし、しゃーないか。弄るのは楽しいからいいけど。
・type8に対するtype0がRELATEDでなくESTABLISHEDなのに気づいたときは、「へー」と思った。
　そりゃそうですよね。なんでRELATEDだと思ったんだろう。

414 ：カミナリ桃 ◆hzkudVaLnM ：2010/12/20(月) 01:07:28 ID:06Ck40yW.net

iptableかぁ…自分もよくわかってない（汗
>>400で百度のIPを弾いたんだけど、logwatch見てたらアイツらさらに別のIPから来てやがった。
ググる＆whoisで以下のIPが百度のものと判明。

119.63.192.0/24
119.63.193.0/24
119.63.194.0/24
119.63.195.0/24
119.63.196.0/24
119.63.197.0/24
119.63.198.0/24
119.63.199.0/24

早速ufwでdeny
sudo ufw deny from 119.63.192.0/24
※行数が多いので以下略

その後logwatchを見たところ…

Attempts to use known hacks by 3 hosts were logged 6 time(s) from:
150.70.75.166: 4 Time(s)
119.63.198.123: 1 Time(s)
119.63.198.89: 1 Time(s)
A total of 3 sites probed the server
119.63.198.123
119.63.198.89
150.70.75.166

あれ？deny出来てなくね？
※なお、150.70.75.166は日本のトレンドマイクロのスパイダーです。
　logwatchに自動的にhack扱いされる凄いスパイダーだよ。

415 ：カミナリ桃 ◆hzkudVaLnM ：2010/12/20(月) 01:15:43 ID:06Ck40yW.net

うちはiptableじゃなくてufw使ってる。
結局中身は一緒っつーかufwはiptableのラッパーらしい。
現在かけているufwは↓
----
sudo ufw default deny incoming
sudo ufw allow from ※自宅IP to any port ※ssh
sudo ufw allow Apache
# baidu
sudo ufw deny from 119.63.192.0/24
sudo ufw deny from 119.63.193.0/24
sudo ufw deny from 119.63.194.0/24
sudo ufw deny from 119.63.195.0/24
sudo ufw deny from 119.63.196.0/24
sudo ufw deny from 119.63.197.0/24
sudo ufw deny from 119.63.198.0/24
sudo ufw deny from 119.63.199.0/24
----

どっかのサイトで「ufwとiptableはかける順序が違う部分があるから注意」みたいなのを読んだんだが、どこだったか失念。
英語読めんとmanが読めないので涙目。
頑張ってufwの情報探すか、それとも.htaccessで逃げるか…はぁ

416 ：カミナリ桃 ◆hzkudVaLnM ：2010/12/20(月) 01:33:26 ID:06Ck40yW.net

ググり直したらufwの順序に関する情報見つかった＞＜
http://gihyo.jp/admin/serial/01/ubuntu-recipe/0077?skip

↑の情報を元にufwの設定を書き直し
----
sudo ufw default deny incoming
sudo ufw allow from ※自宅IP to any port ※ssh

## apache
# baidu deny
sudo ufw deny from 119.63.192.0/24
sudo ufw deny from 119.63.193.0/24
sudo ufw deny from 119.63.194.0/24
sudo ufw deny from 119.63.195.0/24
sudo ufw deny from 119.63.196.0/24
sudo ufw deny from 119.63.197.0/24
sudo ufw deny from 119.63.198.0/24
sudo ufw deny from 119.63.199.0/24

# apache allow
sudo ufw allow Apache
----

これで上手くいってくれ〜＞＜

417 ：デムパゆんゆん＠冬眠前線炎上中：2010/12/31(金) 03:00:11 ID:T8Q0RGRv.net

>>398
そういうのはiptableでやるもんじゃないのか？
baidu.jpではじく書式もあったような記憶あるけど
host.denyは基本全部拒否だろ多分
必要なものだけ開ける
侵入されたりトラブルが起きたときの障害切り分けの負担を減らす

>>409
http://www.atmarkit.co.jp/flinux/rensai/security05/security05a.html

>>411
答え返って来た？

418 ：デムパゆんゆん＠冬眠前線炎上中：2010/12/31(金) 03:04:17 ID:T8Q0RGRv.net

>>412
icmpは必要か？
普段はコメントアウトして
#iptables -A OUTPUT -p icmp --icmp-type 3 -o lo -s $WAN_IP -d $WAN_IP -m state --state RELATED -j ACCEPT
#iptables -A OUTPUT -p icmp --icmp-type 3 -o lo -s $LAN_IP -d $LAN_IP -m state --state RELATED -j ACCEPT
#iptables -A OUTPUT -p icmp --icmp-type 3 -o lo -s $WAN_IP -d $CLIENT_IP -m state --state RELATED -j ACCEPT

必要な時だけsshから繋いで#消して
iptables reloadしてから icmp有効にするとかはダメなのか？

＞なぜ、インターフェイスとアドレスが一致しないのだろう。
centosでもよく言われるが　NetworkManagerでインターネットに繋いでるんじゃないのか？
NetworkManagerを無効化
http://netlog.jpn.org/r271-635/2009/06/ubuntu_81networkmanager.html
記事が古いからあとは自分で確認して
CentOS　だと
service NetworkManager stop
service network start

vi /etc/sysconfig/network-scripts/ifcfg-eth0で
IPADDR=192.168.0.X
HWADDR=xx:xx:xx:xx:xx:xx # xx:xx:xx:xx:xx:xxにはNICのMACアドレスを設定

でIPアドレスとNICを固定させる　たしかこれで固定できた
うぶんちゅも似たような設定で出来たと思う

https://wiki.ubuntulinux.jp/UbuntuTips/DedicatedServer/OverSSHbyDebootstrap

419 ：login:Penguin：2010/12/31(金) 17:52:04 ID:3dAmzO86.net

>>418 レスありがとうございます。
> icmpは必要か？
いえ、icmpが必要かどうかではなく、"iptables -A OUTPUT -o lo -j ACCEPT"の時と同じにするためには、
以下のようなものが必要になる、という事を述べただけです（汗。

> centosでもよく言われるが　NetworkManagerでインターネットに繋いでるんじゃないのか？
いいえ、使っていません。
eth0とeth1が入れ替わるような事態も経験ありません。

>>412で言いたかったのは、「"-o lo"なのに"-s 127.0.0.1"ではない」、
「"OUT=eth0"なのに"SRC=eth0のアドレス"ではない」ことがあるが、何故だろう？ということです。
すいません、書きようが悪くて。

「Linuxをさわり始めた頃は、インターフェイスとアドレスは必ず一致するものと思い込んでいた。」
「なぜ、インターフェイスとアドレスが一致しないのだろう。」
これらの表現が間違ってますねorz。はしょりすぎです。

「『"SRC="に記されるアドレス』は、『"OUT="に記されるインターフェイスのアドレス』と必ず一致するものと思い込んでいた。」
「なぜ、"SRC="に記されるアドレスが、"OUT="に記されるインターフェイスのものと一致しないのだろう。」
と、それぞれ書くべきでした。
eth1のアドレスは変化せず、常に固定です。
eth0のアドレスはdhcpクライアントによって、ネットワーク再起動時に再取得されるので、固定ではありません。
（eth1のアドレスが振られるようなこともありません。）

ただ、発生頻度でも触れましたが、かなり特殊な状況なのだろう？と思っています。
とくに後者は「ESTABLISHEDで、ネットワークの再起動時に発生する。」と書きましたが、
言い換えると、ssh接続中にネットワークを再起動させない限り発生しません。

eth1とクライアントPCとのssh接続は、ネットワークの再起動後も継続されます。
（ネットワークを再起動させているので、実際には一旦切れているのでしょうが。）

420 ：419：2010/12/31(金) 18:16:40 ID:3dAmzO86.net

> また、PCルーターのeth1（LAN側）にクライアントがsshで接続中に、次のようなパケットが発生することがある。
> iptables風に書くと、OUTPUT -o $WAN_IF -s $LAN_IP -d $SSH_CLIENT_IP --sport 22
> "OUT=eth0"だが、"SRC=eth1のアドレス"になっている。ESTABLISHEDで、ネットワークの再起動時に発生する。
これなんですが、
ssh接続中にネットワークを再起動させてますから、一旦接続は切れているでしょう。
そこで、sshサーバーが一度見失ったクライアントをあちこち捜している。
だから、"-s $LAN_IP -d $SSH_CLIENT_IP --sport 22"なパケットを、全てのethから飛ばしているのでは？

…などと妄想しています。もちろん、"OUT=eth0"はDROPしています。


「"SRC="に記されるアドレスが、"OUT="に記されるインターフェイスのものと一致しない」例をもう一つ。
最近見つけました。試しに実験したら、思い通りでした。

[IPTABLES BAD_IP] : IN= OUT=eth1 SRC=eth0のアドレス DST=クライアントPCのアドレス LEN=60 TOS=0x00 PREC=0x00
TTL=64 ID=3159 PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=3840

見ての通り、pingの返答です。ESTABLISHEDなパケットですが、
一致しないOUTPUTはBAD_IPチェインで弾いているので、このログが残ります。
eth1側にぶら下がっているクライアントPCが、eth0に対してpingを打ったときのものです。

eth0がクライアントPCに返事をするためには、eth1を通るしかありませんから、
これはこれで当然なのだろうと考えてます。

長文失礼しました。