ここしばらくは

ここしばらくは、ツイッター(microblogging)ばかり更新していたのだけれど、思ったことを少し。

すごく、怨嗟の言葉が多いです。

愚痴を吐き出す場所という感じ。
僕自身がそういう使い方をしなかったわけでもないけど、そればっかりが増幅するので精神に影響をきたしそう、という感触があった。

いろいろ考えてたらマイナス思考になっていたので、それは全部カット。

Twitter は感情の増幅回路。

言い得て妙。

amazonaws を iptables で拒否

自宅サーバで公開しているサイトへの amazonaws からのアクセスが、かなりうざい。

amazonaws は、amazon がサービスしているウェブサービス aws からのアクセスとのこと。
そのサービスを使ってアクセスしてきているのは理解したけど、まともにページを表示するようなマネはしていなかった。
具体的には /js/lightbox.min.js のような、Web サービスを行うためのスクリプトだけが狙われてた。
思うに、google アナリティクスのようなサービスに検知されないための処理なんだろう。
あれは通常のページを開いて解析サイトにトラフィックを飛ばさないと解析できないもんだろうし。
それに、普通のユーザはコンテンツをすっ飛ばしてサイト情報を集めたりはしない*1

うん。これは amazonaws を拒否しておこう。

とは思ったものの、IPアドレスの範囲はかなり広い上に細かい。
なので、iptables で拒否するのを躊躇していたんだけど、amazon で情報が出てた。

https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html

Amazon Web Services (AWS) は、その現在の IP アドレス範囲を JSON 形式で公開します。現在の範囲を参照するには、.json ファイルをダウンロードします。

ということなので、時々チェックしないとダメみたい。
とりあえず肝心のデータは、次の URL で取得できた。

https://ip-ranges.amazonaws.com/ip-ranges.json

とはいえ、僕は JSON 形式のデータを解析する方法を知らないんだけど……
と思っていたら、同じページに jq コマンドによる解析例があった。
素晴らしい。

jq コマンドって、リポジトリにあるかな?

$ type apt-file || sudo apt install apt-file
$ sudo apt update
$ sudo apt-file search jq | grep "\/jq$"
jq: /usr/bin/jq

あった。

$ sudo apt install jq
(以下略)

うん、さくっとインストールできた。

次に、上記サイトで「例 3.すべての IPv4 アドレスを取得します」とのサンプルがあるので、試しに参照してみる。

$ wget -q -O /tmp/ip-ranges.json https://ip-ranges.amazonaws.com/ip-ranges.json
$ jq -r '.prefixes | .[].ip_prefix' < /tmp/ip-ranges.json
18.208.0.0/13
52.95.245.0/24
99.77.142.0/24
52.194.0.0/15
54.155.0.0/16
54.196.0.0/15
99.78.170.0/23
52.94.22.0/24
52.95.255.112/28
(以下略)

かなり長いな……
ってことで、行数をカウント。

$ jq -r '.prefixes | .[].ip_prefix' < /tmp/ip-ranges.json | wc
   1682    1682   25080

……重複とか、無いよね?
少し表示された内容を読んでて、重複がありそうだったので確認してみる。

$ jq -r '.prefixes | .[].ip_prefix' < /tmp/ip-ranges.json | sort -un | wc
    360     360    5140

……えーと。
こんなに重複があるとか、なんかの嫌がらせ?
と一瞬思ったけど、リージョン違いによる重複なんだろうな。

create-time を見れば更新されているかどうか分かるとのことなので、定期的に観測するなら create-time を参照すればよさそう。
このサイトだと、また amazonaws がログに表示されるようになったら更新を掛ける程度で。
Raspberry Pi だから、ファイルの更新が結構致命傷に繋がりやすいんだよね……。

iptables への設定については、シェルの for 文で一括登録しておく。

$ pTarget="$(jq -r '.prefixes | .[].ip_prefix' < /tmp/ip-ranges.json | sort -un)"
$ for s in ${pTarget}
do
  sudo iptables -A OUTPUT -d ${s} -o eth0 -j DROP
done
$ sudo iptables -n -L

確認コマンドとして iptables -L だけだと、名前の逆引きが行われてかなり表示が遅くなったので -n を加えた。

しばらく様子見。


あと、分割された CIDR をコマンドラインでまとめ直す方法があれば、調べておきたい。
たとえば、こんな CIDR 表記。

52.56.0.0/16
52.57.0.0/16
52.58.0.0/15
52.60.0.0/16
52.61.0.0/16
52.62.0.0/15

