SSL通信は透過するけれども、http通信は透過しないという不思議状況に悩まされる FATAL: mimeLoadIcon: cannot parse internal URL:

CENTOS8で、透過SSLプロキシを建てようとしたはいいものの、諸々はまって、最後に原因が分からないけれども
何とかなったという、誰か真面目に説明して欲しい位の何かにはまったので書いておく。

はまりポイント1

nftablesの意味が分からなかった。
8からnftablesに変わるから覚えなきゃ、で始めたのだけれども、
iptablesのノリで出来る物だと思っていたら、何か御作法が全然違う。iptablesをnftablesの設定に変換できるので、
変換してみたのだけれども、同じ文法で書いてみても適用時にエラーが出る。
なので、3日間位がっつり調べたり試したりしたが、nftablesは未だ早いという結論に至った。
nftablesは書籍は勿論、ウェブページでも扱っているところが少なすぎて、何をどうすればこうなるが全く頭に入らなかった。
結局nftablesを覚えなくても、iptablesがそのまま使える（内部的にはnftablesに変わっている）ので、iptablesで進めることにした。

はまりポイント2

firewalldを無効にしなかった。
どうせ中身はnftablesなのだから、と思っていたら、思いっきり相互干渉してしまっていた。
全く用を為さないわけでは無く、部分的に効いたりするからタチが悪い。
しかもエラーメッセージはないので、原因解明に1日潰した。
firewalldだけ潰して再起動をかける。（似たあるあるで、selinuxの無効有効を忘れるとか）。

はまりポイント3

squidのhttp_portを2つ入れなければならなかった。
これが謎の大元。何回やっても、https（SSL)は通っているが、httpが兎に角通らなかった。
squid.confの設定で、http_portを指定するところがあるのだけれども、

http_port 3128 intercept

のように、intercept（透過指定）すると、
squid自体は立ち上がっているように見えるが、実際はエラーで起動しておらず、

systemctl status squid

でエラーを見ると、
FATAL: mimeLoadIcon: cannot parse internal URL:～というエラーがでて、ずっと悩んでいた。
これの答えは、
https://tutorialmore.com/questions-290758.htm
のように、

http_port 3127
http_port 3128 intercept

と、２つ指定しなければならないと言うことだった。
・・・これ、何故指定しなければならないのか、指定したらどういう風に通信処理されるのかさっぱり分からないんだよね・・・。
iptablesでは、3127ポートに関しては一切触れていないので、内部処理なんだろうけど・・・。
※3127とか3128とかのポートは任意なので一応注釈。
squid3だと、ポートを2つ指定したことが無かったので、新しい御作法なんだろうけれども・・・。

切り分け別個の話として、intercept指定しなければ、ブラウザにプロキシを噛ませる必要があるので、
もし噛ませなかったら

    不正なURL

指定されたURLに正しくない部分があります。

考えられる問題:

    ("http://"または同類の)アクセス・プロトコルが抜けているか不正です。

    ホスト名がありません。

    不正な二重のエスケープがURLパスに含まれています。

    ホスト名に不正な文字が含まれています: アンダースコア(下線)は使えません。

というエラーがsquidから出る。
英語だとinvalid urlか。

ntpを設定するのと、squidプロキシを噛ませてyum出来るようにする

最近ファイルスタンプのずれが気になるという声が「やっと」聞けたので、ntpを設定していこうと思い立った。
もののついでに、SSLプロキシがはまったせいで、yumさえ出来なかったサーバプロキシの設定をしてyum出来るようにする。

まずゲートウェイサーバをNTPサーバにする。と言っても、外部NTPサーバと同期させるというだけである。
詳しいNTPについては
http://tech.ckme.co.jp/ntp.shtml

環境はcentos5~7、192.168.168.1がプロキシ兼NTPサーバとする。

yum install ntp

設定ファイルを編集

vi /etc/ntp.conf
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap　＜これをコピーして下で編集
restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap

あと同ファイルで

server ntp.nict.jp#<<公開NTPサービス
server ntp1.jst.mfeed.ad.jp#<<公開NTPサービスに同期している会社の公開NTP
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp
server 契約しているISPのNTPサービス
#server 0.centos.pool.ntp.org iburst#デフォルトのはコメントアウトして負荷を減らす
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst

これで設定終了。

ntpdate ntp.nict.jp

で手動同期。

systemctl start ntpd
systemctl enable ntpd

