【鉄壁】iptablesの使い方 3【ファイアウォール】

【鉄壁】iptablesの使 ..

666:login:Penguin
08/11/02 15:14:37 fqVxYuim
>>664
-i $INTIF 取ってみな

667:login:Penguin
08/11/02 15:51:43 fqVxYuim
>>658
あと追記だけど、LAN1/LAN2側双方へのマスカレードの設定があと必要だとおもうよ。
このくらい自分でしらべてくれよん

668:login:Penguin
08/11/07 15:57:30 TIV9E6l7
ルーター(192.168.0.1)
↓
eth0┐(192.168.0.2)
　　　│←pc0
　　　│
eth1┘(192.168.1.1)
↓
pc1

iptables -A FORWARD -i eth1 -o eth0 -s 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE

pc1にインターネット共有をさせたくて上記のように設定してみましたが
だめでした
これだとpc0のWAN側がインターネットでないとダメなのかなとか
ひょっとしてできないのかなでもWindowsだとチェックボックスひとつで
共有できるしなあとか思ってはみるものの具体策がわかりません
おしえてください

669:login:Penguin
08/11/07 16:39:12 CnNNPz2n
pc1 は ip_forward してますか？

670:login:Penguin
08/11/07 16:39:43 CnNNPz2n
ごめん、pc0 は ip_forward してますか？

671:login:Penguin
08/11/07 20:21:24 TIV9E6l7
>>670
/proc/sys/net/ipv4/ip_forward
に1とあり大丈夫なようです

672:login:Penguin
08/11/07 21:48:58 lFnUHJKa
>>668
というか「ルータ」に192.168.1.0/24のスタティックルートを設定できないのか？

673:login:Penguin
08/11/08 00:50:25 hssA2L52
前提としてルーター（192.168.0.1）には、もう一個ポートがあって、インターネット(ISP)に繋がっている。
ということでＯＫ？
で、そのルーターは当然のごとくにIP Masquarade(NAT)している、ということでＯＫ？
で、やりたいことは、ローカルネットワークにNATルーター(pc0)を設置してpc1は二重にNATしたい、ということでＯＫ？

pc1をインターネットに繋がるようにしたいだけなら 192.168.0.0/24 のアドレスにしてpc0のeth0と同じ側に繋ぐか、
672 の言うとおり pc0 を(NATしない)普通のルーターとして働かせれば、いいはずだが、それを敢えて二重に
NATしたい、と。

他に -j DROP なルールなどががあったりしなければ、668の設定で基本的にはいいはずだけど、
その前にpc0からはインターネットにルーター(192.168.0.1)経由で繋がるのか？

674:login:Penguin
08/11/08 01:41:09 MJgV0EtY
restartしてないだけというエスパー予想。

675:667
08/11/08 20:06:18 0iWj6iOE
>>668

#WAN側のアドレスとか差っぴいちゃうからアドレスの指定とかやらないほうがいい
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j DROP
#↓WAN出力側は、マスカレードを無条件に許可する
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#↓LAN側から入ってきたソースだけをpc1への戻りアドレス書き換えるマスカレード
#ローカルサーバーが必要ないなら、こいつは別に要らないかな？
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j MASQUERADE

で、逝けそうな気がするけど。

それから、/etc/network/options に次の記述があるか確認してみ
ip_forward=yes

676:667
08/11/08 20:09:41 0iWj6iOE
訂正： >>668 の図見ると、eth0 eth1 逆じゃん？

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j DROP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j MASQUERADE

てところか

677:667
08/11/08 20:14:24 0iWj6iOE
WAN側からの接続をシャットアウトしたいんだっけ？
勘違いしてた。

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
#↓この行だけ違った
iptables -A FORWARD -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j DROP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j MASQUERADE

678:667
08/11/08 20:27:54 0iWj6iOE
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j DROP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j MASQUERADE
なんか、このほうがスッキリするけど…。

679:667
08/11/08 20:34:22 0iWj6iOE
>>668 をまとめるとこんな感じだな
よくわからないか、まとめてみた。

1) WANへの接続は許す
2) WANからの接続は潰す
3) ただし、LANからWANへ接続済みにしたパケットのWAN側からの転送は許す

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j DROP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j MASQUERADE

680:667
08/11/08 20:38:58 0iWj6iOE

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
#↓ FORWARD に -o 張れないからやっぱこれでいいはず…
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -j DROP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.0.0/16 -j MASQUERADE

681:login:Penguin
08/11/08 23:10:35 iMsDtzmC
>>680
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
これは余計じゃないかな。

>>668
それとip_conntrack モジュールはロードしている

682:667
08/11/09 07:45:30 cyMfQhQp
>>681
余計かなぁ…？
ルーターとPC１が別のアドレス空間になっているから
PC0用のアドレスに書き換えてやらないとパケット戻ってこない気がするけど

683:login:Penguin
08/11/09 13:35:21 uYzy9N5y
668のやりたいことが>>673の問いかけ通り（最初の4行通り）なら、
673の指摘通り668の記述であっている（NATも以下の一つでいい）。
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE

実際、最初の4行に書かれている通りのことを今やっている。
違いはeth0を固定IPにしているので、MASQUERADEでなくSNATを使ってることぐらい。
うまくいかない原因は、668に記載された3行以外にあると思うのだが？

684:667
08/11/09 14:02:18 MyRkucom
なーるー

原因不明だな

全部のiptablesオプションに --modprobe=/sbin/modprobe 付け足して
呼んでみるとかやってみるべきかもね

それでもダメなら pc0 に pc1 から ping して応答が帰ってくるかどうか
ぐらいのレベルから検証してみたほうがよさそうだね。

685:login:Penguin
08/11/10 22:31:41 vjcGauLJ
eth0を物理１つのエイリアス2に区切りました。
eth0 192.168.0.10
eth0:0 192.168.0.11
eth0:1 192.168.0.12

.0.10にだけtelnetが繋がるようにするには
どうすればいいのでしょうか？

686:login:Penguin
08/11/11 02:07:43 lioaoJiT
IPエイリアスの場合、全部eth0に変わりないので

-A INPUT -i eth0 -d 192.168.0.10 --dport 23 -j ACCEPT
-A INPUT -i eth0 --dport 23 -j REJECT

こんな感じじゃない

