FreeBSD11 から NetBSD由来の blacklistd が導入されました。
AWS/EC2 や、Google Cloud Platformの FreeBSD11イメージをつかってインスタンスを作成するだけでデフォルト環境についてきます。OSの導入一切が住んでいればサードパーティのソース・バイナリファイルを加える必要がなく、起動時のファイル設定が済めばすぐに動かすことができます。実運用を行った上で気がついた点を書いておきます。
ブロック状況について
運用までの方法は多く記述されているので割愛します。調べてください。
日曜日09:00から月曜の17:00まで、30時間前後、稼働させてみて
この程度拾ったようです。何も動いていなのに律儀に来ますね。
kujiradensan-freebsd11# blacklistctl dump -a
address/ma:port id nfail last access
191.187.110.45/32:22 1/3 2018/03/25 09:08:36
180.68.180.58/32:22 OK 4/3 2018/03/25 16:49:53
121.160.188.114/32:22 1/3 2018/03/25 21:21:12
177.125.21.86/32:22 1/3 2018/03/25 21:21:06
5.101.40.10/32:22 OK 4/3 2018/03/25 23:51:11
171.96.24.107/32:22 OK 4/3 2018/03/25 09:02:13
178.120.138.170/32:22 1/3 2018/03/25 09:08:16
113.190.58.182/32:22 1/3 2018/03/25 21:21:19
42.159.246.3/32:22 OK 4/3 2018/03/25 13:41:06
219.147.95.246/32:22 OK 4/3 2018/03/26 08:12:16
156.218.104.230/32:22 1/3 2018/03/25 09:08:04
kujiradensan-freebsd11#
非公開のサーバですらクラウドでのデフォルト設定だと、ほぼこの程度の
provingがあるので、443/tcpなどを開けておくと増える気がします。
ssh で大穴を開けているケースが過去に多くあったことを考えると
永遠にこの手の詮索からは逃れようがありません。
副作用
AWS/GCPの環境の問題ではなく、おそらく利用する側のラストワンマイルに起因する何らかの理由で回線状況が悪化すると、（使用する端末の設定次第ですが） ssh の再接続を試みることがあります。
その際成功しなかった試行でブラックリストに乗ってしまったか、またはそれ以前にテストなどで”わざと”失敗した場合、blacklistに乗ってしまった IPアドレスから再び接続しようとするのは、設定次第ですが待たされます。
blacklistd に補足されていなくても、何らかの理由で接続ができなくなってしまい、ブラックリストから明示的に削除することが出来ません。
回避措置
service blacklistd stop
/usr/sbin/blacklistd -f
service ipfw restart
service blacklistd restart
blacklistd のみならず、ipfw を再起動する必要があるのはハマりどころです。
一回リストに乗ってしまうと、flush しても実績が残っているのか、再び繋がらなくなってしまいます。/var/run/blacklist.db にどのように記録されているのか、操作するツールはバンドルされてきませんでした。（つくればいいのかもしれない）
解決方法
ただ単にホワイトリストをつくって /etc/blacklistd.conf に入れておけば終わりです。
当たり前ですが、最初にやっておけば副作用は出ません。代わりにブラックリストができるのかをテストは出来ません。
# Block ssh, after 3 attempts for 6 hours on the bnx0 interface
[local]
# location type proto owner name nfail duration
bnx0:ssh * * * * 3 6h
[remote]
# Never block 1.2.3.4
1.2.3.4:ssh * * * * * *
# For addresses coming from 8.8.0.0/16 block class C networks instead
# individual hosts, but keep the rest of the blocking parameters the same.
8.8.0.0/16:ssh * * * /24 = =
雑感
マニュアルを読めば分かる話で恐縮ですが、やはりホワイトリスト設定を行うのは安全のために推奨になるようです。 GCPはコンソール接続を持っているので ssh（の接続設定など） が死んでもまだ奥の手があるというかんじですが、AWS/EC2では ssh だけが頼みの綱なので、設定を消したり壊してしまうと以下の手順でリカバリ作業に突入することになるでしょう。無論、Ansibleなどで「さっくり更地から復帰してデータもバックアップからぽちっとな」というのもある種の理想であるのですが、レガシーな復旧手順も一応あるにはあります。復旧手順もAnsibleの脚本を書くという話が当然あるんでしょうが、これはまたいずれ別のときに（笑）
別のインスタンスを複製
当該インスタンスの起動ボリュームをマウント
ともあれ、人はしばしば間違いを犯す生き物、しくじりになれるのは大事なので、何でもない遊休インスンタンスで十分訓練しておいたほうがいいかもです（笑）
そもそもの動機
今回運用は blacklistd にすべて預けても問題ないかを確認するためです。
筆者はFreeBSD移行の15年来、デフォルトの sshd だけで運用することはせず、ucspi-tcp/tcpserver( inetd の代わりになるもの）を用いてきました。その為この手のブラックリスト作成を行わず、ホワイトリストのみ運用をしていましたが、世の中の人は、どうもブラックリストを作るほうが好きなようですので、
”どんなものかという興味” と
”モバイル端末で管理・開発環境を持つため”
という現実的な課題のためにテストをしたものです。リモートアクセスを確実にするにはVPNを構築するのが筋でしょうが、開発と管理であれば sshトンネル で十分仕事になります。
謝辞
役に立たない記事で申し訳ありません。次は、knockd などの導入と合わせ技、tcpserver で deny した結果を用いてblacklistdの早期警戒（sshでアクセスしてくるやつが80/tcp,443/tcpに行けないようにする）ような実験を行うつもりです（いつになるか）