で自動起動させる。

iptablesでFW機能をさせているので、iptablesにローカルから自機へのNTP問い合わせ許可設定をする
iptables -I INPUT -p udp --dport 123  -s $trusthost -d $mylanip -j ACCEPT
*$trusthostはローカルIP群、たとえば192.168.168.0/24、$mylanipは、LAN側のIP（この場合は192.168.168.1）。厳密にしないなら-sと-dは無くても良い。

次に、クライアント側設定。
プロキシを通すので、yumの設定ファイルにプロキシを追加

vi /etc/yum.conf

で

#proxy=http://PROXY-SERVER.ADDRESS:port
proxy=http://192.168.168.1:8080

プロキシの噛ませ方は、以下のページが詳しい
http://fj.hatenablog.jp/entry/2014/08/20/204554

で、サーバと同じようにyumでNTPを入れる

yum install ntp

設定ファイルを編集

vi /etc/ntp.conf
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap　＜これをコピーして下で編集
restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap

更に、サーバはnictを登録したけど、クライアントはnictを参照させず、NTPサーバを参照させるので

server 192.168.168.1

とする。

ntpdate 192.168.168.1

で手動同期。

systemctl start ntpd
systemctl enable ntpd

で自動起動させる。

追記
上記でも良いけど、設定しながら「これってntpdateをcronで動かした方がリソース消費しなくね？」という事実に気付き、上記の設定ファイルの編集をせず、たとえば
vi /etc/cron.daily/ntpdate_update.sh
とかで新規ファイルを作って
#!/bin/sh
ntpdate 192.168.168.1
で保存し、
chmod +x ntpdate_update.sh
で実行権限付けて、デーモンは動かさないことにした。クライアントなんだから走らせ続ける意味はないわな。
まあ別に走らせても良いと言えばいいわけで（どうせローカル参照だし）、取り消し線で済ませておくことにする。

手動あわせしようとした際に出る「the NTP socket is in use, exiting」というエラーメッセージは、読んで字のごとく、「NTPソケットはもう使ってるから！」と言われている。
おとなしく
systemctl stop ntpd
なり
service ntpd stopなりでNTPを止めてから再度実行して下さい。

備忘録
オレオレ証明書等ルート証明書をlinuxに読ませる場合
centos7
https://cloudpack.media/14148

/usr/share/pki/ca-trust-source/anchors

に証明書をコピーして

update-ca-trust extract

を実行

centos5~6
https://wp.kaz.bz/tech/2013/05/02/1651.html

/etc/pki/tls/certs/にコピーか、
/etc/pki/tls/certs/ca-bundle.crtに追記する。

別環境にファイルサーバを据えたら認証で待たされる（遅くなった）。サーバが参照するdnsサーバを疑え

念願のclassB環境にネットワークを移行させたのは良いものの、結局トラブった。
classC環境（いわゆる192.168.x.x)からPC台数と管理の関係でclassBに移行したのだけれども、
何故か社内の特定ファイルサーバだけ、認証画面に行き着くまでかなりの時間（数十秒）待たされる。
認証してしまえば全く問題なく使えるのだけれども、統括部内だと全ての部署に配置されているファイルサーバに接続するため、
いちいち時間がかかってしようが無い。

結論から言うと、サーバ側の問題だったが、まあおつきあい下さい。
環境はcentos 5x~7xまでばらばらだが、centosとsambaで構成されたファイルサーバ群。クライアントは大半がwindows10。

まず疑ったのが、クライアントPCのルーティング。
「クラスC環境は全て取っ払った」ので、192.168とか吐いたら間違いなくそれの筈。
そこで、Wiresharkで通信ログを取るが、
全てDHCPで管理しているので、ルーティングをしくじっている気配は無い。
192.168とか吐いていればこれだと言えるが、吐いているのはサーバ群のみ。
*このときに気付いていれば良かったが、CからBへの移行の際、シームレスに移行するためにファイルサーバにはIPアドレスを２つ（BとC）持たせていたので、別に不自然だとは思わなかった。

次に、正常なサーバと異常なサーバを比較。
smb.confを比較したが、特に引っかかるところは無かった。
強いて言えば、netbios_nameがあったりなかったり程度。
iptablesではじいてしまっているのかと思って比較するも、関係なし。
ただ、
いつもはさっと引ける「iptables -L」が異常に重い。

google先生に