687:login:Penguin
08/11/13 19:57:50 zJ0w7PDt
telnetにListenIP設定すれば？
絞るなら大本から絞れ

688:login:Penguin
08/11/14 17:28:14 FovMWI9O
>>687
こういうのって(iptablesとデーモンの)両方やらないか？

689:login:Penguin
08/11/14 20:11:16 4rtpLX5i
ポートを開けないようにアプリ（telnet）側でやり、
さらにうっかり開かないようにiptablesで縛るね。

片方だけだと「うっかり」が結構出るけど、両方とも独立に
設定するならオペミスで開いてしまう事故は非常に起こりにくくなる。

690:login:Penguin
08/11/15 01:42:42 Zo/JTpVo
ssh+鍵暗号でいいやん
telnet 殺しちゃいなよ

691:login:Penguin
08/11/15 02:14:20 26XJ0s7F
ここでの telnet はあくまで例なんじゃないの？

692:login:Penguin
08/11/15 08:53:49 OWM1nEoc
それやるとミスもあるんだよな。wrapperではじいてるから
後でFW設定しようとか思ってたら一台だけ設定してなかった、とか。

693:login:Penguin
08/11/15 09:18:53 4Owtonid
後でやろうと思ったとか、ちゃんと手順にそってやったことを確認しながらやらないのは問題外
ヒューマンエラーを防止するために手順メモとチェックリストは個人的にでも作ったほうがいい。

まあ、より強固で確かな方から設定していった方が漏れがあった時被害が少ないかもな…。

694:login:Penguin
08/11/15 13:00:17 OWM1nEoc
実際はもうちょっと複雑な過程ではまるんだが、ちと面倒だったんで……
あとはAの方ではじいてると思ってそっちのルール更新してたらBだった、とか。

695:login:Penguin
08/11/18 00:18:36 ruHhaDcu
ubuntuのufwで出力されるiptablesのルールって誰か分かりますか？
あれってデスクトップ用に最適化されているんですかね？

696:login:Penguin
08/11/18 00:24:59 jDfQIBNa
2.4 系だと MANGLE に TCPMSS 張れないから
FORWARD と OUTPUT に張っているけど
MANGLE に張る場合となにが違うのかよくわからん

697:login:Penguin
08/11/18 04:32:57 d3c/lwkM
>>695

設定してシェルから
iptables -L -v
してみれば良いのでは？
ていうかして、参考にしたいから。
自分はknoppix firewallと同じルールにしているけど、ubuntuのやつも
見てみたい。

698:login:Penguin
08/11/18 10:14:23 MRSXpnk2
>>697
いや、自分も手元にubuntu環境ないから見てみたいのですよ

699:login:Penguin
08/11/18 10:17:31 MRSXpnk2
あ、ubuntuライブCDが手元にあったわ
ufw enable　して　iptables -L -v　見てみる

700:544
08/11/24 21:48:01 qB2Gxz8P
NIC二枚刺して、一方はLANを通ってLAN内のルーターから外に
もう一方はグローバルIP持ってて直接外に
　　 |-eth0(192.168.0.102)-ルーター-インターネット
PC-|
　　 |-eth1(211.4.228.10)-インターネット
こんな構成になってるんだけど
eth0からインターネットに送信するときにeth1のIPアドレスがソースアドレスになっちゃいます。
eth0からLAN内にはちゃんと192.168.0.102がソースアドレスになります。

とりあえずiptables -A POSTROUTING -t nat -o eth0 -j SNAT --to-source 192.168.0.102
として、ソースアドレス設定してるですけど
tcpdumpで見てみるとDNSとかeth1のアドレスで尋ねにいってタイムアウトしてます。

そもそも、ifconfig見るとちゃんとeth0にIPアドレス設定されてるのに、なんでSNATが必要になるんでしょうか？
SNATしなくても済む方法ありますか？

701:700
08/11/24 21:56:04 qB2Gxz8P
追加です。
ping 66.249.89.99 -I eth0
とかすると、ソースアドレスはeth0のアドレスになってて問題なくpingは通ります。

702:login:Penguin
08/11/25 01:17:36 zZh6AovX
・IPv4
・マルチホームホスト
・デフォルトゲートウェイ2つ
・ポリシールーティングなし
が条件かな？

この場合、
・ルーティングエントリは、送出先インターフェースに関連づけられる。
・IPアドレスは、インターフェースに関連づけられる(が、他のインターフェース経由で送出されても良い)
・IPアドレスとルーティングエントリを直接関連づける機構がない。
・2つのデフォルトゲートウェイのうちどちらが使われるかは、メトリックによって決まる。値が同じなら平等。
みたいなかんじ。

IPアドレスと同じサブネットにいるゲートウェイが必ず使われるという保証はない、と言う状況になると思う。

解決策は、今のようにSNATをかけるか、ポリシールーティングで厳密にルーティングを指定するか、だと思うが。

703:700=544
08/11/25 18:33:11 +bzr+l5D
>>702
レスサンクスです
ポリシールーティングなのかわからないんだけど
>>544にあるように、UIDによってルーティングテーブルを分けてます。
mainテーブルはeth1がデフォルトになってて、
一部のユーザーはテーブル2を見て、eth0に振られます。
>>700の現象が起きるのはそのユーザーのみです。後出しですいません。
tcpdump見てると、domainのみeth1のアドレスでまず送って、その後eth0のアドレスで送ってます。
>>544で言ってた遅さの原因は最初のDNS問い合わせがタイムアウトしてるからのようです。

>・IPアドレスは、インターフェースに関連づけられる(が、他のインターフェース経由で送出されても良い)
ここを厳密にインターフェースに関連付けられればいいんですけど、SNATしかないんでしょうか？

704:700=544
08/11/25 18:34:16 +bzr+l5D
ipコマンドの結果とiptablesの一部載せます
# ip rule list
0: from all lookup 255
100: from 192.168.0.102 lookup 2
101: from all fwmark 0xb lookup 2
32766: from all lookup main
32767: from all lookup default

# ip route show table 2
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.102
default via 192.168.0.1 dev eth0 src 192.168.0.102

# ip route show table main
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.102
211.4.228.0/24 dev eth1 proto kernel scope link src 211.4.228.10
default via 211.4.228.1 dev eth1