これって、連続してるんだから、CIDR として次のように書けるはずなんだよね。

52.56.0.0/13

もしかすると、IPアドレス 10 個をネットワークアドレス/ブロードキャストアドレスに消費しているのかもしれないけど、サイト管理者としては設定行数が増えるだけなのでメリットを感じられない。

*1:例を言えば、天気を知りたいのに、予報ではなく予報サイトの構成から調べるとか、なかなかトリッキーな性格の持ち主と思われる。

debian 系 iptables 設定

自宅サーバで公開しているサイトへの SEO 関連の robot である semrush.com からのアクセスが、少しうざい。
(SEO 関連のロボットであるという根拠は、リファラー内情報 https://www.semrush.com/bot/ に記載されている)

robots.txt でクローリングを拒否しているけど、その robots.txt 自体はアクセス拒否ができない。
(これを拒否すると、アクセス拒否を伝えられない)

しばらく放置していたけど、/robots.txt へのアクセスが連日あるので iptables で拒否設定しようと思った。

まず、semrush.com が保有している IP アドレス帯域の調査から。

https://awebanalysis.com/ja/ip-lookup/46.229.168.158/

46.229.160.0/20 の帯域は、オランダに割り当てられている模様。
ちょっと範囲が広すぎるので、もう少し狭めてみる。

ドメイン名・IPアドレス検索 (ANSI Whois) - Asuka.IO

ここで、IPアドレスを入力。

https://ja.asuka.io/whois/46.229.168.149

一部を抜粋。

inetnum: 46.229.168.0 - 46.229.169.255
netname: ADVANCEDHOSTERS-NET
descr: Advanced Hosters B.V.
country: US
admin-c: AH36-RIPE
tech-c: AH36-RIPE
status: ASSIGNED PA

ふむ。
46.229.168.0/23 の帯域で、アメリカに割り当てられていることは分かった。

いったん、46.229.168.0/24 の帯域で、まるっと逆引きしてみる。

# for i in {1..254}; do
>   tmp=$(dig -x 46.229.168.$i +short)
>   if [ -n "$tmp" ]; then
>     echo "### 46.229.168.$i ### ${tmp}"
>   fi
> done
### 46.229.168.11 ### docker6-iad.ag1.thousandeyes.com.
### 46.229.168.14 ### ns2.z5o.net.
### 46.229.168.26 ### turanga-leela.ompr.io.
### 46.229.168.27 ### amy-wong.ompr.io.
### 46.229.168.49 ### leela.ompr.io.
### 46.229.168.56 ### mx3.xyzsmtpservice.com.
### 46.229.168.57 ### mx2.thewebsupports.su.
### 46.229.168.129 ### crawl1.bl.semrush.com.
### 46.229.168.130 ### crawl2.bl.semrush.com.
### 46.229.168.131 ### crawl3.bl.semrush.com.
### 46.229.168.132 ### crawl4.bl.semrush.com.
### 46.229.168.133 ### crawl5.bl.semrush.com.
### 46.229.168.134 ### crawl6.bl.semrush.com.
### 46.229.168.135 ### crawl7.bl.semrush.com.
### 46.229.168.136 ### crawl8.bl.semrush.com.
### 46.229.168.137 ### crawl9.bl.semrush.com.
### 46.229.168.138 ### crawl10.bl.semrush.com.
### 46.229.168.139 ### crawl11.bl.semrush.com.
### 46.229.168.140 ### crawl12.bl.semrush.com.
### 46.229.168.141 ### crawl13.bl.semrush.com.
### 46.229.168.142 ### crawl14.bl.semrush.com.
### 46.229.168.143 ### crawl15.bl.semrush.com.
### 46.229.168.144 ### crawl16.bl.semrush.com.
### 46.229.168.145 ### crawl17.bl.semrush.com.
### 46.229.168.146 ### crawl18.bl.semrush.com.
### 46.229.168.147 ### crawl19.bl.semrush.com.
### 46.229.168.148 ### crawl20.bl.semrush.com.
### 46.229.168.149 ### crawl21.bl.semrush.com.
### 46.229.168.150 ### crawl22.bl.semrush.com.
### 46.229.168.151 ### crawl23.bl.semrush.com.
### 46.229.168.152 ### crawl24.bl.semrush.com.
### 46.229.168.153 ### crawl25.bl.semrush.com.
### 46.229.168.154 ### crawl26.bl.semrush.com.
### 46.229.168.155 ### crawl27.bl.semrush.com.
### 46.229.168.156 ### crawl28.bl.semrush.com.
### 46.229.168.157 ### crawl29.bl.semrush.com.

おー。
見事に semrush.com が利用中なIPアドレスが表示されたね。

46.229.168.129 ~ 157 の 29 個ということは、おそらく /27 の 32 個を確保しているんじゃないかな……という予測がたつ。

46.229.168.128 は、おそらくネットワークアドレス
46.229.168.159 は、おそらくブロードキャストアドレス

TCP/IP の CIDR から、こうであろうという予測。

……46.229.168.158 だけが宙に浮いてるけど、この IP アドレス帯域を利用しているのは、上記の割当情報から US であり、つまりはアメリカの人たち。
サイトは日本語しかないし、拒否しても大丈夫かな?

一応、何に使われているのか調査してみる。

46.229.168.158 への ping は、応答あり。なきゃ良かったのに……
ICMP の他、www とか ssh とか 応答なし。

ん~、これに関してのみ、とりあえず許可する方向でいくか。


ということで、設定内容としては 46.229.168.128/27 を Drop することに。
ただし様子見のため、拒否設定の save はしない。
46.229.168.158 は ACCEPT を入れる。

それでは、拒否設定の投入。

# iptables -A OUTPUT -d 46.229.168.128/27 -o eth0 -j DROP
# 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
DROP       all  --  anywhere             46.229.168.0/24
#
# iptables -A OUTPUT -d 46.229.168.158/32 -o eth0 -j ACCEPT
# 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
DROP       all  --  anywhere             46.229.168.128/27
ACCEPT     all  --  anywhere             46.229.168.158
# 

ここまで設定してから「DROP と ACCEPT の優先順位ってどうなってたっけ?」と思って、ググってみた。

参考サイト様

https://www.virment.com/iptables-setting-example/

……見事に逆順で設定してたね。

初期化したいときは --flush か -F を使う。

# iptables -F
# 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
#

初期化できた。

# iptables -A OUTPUT -d 46.229.168.158/32 -o eth0 -j ACCEPT
# iptables -A OUTPUT -d 46.229.168.128/27 -o eth0 -j DROP
# 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
ACCEPT     all  --  anywhere             46.229.168.158
DROP       all  --  anywhere             46.229.168.128/27
#

順番が入れ替わってるね。

さて、しばらくこれで様子見。



一応、保存したくなった時のことを考えて、調べておく。

環境としては Raspbian を利用している。

# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

で、いろいろググってみたんだけど、RHEL (CentOS) の情報が多くて、適用できるかどうかが不明だった。
いちおう、これなら大丈夫かなという参照先を。

参考サイト:
https://wiki.debian.org/iptables

ここで書かれている iptables 設定情報の保存方法は2通り。

一つ目は、シェルスクリプトを作って起動時に読み込ませる方法。

Debian では、保存先のファイルを /etc/iptables.up.rules としているみたい。
すでに iptables コマンドで設定しているときは、iptables-save の標準出力を、ファイルにリダイレクトする。

# # ls -l /etc/iptables.up.rules
ls: '/etc/iptables.up.rules' にアクセスできません: そのようなファイルやディレクトリはありません
# iptables-save > /etc/iptables.up.rules

で、これをリストアするときは、次の簡単なシェルスクリプトを書けと。

/etc/network/if-pre-up.d/iptables

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules

二つ目は、管理パッケージを使う方法。

iptables-persistent

# apt-cache search iptables-persistent
iptables-persistent - boot-time loader for netfilter rules, iptables plugin
netscript-ipfilter - Linux 2.6/3.x iptables management system.

「boot-time loader for netfilter rules, iptables plugin」は、意訳すると「起動時にフィルタルールを読み込む iptablesプラグイン」かな。

これをインストールしてから、次のファイルを作る。

iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6


うーん、やるならパッケージのインストールかな?

# dpkg -l iptables iptables-persistent
要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)トリガ待ち/(T)トリガ保留
|/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常)
||/ 名前                 バージョン      アーキテクチャ  説明
+++-====================-===============-===============-==============================================
ii  iptables             1.6.0+snapshot2 armhf           administration tools for packet filtering and
dpkg-query: iptables-persistent に一致するパッケージが見つかりません