「iptables "-L" ローカルIPアドレス　遅い　表示」

で聞いてみると、どうやら名前を逆引き出来ないから、という結論に。
iptables -nLで逆引きしなければ良いよ、と教えて貰えるが、それはこの環境での答えとは違う。引いているのはローカルIPアドレスなのである。
ここら辺で、なんとなく名前の解決関係（DNS）がらみなのではと疑い出す。

ゲートウェイやDHCPはクラスB環境に移行していたので、最後にファイルサーバ群のネットワークの記述をクラスCのみにすることに。
ここで比較していると、一点だけ違う、奇妙なことに気がついた。
PEERDNS。
解説は
http://think-t.hatenablog.com/entry/20110113/p1
が詳しいのだけれども、あるなしの違いがあった。
正常に繋がる方は、PEERDNS=no、繋がらない方は記述自体が無い。
上記ページに従うと、resolv.confの記述内容を使うかどうかということ。
Centos5から使い続けていたので、NetworkManagerとは因縁がある。
もしNMを使っていれば関係ないのかもしれないが、
NMを使っていると、勝手にresolv.confを書き換えるので、意図的に停止させているのである。
なので、resolv.confの書き換えをしないと、設定は生きっぱなしになる。
resolv.confには、ばっちりclassCのDNSサーバアドレス。
しかも僕はご丁寧に（移行中だったからだけど）NICの設定ファイル（ifcfg-foobar）にも書いていた。

ということで、問題点は、
「存在しないDNSサーバにファイルサーバが問い合わせまくって、その問い合わせの答えが出ないから時間がかかりまくった」
ということでした。
解決法は
NICの設定ファイル（/etc/sysconfig/network-scripts/ifcfg-foobar)に正しいDNSサーバアドレスを書く
ことと、
resolv.confを見直し、ちゃんと正しいDNSサーバアドレスを認識しているかどうかを確認する
こと。

前者は、たとえばNICの設定ファイルがifcfg-eth1だった場合、

vi /etc/sysconfig/network-scripts/ifcfg-eth1

で、正しいDNSサーバのIPアドレスを指定する。たとえば

DNS=192.168.0.1

と記述してやる。
僕がはまったのは、サーバは番号を振ればいくらでも登録出来るので

DNS1=192.168.XXX.XXX
DNS2=172.16.YYY.YYY

のように登録して、DNS1は既に取り外していたこと。

後者も同じように、nameserver=でいくつでも登録出来るので、使う（使える）DNSサーバだけにする。

これで問題なくなった。

以下はgoogle先生に聞きまくったときに出てきた似たような事例。
残念ながら答えは出ていなかったが、恐らく問題は同じだろうと推察。
http://cgi.samba.gr.jp/mailman/archives/samba-jp/2013-July/003306.html
クライアント-サーバ間では全く問題ないログしか吐かないし、Wiresharkでも問題が認識出来ないのがミソ。

自分の関連過去エントリは
resilv.confとPEERDNSなど
http://roserogue.blogspot.jp/2011/10/cent-os6resolvconf.html

sambaがらみ
http://roserogue.blogspot.jp/2007/08/samba.html

squidをSSLに対応させたい。https通信なんて大っ嫌いだ・・・。

今回何をやったかというと、SquidのSSL対応である。その備忘録。やり方は後日ここにも書きます。ひとまずわかりやすいpslaboさんの記事の方へ

元々
http://pslabo.hatenablog.com/entry/20150703/p1
で、https通信、しかも透過型で噛ませられることは認識していた。
ただ二の足を踏んでいたのは、
・作っている暇が無かった。
　作るならゲートウェイサーバをすげ替えることになるので、何より面倒くさかった。
・透過型なのだけれども、証明書をクライアントにインストールしなければならなかった。
　実は結構これが大きくて、今はプロキシが噛んでいることをユーザは認識せずに使っているのだけれども、証明書を入れなければいけない時点で認識されてしまう。
　また、ゲストネットワークをどう認識させるかという問題もあった。ゲストがネットワークに繋ごうとすると、証明書のインストール必須だと、まあ誰も接続しないだろうし、接続したいと言い張られてサポートに人手が必要とか、切ないことになりそうだったので。