# iptables -L -t mangle
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere anywhere MARK set 0xa
MARK all -- anywhere anywhere OWNER UID match serv1 MARK set 0xb

705:700
08/11/25 19:15:43 +bzr+l5D
自分でも混乱してきたのでまとめ

table2を見てる特別ユーザーの場合
>>704の状態
ソースアドレスがeth1のアドレスになってしまって通信不可

>>704に加えてSNAT
基本的にソースアドレスはSNATで指定したアドレスになり通信できるが
DNSのみeth1のアドレスで問い合わせ後、SNAT指定のアドレスで問い合わせるので遅くなる。

706:login:Penguin
08/12/25 14:38:37 W3gIymfl
>>666
亀ですんません
-i $INTIF取ってもダメでした
結局、-s ! $OREIPで凌いでます

707:login:Penguin
08/12/26 00:11:11 VXirjz6Y
今さっき、単純なポリシールーティング(fwmark未使用)なら動いたけど・・・・
なんか、自分のよりずいぶんややこしいことやってるな

708:700
08/12/26 18:06:08 ltPqHwfd
やりたいことは単純で、ユーザー毎に使うネットワークを分けたいだけなんですけどね。
宛先のみでは分けれないので静的なルーティングでは実現できず、fwmark使うしか思いつかなかったんです。

709:login:Penguin
08/12/27 00:08:55 opgamkt1
既に理解しているようならスルーしてくれ。

まず、linuxのポリシールーティングがどういうものかというと、
「ルーティングテーブルを複数持って、条件によって使うテーブルを切り替える」
機構になってる。

これは、普段使うmainテーブルを複数持つような物だと思えばいい。
つまり、切り替えたテーブルにおいて、ネットワークの定義等が無いと、そのネットワーク等は使えない。

通常、mainテーブルが
$network1 dev $if1 　scope link 　src $ip1
$network2 dev $if2 　scope link 　src $ip2
127.0.0.0/8 dev lo 　scope link
default via $gw1 dev $if1
のようになり、
これとほぼ同じものを、切り替え用のテーブルとして用意する
(127.0.0.0/8 も、テーブルごとに用意した方がいい)

また、アプリケーション側でソケットを作成する際に、
local側をbindして、bindしたアドレスと別のネットワークに飛ばそうとすると
当然の如く、ネットワークを跨ぐことができず、ルーティングに失敗する。
(ip_forward=1にすれば超えれるのかな？)

bindをanyにした場合は、送信先に対応するネットワークをルーティングテーブルから選択して、
そのテーブルに書かれているIPアドレスorデバイスをlocalのbindとする。

どうやって調べるかという話はあるにしろ、どこが問題なのかはっきりさせた方がいい気がする。

#完全にiptablesの話じゃないな

710:700
08/12/27 00:58:36 jUvzXagD
自分でsocketから書けばbindでIPアドレス指定することで
ルーティングで小細工しなくてもNICを使い分けれるんですね。知らなかった。

でもwgetとか普通のクライアントアプリならbindとか呼ばず、いきなりconnectじゃないですか？
そういう場合ってどうやってソースアドレス決定するんでしょう？
ルーティングテーブルでローカルネットワーク使うように設定しても(>>704のtable2)
ソースアドレスがグローバルIPになっちゃうんですよね。

##完全にiptablesの話じゃないな
#たしかに。板違いかも。

711:login:Penguin
08/12/27 07:35:52 opgamkt1
いや、ポリシールーティングの設定はいる。
けど、fwmark使わずに、ソースアドレスでテーブルを振り分ける。

echo "127 net1" >> /etc/iproute2/rt_tables
echo "126 net2" >> /etc/iproute2/rt_tables

ip route add $network1 dev $if1 　scope link 　src $ip1 table net1
ip route add $network2 dev $if2 　scope link 　table net1
ip route 127.0.0.0/8 dev lo 　scope link table net1
ip route default via $gw1 dev $if1 table net1

ip route $network2 dev $if2 　scope link 　src $ip2 table net2
ip route $network1 dev $if1 　scope link 　table net2
ip route 127.0.0.0/8 dev lo 　scope link table net2
ip route default via $gw2 dev $if2 table net2

ip rule add from $ip1 table net1 prio 14998
ip rule add from $ip2 table net2 prio 14999

いわゆる、参考文献でよく見る基本形
・localのbindによって、gw1とgw2を振り分ける。
・localのbindがanyの場合は、mainテーブルのdefault gatewayによってlocalのbindが確定する
・listenしているソケットがanyの場合は、acceptしてlocal側のbindが確定した段階で、
　出力先のネットワークが確定する。つまり、受け取ったif側のgwが使用される
・wgetにはbindaddress指定があるので、
　wget --bind-address=${ip1} URLﾘﾝｸ(hogehoge)<)　ではgw2
　wget URLﾘﾝｸ(hogehoge)　ではmainテーブルで指定したgw
　に向かってパケットが投げられる

712:login:Penguin
08/12/27 07:44:29 opgamkt1
IP通信の基本として、パケットには自分のIPアドレスが含まれる。（無いと通信できない）
srcIPとdstIPが別のnetworkになる場合、ルーティングを行う必要がある。
つまり、localのbindが${ip1}の状態で、$gw2に投げようとする時点で、ルーティングが必要になる。

localのbindが確定した段階で、別のgwに投げようとしても、localでroutingしない限り届かない。

>>700 の場合
アプリケーションが起動して、localのbindをanyでsocket作成
通信先を決定時に、local側IPアドレスをmainテーブルを元に生成(eth1のIPアドレス)
ルーティングテーブル選択ルールで、table 2を選択して、パケットを送出（211.4.228.0/24のネットワークの定義が無いので投げられない)
という動作になっているんじゃないかなー

多分、anyのbindがmainテーブル参照でsrcIP決定になるというのが、想定外の動作なのではないかと。
（なので、条件によって使用される他のテーブルにも、mainテーブル相当の内容を入れておくことが推奨される)

713:login:Penguin
08/12/27 12:23:31 itSOO7pC
スレ違いになるけどIP配布するときにゲートウェイをMACアドレスの
グループごとに変えるとかじゃ、だめなのかな。セキュリティの問題で
分けてるんだとすると、だめだが……

714:700
08/12/27 19:04:19 jUvzXagD
>>711
wgetにはbindの設定がありましたか。さすがwgetですね。wgetは例として悪かったです。
実際使いたいのはperlのLWP::UserAgentなんですけど、bindアドレスの設定はなさそうです。