ということなので、自分がやるなら次の手順。

$ sudo su -
# apt-get update
# apt-get install iptables-persistent
# 
# iptables -F
# iptables -A OUTPUT -d 46.229.168.158/32 -o eth0 -j ACCEPT
# iptables -A OUTPUT -d 46.229.168.128/27 -o eth0 -j DROP
# iptables -L
# 
# iptables-save > /etc/iptables/rules.v4
# ip6tables-save > /etc/iptables/rules.v6
#
# exit
$

Windows 10 は、ログインしておかないと RDP できない?

念のために、一度 Windows 10 を再起動して RDP を試してみた。
なんと ping に応答しない。
もちろん RDP では接続できない。

コンソールでログインしてから RDP すると、なんと接続できた。

もう一度 Windows 10 を再起動して、ping を流し続けてみたところ、コンソールログインして数分後でないと ping に応答してくれなかった。

コンソールログインしていないと、いろいろ動いてくれないとか。


まぢかよ!!
うがー!

追記。

もう一度 ping を打ちつつ Windows 10 を再起動してみたところ、ping が応答してくれた。

およ?

で、RDP は接続……できないよねえ。
念のため、コマンドプロンプトから mstsc /admin /v:xx.xx.xx.xx でアクセスしてみたら、なんと接続できた。