でももう背に腹は代えられなくなってしまった。
どうも社内ファイルがgoogleドライブで作業されているようなのである。
せめてoffice onlineなら分かる。お漏らし回数で考えると、圧倒的にまだマイクロソフトに分があるから。
googleはあくまでも自己責任ツールの集合体で、信用しても信頼してはならない。
大企業だからって信頼してはならないことを知っているはずなのに。
また、銀行系マルウェアに感染した人が居て、大騒ぎになった。愚かとしか言い様がないが、いとも簡単に感染してしまっているのが現実。
で、そのマルウェア、誘導にSSL使っていやがります。
今のままだと、まず間違いなくやられる。
ということで、以下を実行。
pslaboさん本当にありがとうございます。。。見ず知らずなのに即行エントリ書いてもらいました・・・。
http://pslabo.hatenablog.com/entry/2017/06/18/CentOS7%E3%81%A7squid%E3%81%A7SSL%E3%82%92%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8Bproxy%E3%82%92forward_proxy%E3%81%A7%E8%A8%AD%E5%AE%9A%E3%81%97%E3%80%81

はまったところは、透過プロキシとフォワードプロキシで動作が違うらしく、google「だけ」HSTS通信と見なされ、証明書エラーで通らないこと。facebookもtwitterもHSTS通信でも大丈夫だったのに。
透過プロキシだとどうしても通らなかったのが、通常のプロキシだと通るという・・・。
ここからカスタムしていくことになるのだけれども、まずはOK/NGという初期段階まではいけたということで。
#検証前だけど、googleがリダイレクト動作をしているので、そこで引っかけている可能性が高そう。どう回避するかなあ・・・。

WannaCry対策をする（SMB1からの決別）

WannaCryという米NSAの悪意あるお土産のせいで、世間が阿鼻叫喚になったのは記憶に新しいが、
まともに対策を書いていない感じがあるので、対策。
WannaCryの概要は
https://syobon.jp/2017/05/15/wanacrypt0r-spread-of-infection-around-the-world/
を拝見しました。

ファイルサーバがSMB1を使わないようにする。
sambaだと、SMB1で通信出来るようになっているので、明示的にSMB2以上で接続するようにsmb.confのglobal部分に以下を書く。

server min protocol = SMB2

もしくは

min protocol = SMB2

で、設定の再読込

service smb reload

クライアント側は、windows7以前のOSを排除する。
SMB2.0以降を使うOSだけにする。
その場合、古いAndroidも恐らく対象になる。具体的には、AndroidOS2.Xは全滅じゃ無いかな・・・。

また、win10でもSMB1通信が出来るので、出来ないようにする。
「Windowsの機能の有効化または無効化」の「SMB 1.0/CIFSファイル共有のサポート」チェックボックスを「外す」。
http://news.mynavi.jp/column/win10tips/047/
URLは真逆のことをやっていることに注意。

ゲートウェイ上の対応は、とりあえずbotネットワークに組み込まれないように、torネットワークへの接続をしないようにする。
https://dist.torproject.org/への接続をSquidで切ったり、IPを引いてiptablesで遮断する。
http://roserogue.blogspot.jp/2014/01/toriptables.html

あと出来れば、脅威の主体国が保持するIPアドレスに対してアクセスしないようにするのが適当だけど、仕事上そうも行かない可能性が高い。
ロシア、中国、イラン、北朝鮮、パキスタン、シリアへのアクセスは本音では切りたい。
個人的にはスプートニクが見られなくなることが残念だけど。

https://www.osstech.co.jp/support/2017-05-16
は眉唾だなあ・・・XPがある環境だとSMB1に対応せざるをえないからなあ・・・。
まさかとは思いますが、「サーバが感染しない（暗号化されないとは言っていない）」というだけだったりして・・・。

1e100.netというgoogleの踏み絵

chrome汚染が酷いので、googleサービスを取捨選択して使用しようと思い立った。
まずchrome自体をダウンロードできなくするために、dl.google.comへのhttp、httpsアクセスを止めた。
あと広告配信を1e100.netからやっているようなので、これも止めた。
するとどうだろう。ssl通信を必要とするほぼほぼ全てのgoogleサービスにアクセスできない。
アクセスしてもタイムアウトする。iptablesがうまく動いている証拠と言えば証拠だが・・・。
慌ててsquidのログを確認すると、216.58.216.XXXを恐ろしい回数ドロップしている。
1e100.netである・・・。

1e100.netについて調べると、http://www.herdprotect.com/に行き当たった。