>>712
パケットを生成するためにはsrcIPが必要で、ルート決定にはパケットが必要なんですね？
今自分がやろうとしてる、ルートによってsrcIP決定するという考え方が間違ってるんですね。
>>700ではsrcIPをmainから仮決定しているのでSNATで修正する必要があるのは当然だと。
ちなみに>>704の場合、一応パケットは送出されてます。でもsrcIPが間違ってるのでルーターに遮断されてると思われます。

>（なので、条件によって使用される他のテーブルにも、mainテーブル相当の内容を入れておくことが推奨される)
そうすると、srcIPが間違ってる限り、どのテーブル使ってもmainと同じルーティングになってしまいませんか？

715:login:Penguin
08/12/28 11:07:42 em+fhSry
スルー推奨

716:login:Penguin
09/01/16 16:01:57 okJnBqgJ
2008年12月　攻撃元国別ランキング
《1位》韓国(78.1%)
《2位》アメリカ(5.4%)
《3位》中国(2.5%)
《4位》サウジアラビア(2.1%)
《5位》台湾(中華民国)(1.5%)

URLﾘﾝｸ(www.security.ocn.ne.jp)

717:login:Penguin
09/01/16 16:06:20 u7wlazQY
>>716
これは韓国ネチズンvs 2ちゃんねらーのせいじゃないかな。でないと偏りが大きすぎるw

718:login:Penguin
09/01/16 16:46:44 +DlK6TCr
迷惑な話だ（笑 vipper専用の回線でも引いてそこでやってほしい

719:login:Penguin
09/01/16 22:24:37 Qy3jFgAJ
DebianでfirestarterのGUIを最小化自動起動させている方いらっしゃいませんか？

URLﾘﾝｸ(www.fs-security.com)
上記サイトに書いてあるようにしたのですが、ログイン後通知パネルに自動起動しません
/etc/sudoersに

username ALL= NOPASSWD: /usr/bin/firestarter

Note: Debian users should replace /usr/bin/firestarter with /usr/sbin/firestarter in the above line.
↑のように追記したのですがやっぱりダメです
セッションの自動起動するプログラムにも書いてある通り追加しました
どなたか成功している方いらっしゃいませんか？
firestarterのバージョンは1.0.3-1.3です
よろしくお願いしますm(_*_)m

720:login:Penguin
09/01/16 22:29:09 VaS+Z9mp
>>719
usernameのところをちゃんと自分のユーザー名にした？
firestarterの場所はちゃんと合ってる？
端末でsudoとかsuとかせずにfirestarterと打って起動出来る？

721:719
09/01/17 16:22:18 98qqdXhI
>>720
usernameは自分のユーザー名にしました
firestarterの場所は/usr/sbin/firestarterにしました
sudoとかsuせずに起動できません

722:login:Penguin
09/01/17 18:08:23 lpCkIAcT
>>721
ごめん間違った。
sudo firestarterでパスワード要求されずに起動できる？
セッションにはsudo firestarterで登録ね。

723:719
09/01/17 18:36:18 98qqdXhI
>>722
セッションへの登録の仕方が間違ってました
自動起動時の最小化はできませんでしたが、通常モードで起動することはできました
本当にありがとう

724:719
09/01/17 19:05:29 98qqdXhI
>>722
--start-hidden
↑を付加して最小化もできました…orz

725:login:Penguin
09/01/23 08:14:33 GeOEI94J
こんなのみつけた
コメントもついてて、大元になるスクリプトをジェネレートしてくれるみたい
これを少しづつ買えていけばいいじゃないかな。パスとかルールとか
URLﾘﾝｸ(easyfwgen.morizot.net)

726:login:Penguin
09/01/30 16:53:34 037qY2Hb
最近namedに
72.20.3.82#35022: query: . IN NS +
のような連続攻撃がバンバン来る。
そこで同一IPアドレスから一定数以上の53/UDPパケットが来たらiptablesで叩き落としたい。
ところが…　recentモジュールはTCP専用だったのね。知らなかった。orz
UDPでrecentモジュールと同様のことをするにはどうすれば良いのでしょう？

727:726
09/01/30 17:02:36 037qY2Hb
因にUDPでrecentモジュールを実験してみたら、見事に誤作動。
一つのIPアドレスがhitcountに達したら、全部のIPアドレスがDROPされてしまいました。orz

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m recent --set --name domain --rsource
-A INPUT -p udp -m udp --dport 53 -m recent --name domain --rcheck --seconds 300 --hitcount 50 --rsource -j LOG
-A INPUT -p udp -m udp --dport 53 -m recent --name domain --rcheck --seconds 300 --hitcount 50 --rsource -j DROP
-A INPUT -p udp -m udp --dport 53 -j ACCEPT

728:login:Penguin
09/01/30 18:17:17 Pcr9wMdL
適当なこというけど hashlimit は？

729:login:Penguin
09/01/30 21:25:17 YBChhxZr
>>726
というかbindのACLで不正な問い合わせには応答しなきゃいいじゃないか。
仮にiptablesでやったとしてもパケットがやってきてしまうことは
どうしても防げないわけだし。

730:login:Penguin
09/01/31 02:54:59 asn696XI
bindのDDoSはどんどんひどくなってるみたいね。
とりあえずはbindのほうをいじったほうが、確かに早いかも分からん。
スレ的にはiptableで簡潔ないい記述ができればいんだが。

731:726
09/01/31 16:55:12 CmZY/+bL
BINDは対策済なんだけど、これだけでは偽装された発信元IPアドレスに（短い）パケットを返してしまう。
iptablesで叩き落とせばこのバックスキャッタリングを防げる。
上手い方法ないかなあ。

732:login:Penguin
09/01/31 17:01:03 asn696XI
blackholeとかメンテナンスするのいやだからなぁ。
ルールベースで切りたいな確かに。

733:login:Penguin
09/01/31 22:58:57 asn696XI
しかしひどいね。blasterが流行ったときみたいだな。

734:login:Penguin
09/02/01 06:17:02 EdoXH2sU
BINDは設計がおかしいから、もうどうにもならん

735:login:Penguin
09/02/01 10:27:09 pLJq1zgT
だれか海外サイトから設定をかっぱらって来るんだ