Windows 10 の挙動、意味が分からなすぎる!

さらに追記。

検証として、もう一度 Windows 10 を再起動。
ping が応答するまで待ってから、RDP 接続しても NG だったものの、もうしばらく待ってからもう一度普通に RDP すると、今度は接続できた。

Windows 10 が起動してから、各種サービスが起動するまでは、かなりのタイムラグがあるように見える。
スペック的には、

CPU Intel CORE i7-4790
メモリ 16 GB
SSD 110GB (空き容量22GB)

なので、そう悪くはないはず。

むぅ。

Windows Update の弊害?

Windows Update の弊害?

この間、Windows を、バージョン 1903 にアップデートした。

その直後だけはリモートアクセスできて安心していたんだけど、その後全く応答がなくなってしまった。

結論からいうと、イーサネット設定(有線LAN)が、プライベートネットワークからパブリックネットワーク接続に書き変わっていた。

以下、その原因究明と対処のあれこれ。

続きを読む

banner コマンドを使う

banner コマンドを使いたいと思ったけど、Raspbian にはインストールされてなかった。

ということで banner コマンドが含まれるパッケージを調べる。

事前設定

$ sudo apt install apt-file
$ sudo apt update

banner コマンドが含まれるパッケージの調査

$ sudo apt-file search banner | grep "\/banner$"
afterstep-data: /usr/share/afterstep/banner
afterstep-data: /usr/share/afterstep/ucf/banner
album-data: /usr/share/doc/album-data/examples/banner
eggdrop-data: /usr/share/eggdrop/text/banner
epic4-help: /usr/share/epic4/help/4_Misc/set/banner
fortunes-it: /usr/share/games/fortunes/banner
fortunes-it: /usr/share/games/fortunes/it/banner
qt4-demos: /usr/lib/qt4/examples/declarative/text/fonts/banner/banner
surfraw: /usr/share/doc/surfraw/banner
sysvbanner: /usr/bin/banner
$ 

ということで、sysvbanner をインストールすれば良さそう。

$ sudo apt-get install sysvbanner
$ banner test

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

使用例

うまくいったので、/etc/motd に書き込む。

$ sudo cp -p /etc/motd{,_$(date +%Y%m%d)}
$ ll /etc/motd*
-rw-r--r-- 1 root root 286  728  2017 /etc/motd
-rw-r--r-- 1 root root 286  728  2017 /etc/motd_20190704
$ sudo banner $(uname -n) > /etc/motd
-bash: /etc/motd: 許可がありません

えぇぇぇぇぇ!?

$ sudo su -
# banner $(uname -n) > /etc/motd
# cat /etc/motd
(出力内容は省略)
# ls -l /etc/motd*
-rw-r--r-- 1 root root 390  74 12:01 /etc/motd
-rw-r--r-- 1 root root 286  728  2017 /etc/motd_20190704
# exit
$

なぜうまくいく?

root.hint の謎なアップデート

昨日、DNSOPS summer 2019 に参加して、自宅 DNS を参照していた。
で、DNS を構築して以来、ルートヒントを更新してなかったなぁと思い出して、ちょっと見てみた。
BIND のルートヒント(named.cache) がアップデートされているようだったので、どんだけ差分があるんだろうと思ったけど……

# cd /tmp
# wget https://www.internic.net/domain/named.cache
# cd /etc/bind/zonefiles
# diff db.root /tmp/named.cache
12,13c12,13
< ;       last update:     November 16, 2017
< ;       related version of root zone:     2017111601
---
> ;       last update:     June 27, 2019
> ;       related version of root zone:     2019062701
92c92
< ; End of file
---
> ; End of file
\ ファイル末尾に改行がありません
#

差分どこー?