docs.google.com
http://www.herdprotect.com/domain-docs.google.com.aspx
dl.google.com
http://www.herdprotect.com/domain-dl.google.com.aspx

結局1e100.net（のサブドメイン）を使っているのだ・・・。
なので、iptablesで1e100.netをはじくとさっぱり繋がらなくなる。
また、docs.google.comやdl.google.comをブロックしても、同じ状況に陥る。
ただし、必要な1e100.net群をブロックしていなければ、そこそこ繋がるという不思議状況にもなる。
ワンチャンかけてdl.google.comをブロックするのもありだが、あまりお薦めはしない。
また、何回か試していると、いつも決まった1e100.net（のサブドメイン）を参照している「わけではない」ようなので、余計にたちが悪い。

結局squidでhttpのみdl.google.comや1e100.netをはじく対処で落ち着いた。
落ち着いた？気休めである。そう、問題は何も解決していない。
googleはSSLを推奨しており、わざわざhttp接続にしても、ご丁寧にhttps接続に切り替えてくれる。

https://support.google.com/drive/answer/1211661?hl=ja
で、ファイヤーウォールの設定が書いてあるが、
結局大元の1e100.netを止めてしまっては元も子もないということである。不親切。
また、
https://support.google.com/faqs/answer/174717?hl=ja
に1e100.netについて書いてある（が、日本語にならない。）

we started using a single domain name to identify our servers across all Google products

と記述されているので、まあ「そういうこと」なのだろう。
googleサービスを使うのであれば、1e100.netへのSSLアクセスは必要で、拒否することは出来ない。

そう、抵抗は無意味だ。

iptablesで特定の外部サーバへのSSL接続を制限・禁止したい

やっと念願のSSL接続を遮断することが出来た。
元々squidでフィルタリングする予定だったが、どうも透過プロキシを使用する場合はNGらしく
http://lists.debian.or.jp/debian-users/200909/msg00065.html
じゃあどうやって切るんだと言われると、iptablesくらいしか思いつかなかった。
そこで

iptables -I OUTPUT -d 31.13.64.0/18 -p tcp --dport 443 -j DROP

という感じで記述したのだけれども、結局箸にも棒にも、iptablesにも引っかからなかった。
人に聞いてみても応えてくれないし、正直お手上げだった。
というか、みんなデフォルト設定でOUTPUTはACCEPTの人が多いんですよねー・・・。

で、google先生に力一杯調べて貰って5年越し（5年間分からなかった）の回答を得た。
http://www.linkedin.com/groups/HOW-block-HTTPS-sites-32612.S.107118452
流石linkedin。実名で且つ仕事してる人たちの集まり。
Pramodさん流石すぎる。

iptables -I FORWARD -s 192.168.1.0/24 -d 31.13.64.0/18 -j DROP

FORWARDなのね・・・。
真逆の展開。というか、よく考えればその通りで、ローカルからディスティネーションへの転送だから、ああ、なるほど。
443だけ蹴りたいので、

iptables -I FORWARD -s 192.168.1.0/24 -d 31.13.64.0/18 -p tcp --dport 443 -j DROP

となる。かな。

ということで、まずはじきたいurl群を書いたファイル「denysslURL」を用意する。
で、以下のシェルスクリプトファイルを作る。
vi BANSSH.sh

#!/bin/sh
#スクリプト起動時にファイル「denyssllist」を消して再作成
rm -rf ./denyssllist
touch ./denyssllist

#########このシェルスクリプトは、必ずきちんとしたiptablesの設定を読み込んでから実行###################
#SSLをはじくurlを書いたファイル「denysslURL」を読み込んで、ipアドレスをdenyssllistに書き込む
############################
if [ -s ./denysslURL ]; then
  for dnysslurl in `cat ./denysslURL`; do
     host -W 2 $dnysslurl | grep "has address " | cut -d' ' -f4 >> ./denyssllist
  done
fi

host命令にに-W 2が入っているのは、もしurlが値を返さなかった場合（筆記ミスとか、休止したとか）、凄く待たされるので、2秒経ったら諦めるようにしているということ。
そこからの

iptables -N IPDENYSSL
iptables -A IPDENYSSL -j LOG --log-tcp-options --log-ip-options --log-prefix '[IPTABLES IPDENYSSL]: '
iptables -I IPDENYSSL -j DROP
if [ -s ./denyssllist ]; then
  for denysslip in `cat ./denyssllist`; do
   iptables -I FORWARD -s 192.168.168.0/24 -d $denysslip -p tcp --dport 443 -j IPDENYSSL
  done