736:login:Penguin
09/02/02 09:48:50 +Az43133
URLﾘﾝｸ(lists.dns-oarc.net)

DNSオペレータのMLに出ていたラインで、通技板に転載がありました。

737:login:Penguin
09/02/02 11:30:57 4AWynPNf
u32モジュールってなんだ!?
こんなの初めて見た

738:login:Penguin
09/02/02 12:04:46 +Az43133
俺も初めて使った。最近のkernel/iptablesじゃないとダメみたいね。
あと at ってなってるところは@に置換ね。

739:login:Penguin
09/02/02 12:07:52 +Az43133
ただこれ、すごい単純なマッチングだからアタックの問い合わせにいろんなのが
出てきたら、ダメだな。よく見てるとランダムな文字列のDDoSもあるから、そういうのには
上の人みたいに時系列で追うルールじゃないと対応できない、たぶん。

740:login:Penguin
09/02/02 13:24:16 pp7sQ9oB
うちには「.」だけじゃなく「se」の攻撃も来てる。

741:login:Penguin
09/02/02 17:41:07 pp7sQ9oB
>>728
hashlimitはudpで使えるの？

742:login:Penguin
09/02/04 17:19:46 DRq4jnVW
recentの場合は一度hitcountに達すれば攻撃が続く限り全部DROPできる。
これに対してhashlimitの場合は攻撃が続いている間、攻撃の一部を受け入れてしまう。
という理解で正しい？

743:login:Penguin
09/02/05 07:35:29 zryjGLFD
UDPの場合はipアドレス偽装しても困らないんだから
hashlimitは全く役に立たないと思うんだが。

744:login:Penguin
09/02/05 09:10:03 k3yyhcPH
>>743
TCPもSYNに限ってはアドレスを偽装できるので、
アドレス偽装対策としての確実性を求めるべきではない罠。

745:login:Penguin
09/02/05 12:05:09 HWvjHGlG
namedのログを見ると、実際には同じ発信元IPアドレスが繰り返し使われている。
何故かというと、namedは攻撃の踏台に使われているだけだから。
本当の攻撃対象のIPアドレスを発信元に偽装して、世界中のnamedに問い合わせをバラまく。
namedの応答を悪用することで攻撃のトラヒックを何倍にも増幅することができるから。

746:login:Penguin
09/02/05 18:54:59 8g5FEuSC
結局あれをやってる連中の意図はそういうことなのかな。
となるとやっぱり律儀に返事を返すのは、どうしても
連中の思ったとおりのことをやってしまうことになるね。

あまり本来の設計にない動作はさせたくないが、しょうがないなこれは。

747:login:Penguin
09/02/05 23:35:52 zryjGLFD
DRDoSを調べようとしてもDR-DOSばかりヒットするのは困ったものだな・・

748:login:Penguin
09/02/05 23:39:35 dEMHjHJ3
>>747
DRDoS -DR-DOS でググる

749:login:Penguin
09/02/06 09:58:40 EQF4KdkV
直接iptablesというわけではないのですが質問です。

ある特定のISPユーザにしかサービスを許可したくない場合等
ドメイン名で制限を書けたい場合にはどのようにするのが一般的でしょうか？
(IPアドレス帯域を公開していたりTCP Wrappersが対応していればカンタンなのですが)

750:login:Penguin
09/02/06 12:32:44 KaLnvoCv
安易な対策としてzone "."にallow-query { 127.0.0.1; };を書き加えてみたけど、拒否されますた。orz

Feb 6 12:25:21 ***** named[26734]: loading configuration from '/etc/named.conf'
Feb 6 12:25:21 ***** named[26734]: /etc/named.conf:23: option 'allow-query' is not allowed in 'hint' zone '.'
Feb 6 12:25:21 ***** named[26734]: loading configuration: failure
Feb 6 12:25:21 ***** named[26734]: exiting (due to fatal error)

751:login:Penguin
09/02/06 21:14:56 xQ6autwt
optionsに127.0.0.1とローカルのIPだけ許可する設定を書けばいいよ。
公開してるゾーンだけanyに許可。

752:login:Penguin
09/02/06 22:03:16 JpTPB05X
>>749
DNSでアドレスから名前を逆引きして判別 (さらにsecureにしたい場合は、
確認できたホスト名をアドレスに再変換してチェック) とか。

753:login:Penguin
09/02/13 16:23:01 e2K4rCg5
BIND 9.4からnamed.confの仕様が変更になっていたのね。
allow-queryが効かなくてハマった…。

754:login:Penguin
09/02/13 23:59:00 owjgCdcY
省略せずに、ちゃんと明記すればいいんだっけか
google様でわからなかったら苦労しそうなパターンだよなぁ

755:login:Penguin
09/02/17 13:00:46 WbA+0bN2
MythwebでwebからTVの録画や視聴をしようと思い、念のため外からの接続はSSL経由で
クライアント認証にしてみました。
そしたら、

１、Mythwebから録画設定等の画面は開ける（httpsでリンクやsubmitできている）
２、Mythwebから録画した映像を見ようとするとサーバに接続できない（リンク先のプロトコルがhttpになっている）

と言う結果になりました。
iptablesで

httpsで接続できているマシンから、httpで要求があった場合はhttpを通す。
ただし、httpsで接続していないマシンからhttpの要求があった場合はブロックする。

と言ったような都合のいいブロック方法って何かありますか？
ちなみにMythwebはLAN内ではhttpで普通に使えています。

756:login:Penguin
09/02/20 21:35:13 iLve4iTI
>>755
iptablesで必要なポートを開けるためのスクリプト(setuidフラグ付き)を作り、
それを呼び出すためのcgiを作ってhttpsからアクセスさせればいいのでは。

もちろんセキュリティホールにならないようきちんとチェックする必要があるが。

757:login:Penguin
09/02/21 16:56:16 5ViP3mcA
>>756
あ～、なるほど。
そういう手もありますか。

でもftp何かでもコマンド用のポートとデータ用のポートが違っても大丈夫な様に、
httpでも同じような仕組みができないかと思ったんですが、難しいんですかね～？

758:login:Penguin
09/02/22 03:08:54 kRWcVgWK
ftpは追跡用の専用モジュールあるでしょ(ip_conntrack_ftp)
http対応させるならhttp用のモジュールが無いと無理。
そもそもL7だからiptablesの仕事じゃないと思うが。
一応l7-filterってのもあるけど、それでうまくいくかどうかは知らない。

759:login:Penguin
09/02/22 03:11:52 kRWcVgWK
あー、内部のftp鯖用だとip_nat_ftpだっけ、まあどっちでもいいや・・・

760:login:Penguin
09/02/22 20:47:12 GfbPUEsr
あまりニーズがなさそうだからねぇ。ftpのようなトリックは自分でやらんと。
そういうことをやる汎用のルールはないか、という意味の質問なんだろうけども。

761:login:Penguin
09/02/22 22:15:21 7d9guBVj
>>758
>>759
>>760

レスありがとうございます。
言われてみればftpは専用モジュールがありましたね・・・。

実際にはやはり、sslでログインなどの認証かまして、そのIPに対してhttpを開放するルールを
作るのが正解っぽいですね。

あるいは、リバースプロクシか何かで強制的にポートを入れ替えてしまうとかですかね？

ありがとうございました！

762:login:Penguin
09/02/22 23:27:39 +kmxZRYl
>>761
今更だが、sshでトンネルを掘る(簡易VPN)っちゃダメなのか？
公開鍵認証のみ受け付ける設定にすれば安全性はクライアント認証と変わらない。
（つ～か、下手にスクリプト組むとセキュリティの確認が面倒）

763:login:Penguin
09/03/15 15:17:31 vnCvBK0D
ポート80には、韓国・中国・香港・台湾（.tw）などの国を拒否しつつ
ポート8080では、日本からのIPのみを許可する方法教えてください。
いろんなサイト見てると意味不明になってきましたorz

764:login:Penguin
09/03/15 17:59:00 uk1z+jYj
方法っつーか地道にリスト作るしかないでしょ。
そんな需要あまりないから自分で。

765:login:Penguin
09/03/15 18:13:08 umYumNQy
>>764
あるんだな

>>763
web上探せばスクリプトも公開されてるよ
2chでスレッドが立ったこともある
外部公開したいくらいなら自分で探してみ

766:login:Penguin
09/03/15 18:21:32 D7dwhpji
5つくらいのリストファイルDLしてgrepするだけでいけるはず。

767:764
09/03/16 04:12:07 IPdPlwrs
APNICかなんかの情報でそれできるかね？
最近は再割り当て頻繁だから、古い情報をもとにやると
本来はじくべきでない人をはじいたりしそうだなー。

メンテナンス自動化しないと、やはりその問題が起きるから
かなり手間かかると思うが、それをやるスクリプトってことかね？

クラッカーは迂回路から入ろうとしたりするわけだから、あまり
意味がないと思うけど……

768:login:Penguin
09/03/16 07:28:48 vC3uuih8
>>767
金魚みたいに口パクパク開けてねえで調べろって

769:764
09/03/16 09:16:14 IPdPlwrs
俺に言うなよ（笑　ちゃんとレス番見れ。

770:login:Penguin
09/03/17 01:03:18 tZV7ufHu
じゃあ俺はちゃんとレス番を見てお前に言っちゃおうかな？
>>764
金魚みたいに口パクパク開けてねえで調べろって

ちょっとググったらその手のスクリプトの内容も分かるぞ。
DLしてgrepが基本だからそんなに手間もかからないし面倒くさくもないけどな。
ちなみにBOTを弾くのにも有効な手段。ポートを変えてても総当たりで試そうとするタイプもいるから困る。

771:764
09/03/17 01:08:26 OQn5xYfP
いや俺は質問者じゃないって。スクリプトがあるとかないとか、関心なし。
つか質問者どこいった？（笑

772:764
09/03/17 01:14:57 OQn5xYfP
あと、BOTをそんなIPベースでちまちま羅列する方法ではじけてる、
なんてのはDDoSの意味が分かってないとしか。

アドレスブロックなんていまてんでバラバラにクラスレスであっちこっちに
再割り当てしまくってる上に、BOTなんて二重三重に国を経由して来る。

自分でやってることと現実が一致してないのに悦に入ってるだけ、の
可能性もあるかと。

773:login:Penguin
09/03/17 05:04:49 ze3UVfmX
調べて自分の目で確かめるのが一番だと思うよ
逆に興味がないなら調べる必要ないし

774:login:Penguin
09/03/17 07:33:45 mDYSR57N
てんでバラバラにクラスレスにあっちこっちを塞ぐスクリプトなんだよな。
国別iptables。
なんか美しくないし自分とこでは必要なさそうなので使ってないけど。

775:login:Penguin
09/03/17 11:44:05 WpLV1Gl4
攻撃元IPアドレスの分析とかやってないんだろうな

攻撃元のうち、日本以外の物が9割以上
日本が発信元のうち、某激安ホスティングプロパイダと学校系で約5割
これらを拒否するだけで95%以上は対策できる。

あと、固定IPと動的IPで、攻撃される量がかなり違う。
進入成功して踏み台にするにも、IPアドレス変わったら使い物にならないし
42億近いIPを全スキャンすると途方もない時間がかかる。
結局、効率的にやる必要があるので、固定IPだとわかっているブロックが狙われやすい。

hosts.allow/denyに.jpと書く方法もあるけど、DNSの逆引きに時間がかかるため、
結果として自分でDoSを起こしてしまう可能性が出てくる。
apnic/jpnicのデータベースからスクリプトで変換してiptablesで入れておく方が現実的かと。

776:login:Penguin
09/03/17 13:58:18 /w9gjZ7Q
こうしてインターネットは国ごとに分割され使いにくいものとなったのであった

777:764
09/03/17 16:43:59 OQn5xYfP
俺もadhocな感じがするし完全にはできないから、まして人が作った
スクリプトで自分の管理するマシンに到達不可能なIPをじゃんじゃか
機械的に生産するとか、とてもやろうとは思わないわ。

それこそ趣味でやってんなら別だが、他人にサービスする用途だったら
知識ある人ならやらんでしょ。需要ないって書いたのはそういう意味で。

ちなみにBOT感染してるPCの数は日本はそれなりに多かった気がする。
どこだったかで統計みたけど。自宅の通信環境が良いので自宅でサーバを
動かしてる人が多いからじゃないか、とか分析してたな。