fi

みたいな。
これで安心してdropboxを蹴り出せるし、何よりLINEの認証を止められる。
LINEはサーバに繋ぎすぎ。
0点。

シェルスクリプトの突っ込み大歓迎です。多分もっと短くなるはずなので。というか、眠い・・・・・。

追記

#!/bin/sh

################################
#

mv /usr/local/sbin/denyssllist /usr/local/sbin/denyssllisttmp

############################
#change URL(need file  >>>   denysslURL
############################
if [ -s /usr/local/sbin/denysslURL ]; then
  for dnysslurl in `cat /usr/local/sbin/denysslURL`; do
     host -W 2 $dnysslurl | grep "has address " | cut -d' ' -f4 >> /usr/local/sbin/denyssllisttmp
  done
fi

#########
#
#facebook
#echo "31.13.64.0/18" >> /usr/local/sbin/denyssllist
#dropbox
echo "108.160.0.0/16" >> /usr/local/sbin/denyssllist
#LINE
echo "119.235.235.91" >> /usr/local/sbin/denyssllist

##################
#SORT&UNIQ
##################
sort /usr/local/sbin/denyssllisttmp > /usr/local/sbin/denyssllist
rm -f /usr/local/sbin/denyssllisttmp

 これはcron.dailyに読ませる

torからのアクセスだったりをiptablesで検知・拒否して接続させないようにしたい

何か物騒な世の中なので、一応対策らしいものもしなければ、ということで、iptablesで拒否してみることにした。
iptablesにはいつも通りシェルスクリプトで読ませることにする。

この前
http://roserogue.blogspot.jp/2014/01/centosiptablesip.html
で海外からのアクセスを禁止したい記事を入れたのでこちらも参照のこと。

参考は
http://d.hatena.ne.jp/rudeboyjet/20070226/p1

内容としては、IPDENYTORという名前のユーザー定義チェインを作成（-N）して、
ログを取りアクセスはドロップする設定を書き、
if文で/root/denytorlistの中に書いてあるIPアドレスをDROPする。

vi /root/iptables_denytor.sh

#!/bin/sh
################################################
#DENY TOR
################################################
iptables -N IPDENYTOR
iptables -A IPDENYTOR -j LOG --log-tcp-options --log-ip-options --log-prefix '[IPTABLES IPDENYTOR]: '
iptables -A IPDENYTOR -j DROP
if [ -s /root/denytorlist ]; then
  for ip in `cat /root/denytorlist`; do
    iptables -A INPUT -s $ip -j IPDENYTOR
  done
fi

chmod 700 /root/iptables_denytor.sh

denytorlistという、torのIPアドレスを貼り付けたものを作る

touch /root/denytorlist
vi /root/denytorlist

ipアドレスは、以下のサイトからIPアドレスのcsvを取ってきて貼る。
http://torstatus.blutmagie.de/index.php
csvへの直リンクが出来なそうなので、wgetで取得するのは無理そう？

chmod 700 /root/denytorlist

あとは/etc/rc.d/rc.localに

sh /root/iptables_denytor.sh

を入れればOKのはず。

ただ、読ませるのに相当時間がかかるので、これやる必要あるのか？というのも勿論ある。
まあ禁止リストの一環と思えば・・・。

修正。
denytorlistは実行できん・・・多分脳が寝ていた。。

兎に角海外からのアクセスを制限、遮断したい（centos上でiptablesを使ったIPアドレスアクセス制限）

サーバ立てていると、兎に角どこから沸いてきたのか辞書攻撃をばんばんする輩がいる。
勘弁してください・・・ddosとか掛けられると速攻落ちるくらいの貧弱スペックで運用してる奴に限って、
何故か半端ない・・・。





環境は
centos（サーバはcentos5とcentos6）とiptables。


hosts.allowとhosts.denyで制限するという方法も散見されたが、正直どうだろう。
正しいと思うけど、複雑なことをさせようとすると凄いことになりそう。

で、その対処法。
まず考えたのは、SSHを通しているので、こいつに辞書攻撃を仕掛けられていること。

http://blog.browncat.org/2007/07/sshiptables2.html

を参考に、2行書いてやればかなり収まる。
60秒間に8回SSH接続しようとしたIPをはじく、とある。