778:login:Penguin
09/03/17 17:13:29 FZ96Xb7j
apnic/jpnicのデータっても即時更新されるわけじゃないからね。

779:login:Penguin
09/03/17 20:14:20 DpJX+Z4E
>>775
>攻撃元のうち、日本以外の物が9割以上
かなり有効な対策なんだな

>apnic/jpnicのデータベースからスクリプトで変換してiptablesで入れておく方が現実的かと。
そういうツールの話だろ？

780:764
09/03/17 22:51:02 OQn5xYfP
それはさぁ、インターネット全体を把握することが誰でも簡単にできますよ、という
あまり現実的じゃない話かと。

>>779がむしろそういうことができると言うことで何かメリットのあることを
やってて、そのレベルで、できる、かといえばできる、わな。

つかその攻撃元がうんぬんってのも分散攻撃とは何か、が分かってない
統計かと。実際iptablesのログ見てても最近のDNS DDoSなんか
まぁよくこんないろんな国から来るな、という感じでしょ。

781:login:Penguin
09/03/18 01:39:41 NihXUljR
そういう方法しか思いつかない人がいるなら、
より良い方法があると思うならアドバイスをしてやれば良かろうに。
と思った。

俺？対策はしてないな。興味はあるけど。

＞iptablesを使って素敵なファイアウォールとか、
＞快速ルータを作ったりするために、
＞情報を出し合うスレ

782:764
09/03/18 01:42:02 jphinfD+
というかないよ。むしろAPNICがそのプログラムくれって感じだろ（笑

783:login:Penguin
09/03/18 23:37:52 NihXUljR
無いなら黙ってればいいんじゃね？
JP以外弾きたいと言う人がいて、（若干非効率ながらも）弾く方法があるというのに
それを需要が無いだの、メリットがどうだのこうだの。

>764に他人のサーバ環境を心配される必要も筋合いもないんだぜ？
セキュアのセの時も知らない奴ならともかく。

784:login:Penguin
09/03/18 23:50:52 1fzt16E1
APNICのリストみたって、日本のIPの全部は分からないんじゃないの？
一部の大学や海外系ISPとか、あとネットワーク系企業とか、
結構重要なのが漏れてる気がするんだけど。

785:login:Penguin
09/03/18 23:55:52 U7+c+vxW
5年くらい前に調べたときは中国・韓国からのアタックが90%以上占めてた。
アドレスレンジのリスト作ってiptablesで弾くだけでかなり効果あった。

最近は東欧や南米からのアタックが増えている希ガス。(ちゃんと統計とってないけど)

786:login:Penguin
09/03/19 00:42:09 A46BG9io
>>784
どっちにしろ100％は無理なのは分かってるけど
その辺りのIPアドレスはどこかにリスト化されてないのかな？

787:login:Penguin
09/03/19 01:42:48 VEb9NHr7
fURLﾘﾝｸ(ftp.arin.net)
fURLﾘﾝｸ(ftp.ripe.net)
fURLﾘﾝｸ(ftp.apnic.net)
fURLﾘﾝｸ(ftp.lacnic.net)
fURLﾘﾝｸ(ftp.afrinic.net)

ここからgrepした結果にその漏れてる奴とやらを追加していけばいいべ
というわけで漏れてるのうpヨロ

788:764
09/03/19 04:18:08 LfNCeRW7
>>783
非効率というか、DBはたしかにAPNICが公開しているが、それを
じゃあcronか何かで毎回持ってきてgrepしてリスト作るの？
それみんながやり始めたら単なる迷惑行為かと。

しかも現状とは完全には一致してないから、 JP以外は排除なんて
ことは本当にちゃんとやろうと思ったら不可能。むしろJPなのに
アクセスできない人が出てくる。

一応趣味だろうがなんだろうが、サーバ管理者でネットのオペレータの
端くれなんだから、はじくべきでないものをはじいいてしまうルールというのが
いかにダメか、って分かると思うんだけどね。

789:login:Penguin
09/03/19 07:00:41 THCrkLGw
>はじくべきでないものをはじいいてしまうルールというのが
>いかにダメか、って分かると思うんだけどね。

最所っから
>そんな需要あまりないから自分で。

と言ってる人にはそうなんだろうな

>それみんながやり始めたら単なる迷惑行為かと。
なんのために情報公開してるんだか
２chにアクセスするの止めたら？

790:764
09/03/19 07:28:16 LfNCeRW7
iptablesのラインというか、地理情報をIPと完全にマッピングする方法は
あるのかないのか？って話になるよね。それはやろうとしても不完全になる。

ちなみにJPNICの活動理念から引用するけど、

JPNICはインターネットの円滑な運用のために各種の活動を通じてその基盤を支え、
豊かで安定したインターネット社会の実現を目指します。

できもしないことのために彼らのDBに四六時中アクセスするってのは、
俺にはできんなぁ。

スパム排除ならもっと他にいいフィルタ方法が沢山あるし、DDoSは
論理やパターンではじかなきゃ、BOTNETを利用してる連中はふせげないよ。
需要、ないでしょ？

ちなみにできることであれば俺はいくつかラインはここに書いた。
できないのに、できるよバーカ、みたいなことを言うのがいたけど、
それは自分でやるのは勝手だが、ここの住人の見解ではないというだけ。

791:login:Penguin
09/03/19 10:41:45 JUp7sKbL
自分の見解がスレの見解だとも？

フィルタリングされて困る人
１　apnic等に登録されていないアドレス帯を使ってる人
２　クラッキング等が困難になる、ヒット率が下がる、BOTNET使ってる人
３　高額なハードを売りつけれなくなる人

SPIに言及してるから３かな

792:login:Penguin
09/03/19 10:52:09 t7bAZDSH
IPアドレスで弾くのは本質的な対策になってないよな
ちゃんとサーバのセキュリティ対策をやっておけばそんなことする必要ない

海外に行ったら見られなくなったりするコンテンツとか正直ありえんよ
俺は出張でよく海外行くからねえ

793:login:Penguin
09/03/19 11:55:28 VEb9NHr7
ここはiptablesのスレだから、IPアドレスで判断するのは基本。
それはしょうがない。

794:login:Penguin
09/03/19 12:02:35 DAtP4B6B
ここはなんでもかんでもiptablesでやろうとするスレです。
アプリケーション層でやれとかいう人はお引き取りください。

795:login:Penguin
09/03/20 01:06:19 Wj9gyTsE
>>792
それは論外じゃね？

796:764
09/03/20 02:20:35 fkbrMgVo
>>791
では俺が書いてることで技術的に間違ってる点をあげてみてくれ。

困るとか困らないとかじゃなくて。ちなみに一ユーザですよ。

簡単にできるからgoogleで調べろ、ってのがじゃあこのスレの意見って
ことでいいの？（笑　どこぞのアングラサイトのハッカー気取りの
個人掲示板ならそれでいいだろうが。

>>793
んなこたーない。最近DDoS対策で一番助かったのはパターン
ベースのラインだし。プライベートIPがソースでグローバルから
入ってくるとか、そういう不正パケットは確かにIPベースではじいてるが、
これはプライベートIPの定義がはっきり決まってるからできることだわな。

797:login:Penguin
09/03/20 10:14:28 ya3lNzB4
>>792
ここlinux板だろ？
どうして、自宅経由でアクセスするとか考えないんだ？
32022とか、一時使用のポートに見せかけてsshd開いておいて
XForwardをsshの中通すようにでもすればいいだろ

そもそも、海外ってのが中国だったら、普通の方法じゃ見れないとも思うが

798:764
09/03/20 13:16:17 4kmKdqy9
国別での対策なんてされたら俺の同胞が困るだろ

799:764
09/03/20 17:02:44 fkbrMgVo
>>798みたいないう嫌○厨みたいのがここ見てわけわかんないけど好都合だからっつって
APNICにガンガンアクセスするスクリプトを繰り返し動かすとか、迷惑行為だなぁ、やっぱり。

この話題はもうiptablesのライン出てくることないから、まだ続けるなら、通技板にでも持っていこう。

800:764
09/03/20 17:12:40 Wj9gyTsE
自演かもしれないけどな
トリップを付けていないから本人の判別なんて出来ないからなあ

801:764
09/03/20 17:20:35 fkbrMgVo
といいながらハンドルマネすんのやめてくれ（笑　レス番付けるのは
読むほうの利便性を考えてやってることなんだからさ……

802:login:Penguin
09/03/20 18:52:16 kQ12QUs2
>>797
誰でも自宅サーバ持ってると思うなよ

803:764
09/03/21 02:53:34 +9fyatks
特定の国からアクセスされたくないというのなら
その対策を取るのは情報を発信する側の自由だろう

そういうニーズの存在を否定することはできないし
対策する手段があるということは喜ばしいことでもある

804:login:Penguin
09/03/21 03:02:23 Zgt+v0rx
iptables側はそのニーズを汲み取ってはいないけどね。

805:764
09/03/25 17:04:48 FXSCQYzx
ググれカスもいいけど、アドレスぐらいケチケチせずに貼っちゃえよ
URLﾘﾝｸ(www.42ch.net)

俺はこんな感じのスクリプトでやってる
#!/bin/sh
DROPCOUNTRY="KR,CN,KP,HK,ID,IN,MX,RU,TW,PL,TH,AU,PH,UA,PE,IT,CA,CZ,NL,TR,BR"

wget -O delegated-apnic-latest fURLﾘﾝｸ(ftp.apnic.net)
wget -O delegated-ripencc-latest fURLﾘﾝｸ(ftp.apnic.net)
wget -O delegated-afrinic-latest fURLﾘﾝｸ(ftp.apnic.net)
wget -O delegated-arin-latest fURLﾘﾝｸ(ftp.apnic.net)
wget -O delegated-lacnic-latest fURLﾘﾝｸ(ftp.apnic.net)

perl countryfilter.pl iptables $DROPCOUNTRY < delegated-apnic-latest > filter-apnic.sh
perl countryfilter.pl iptables $DROPCOUNTRY < delegated-ripencc-latest > filter-ripencc.sh
perl countryfilter.pl iptables $DROPCOUNTRY < delegated-afrinic-latest > filter-afrinic.sh
perl countryfilter.pl iptables $DROPCOUNTRY < delegated-arin-latest > filter-arin.sh
perl countryfilter.pl iptables $DROPCOUNTRY < delegated-lacnic-latest > filter-lacnic.sh

sh iptable.sh

sh filter-apnic.sh
sh filter-ripencc.sh
sh filter-afrinic.sh
sh filter-arin.sh
sh filter-lacnic.sh
/etc/rc.d/init.d/iptables save

806:login:Penguin
09/03/26 04:31:26 OsjUvcPw
意味が分からないで使うやつがでてくるから貼るなとはいわんが
解説くらい付けたら。ローカルだけの処理じゃないんだし。

807:764
09/03/26 11:30:02 P+axV9ZV
>>804
痛い奴だな

808:764
09/03/26 14:30:18 9PJCe/57
>>806
素直にわからないから教えてくださいって言えば？
意味もわからず2chに貼られたスクリプト実行するって・・・

809:764
09/03/26 23:31:41 qS6lSxTJ
>>806
解説はURL参照。つーか、説明しなきゃならんほど複雑なスクリプトか？

810:login:Penguin
09/03/26 23:53:14 WCnoFcd/
これ見てわからん奴は使わなくていいんじゃ

811:login:Penguin
09/03/27 00:08:16 2rBgswvf
わからないものは使わないまともな人間ばっかならいいんだけど。

812:764
09/03/27 07:02:52 BIb02kCF
またニセモノが（笑人様を罵倒してる764は全部ニセモノだから。

>>811
そういうことですね。
クラックやら不正アクセスやらを防ぐためにAPNICに迷惑かける
なんて本末転倒だね。互助精神とかないのかな……

813:764
09/03/27 16:00:52 w8VvGftF
>>812
> クラックやら不正アクセスやらを防ぐためにAPNICに迷惑かける
805のスクリプトだけじゃ糞の役にも立たないよ
APNICに迷惑かけるってどのあたりが迷惑かけるになるの？
cronで毎秒廻したりするの？

> 互助精神とかないのかな……
こゆこと抜かす奴に限って何もしないよな
そー思うならお前が解説書けばいいじゃん

814:login:Penguin
09/03/27 16:49:36 vWe7WV5n
>>813
>cronで毎秒廻したりするの？

わからないまま使ったらそういうやつもいるかもな。

次ページ