-A RH-Firewall-1-INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
-A RH-Firewall-1-INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

がcentosには適応する。

が、それだけでは怒りが収まらない。
こうなったらと、日本以外の外国からアクセスを遮断することにする。

http://vogel.at.webry.info/201306/article_1.html
と
http://vogel.at.webry.info/201306/article_2.html
を参考に（というか丸パクりして）設定。

以下は僕の環境下で使ったmemoなので、ちゃんとしたものと解説はURLの方参照してください。

#!/bin/sh
#COPYRIGHT
#http://vogel.at.webry.info/201306/article_1.html
#http://vogel.at.webry.info/201306/article_2.html
#http://blog.browncat.org/2007/07/sshiptables2.html
IPTABLES=/sbin/iptables
if [ $# -eq 1 ]
then
    if [ $1 = "stop" ]
    then
        $IPTABLES -F
        $IPTABLES -Z
        $IPTABLES -X
        $IPTABLES -P INPUT ACCEPT
        $IPTABLES -P OUTPUT ACCEPT
        $IPTABLES -P FORWARD DROP
        echo stopped..
        exit
    fi
fi
$IPTABLES -F
$IPTABLES -Z
$IPTABLES -X
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -N ACCEPT_FILTER
$IPTABLES -A ACCEPT_FILTER -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state NEW,ESTABLISHED -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type source-quench -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type redirect -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT

$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT_FILTER

$IPTABLES -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

#SSH Accept(上2行は別から）
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT_FILTER

#WWW Accept
#$IPTABLES -A INPUT -p tcp -m multiport --dport 80,443 -m state --state NEW -j ACCEPT_FILTER

#日本のIPからのみアクセス出来る
wget -N http://nami.jp/ipv4bycc/cidr.txt.gz
gunzip -q -f -c cidr.txt.gz > cidr.txt
if [ -f cidr.txt ]; then
    $IPTABLES -F ACCEPT_FILTER
    sed -n 's/^JP\t//p' cidr.txt | while read address; do
        $IPTABLES -A ACCEPT_FILTER -s $address -j ACCEPT
    done
    $IPTABLES -A ACCEPT_FILTER -j DROP
fi
#eof

シェルスクリプトなので、実行可能な場所において、ファイル名.shで保存（もういっそ/rootとか）、
chown root.
chmod 700
(rootの持ち物（ドットまで入れるとグループもrootになる）で、アクセス権はルートのみフルアクセス）
/etc/rc.d/rc.local
に
sh /ファイルまでの絶対パス/ファイル名.sh
とかの形式で書いてやれば、起動時に読み込んでくれる。

これで収まった。
味噌は、有志がIPアドレスレンジのファイルを公開してくれてるところ。凄いよなあ・・・。

追記
torのアクセス遮断を別記事で

port53番ポートが兎に角開かない（iptablesでは開放しているのに、外から見ると閉じている）

CentosにBINDを突っ込んで設定していたところ、どうしても53番ポートが開かない。
というか、サーバ的には53番は開放しているのだけれども、外から見た場合、closedに見えるという切ない状況。
iptablesとしては、53番開放済み。
nmapをわざわざインストールして見ても、53番は開いている。
dig @192.168.XXX.XXX google.com（XはサーバのIP） も通る。
でも外からwindowsで見た場合、
nslookup google.com 192.168.XXX.XXX
はタイムアウトするし、windowsからnmapでサーバを見ても、port 53はclosed。
困りに困ってまたまたgoogle先生にお伺いを立て続けたところ、

http://q.hatena.ne.jp/1296524427

が出てきた。

named.conf に

listen-on port 53 { 127.0.0.1; };

という行がありませんか？ つまり、localhost のインタフェースでしか Listent していない状態です。
この行を外せば、全てのインタフェースで Listen するようになります。

間違いない。
これのせいだ。ということで、
vi /etc/named.conf

で
// listen-on port 53 { 127.0.0.1; };
という風にコメントアウト。
無事外からも見えるようになりましたとさ。

ただ、ポートがふさがっているということになると、やはり疑うのはfirewall。
iptablesの内容を何度もさらった。

iptables -A INPUT -p udp -s $internal_ip --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp -d $internal_ip --sport 53 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -s $internal_ip --dport 53 -j ACCEPT

で大丈夫なんだろうけど、もっと良い書き方有ったら教えてください。

また、named.confにforwardの設定をしているのだけれど、

Nov 14 21:50:40 servername named[1876]: error (no valid DS) resolving 'XXX.XXX.168.192.in-addr.arpa/PTR/IN': 8.8.4.4#53
Nov 14 21:50:40 servername named[1876]: error (no valid RRSIG) resolving '168.192.in-addr.arpa/DS/IN': 8.8.4.4#53
Nov 14 21:50:40 servername named[1876]: error (no valid RRSIG) resolving '168.192.in-addr.arpa/DS/IN': 8.8.8.8#53

 みたいなログをmessagesに吐き出されてげんなり。
8.8.8.8と8.8.4.4と192.168.XXX.XXX
をforward先として設定しているのだけれども、全部エラー。しかもgoogle先生教えてくれない。

追記
と思ったら出てきた。
http://jsapachehtml.hatenablog.com/entry/2014/01/13/113229

ということで、DNSSECの問題らしい。が、それはそれで気持ち悪いなあ・・・。
named.confを書き換える。

vi /etc/named.conf

dnssec-enable no;
dnssec-validation no;
//dnssec-lookaside auto;

chrootしている場合はファイルの場所が違うので注意。

名前の解決は出来るがpingが通らない

久しぶりにやらかした。


NICが2つあるマザーでゲートウェイを組もうとしていた。
DNSリゾルバを組み込もうとしたところで躓く。
何故かpingが通らない。
そして名前も引けない。
ここでの解法は簡単な物だった。
namedを設定する直前に、squidプロキシの設定やらがちがちの禁止事項を盛り込んだiptablesのシェルスクリプトファイルを読み込んだからである。
そこまでは良かった。
そしてそこからが大変だった。
取り敢えず物理的環境を実運用スタイルにと思い、

インターネット
│
ルータ（192.168.69.1）
│
eth0（192.168.69.2）
│
ゲートウェイサーバ本体
│
eth1（192.168.96.1）
│
ハブ
│
設定用ノートPC（192.168.96.2)

という構成にしたところ、
素の状態で、何故かgoogle.comにpingが通らない。
何をしても通らない。
iptablesを落とし、selinuxを落としても直らない。
 だがdigするとgoogle.comの名前は引ける。
ルータ（192.168.69.1）にもpingが通る。
でもdigで引けたgoogleにpingが通らない。
ルータにノートを直づけすると、勿論gogle｡comは通る。

名前は解決できているので、少なくともサーバはルータには繋がっている。
ルータはgoogle.comに繋がっている。
 でもサーバからgoogleにpingが通らない。
ある意味「半分繋がっている」、という不思議な状態。
経路の問題というのは分かるのだけれども、tcpdumpを眺めても特になく。

嫌な感じがして、わざわざgnome環境をサーバに入れてみたところ、
サーバ上のfirefoxでもgoogle.comに繋がらない。
意味が分からない・・・。

やはりそこはgoogle先生にということでお伺いを立て続けると、

http://okwave.jp/qa/q7244798.html

が。

外部、というのが202.xxx.xxx.xxx/28や192.168.xxx.xxx/24以外のネットワークだとしたら当然そうなります
デフォルトルートが2つ設定されていますが、実際に有効になるのは片方だけなので

ネットワークのあて先がわからないときの最終的なパケットの投げ先がデフォルトゲートウェイなので、そんなものが2つあっても片方にしか投げられないのが原因
片方のデフォルトゲートウェイを残し、もう片方のNICに対しては必要な分のスタティックルーティングを設定すべきです

まるっきり状況が同じ。

要は、eth0とeth1に、別のゲートウェイを指定していたためにこうなってしまったのである。

実はeth1は、元から有る環境に接続するため（ぶら下がるために）IPアドレスは、
192.168.96.1ではなく、192.168.96.20だった。なので、eth1にはGATEWAY=192.168.96.1が設定されていた。

上記のような環境にするために、eth0にGATEWAY=192.168.69.1を設定したにもかかわらず、
eth1のGATEWAYが優先され、本来GATEWAYとして通らなければならない192.168.69.1は無視されたと。

要は、一番初っ端のネットワーク設定をしくじっていたということである。
eth1のGATEWAY記述を192.168.69.1にすることで一応の解決を見た（これ消した方が良いのかしらん）が、
全く気付かなかった・・・。

sambaで待たされる（異常に遅い）現象について

この概要は表示できません。投稿を閲覧するには ここをクリック してください。