ホーム » コンピュータ » Network (ページ 2)

Network」カテゴリーアーカイブ

システム

最近の投稿

アーカイブ

カテゴリー

FortiGuard Web Filter

自宅サーバで CTF 問題とかを公開している中、nmap の実験で自宅サーバをチェックすることがあるけど、8008, 8010 とかのポートが表示されるのが気になっていた。

$ nmap tsaitoh.net
Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-06 14:12 JST
PORT     STATE  SERVICE
(略)
8008/tcp open   http
8010/tcp open   xmpp
8022/tcp closed oa-system
8080/tcp closed http-proxy
Nmap done: 1 IP address (1 host up) scanned in 4.35 seconds

自宅のサーバでは、FireWall でポート制限しているし、対外接続のルータでも、特定のポートだけ DMZ 設定などでサーバに接続できるようにしていた。CTF の問題作る中で一時的に開いたものかと思ってた。

FortiGuard WebFilter

でも改めて http://tsaitoh.net:8008 とかしてみたら、下記の画面が表示された。どうも自宅のルータより外部の丹南ケーブルテレビ側のルータで、FortiGuard の WebFilter が動いているかと思われる。

そこで、”traceroute tsaitoh.net” を実行すると表示される自宅サーバの一つ手前のルータ?を調べてみる。

$ traceroute 64.33.3.150
traceroute to 64.33.3.150 (64.33.3.150), 30 hops max, 60 byte packets
(略)
 9  218.100.9.53 (218.100.9.53)  10.949 ms  10.658 ms  10.647 ms
10  core-sw2-e-5.ntwk.ttn.ne.jp (202.127.81.22)  16.457 ms
    core-sw1-e-5.ntwk.ttn.ne.jp (202.127.81.10)  16.535 ms  16.526 ms
11  ftth-sw1-po-2.ntwk.ttn.ne.jp (202.127.81.30)  25.875 ms  26.144 ms
    ftth-sw1-po-1.ntwk.ttn.ne.jp (202.127.81.26)  22.889 ms
12  olt1-la-1.ntwk.ttn.ne.jp (202.127.81.34)  20.911 ms  20.902 ms  37.585 ms
(略)

試しに、”nmap 202.127.81.34″を実行すると同様に 8008,8010 ポートが開いている。

$ nmap 202.127.81.34
Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-06 14:35 JST
Nmap scan report for olt1-la-1.ntwk.ttn.ne.jp (202.127.81.34)
Host is up (0.0039s latency).
Not shown: 995 filtered ports
PORT     STATE  SERVICE
80/tcp   open   http
113/tcp  closed ident
443/tcp  open   https
8008/tcp open   http
8010/tcp open   xmpp

そこで、このルータに同様に http://202.127.81.34:8008 にブラウザでアクセスしても最初のような、FortiGuard の表示となった。ということで、8008,8010 は、FortiGuard で WAF(Web Application firewall) が設定されているのが原因と思われる。

WebFilter 廃止になるのかな?

ただ、丹南ケーブルにて「安心インターネットサービス停止」のアナウンスが出ている。会員向けのProxyサーバの運用停止の案内だけど、これも影響するのかな。どちらにしろ、2023/1/15(日)になれば分かるかな。

Edgerouter-X が寿命?

VPNルータとして導入した Edgerouter-X だけど、最近何日かおきにトラブル。

現状は、実質 SW-HUB 状態の使い方だけど、HUB 機能は動いているものの、管理画面などの Web 機能に繋がらない。電源を入れなおせば復活する。当初導入は VPN 機能だったけど、ルータを交換したら L2TP 使えるし、ただの HUB での利用なら Giga HUB の方が安いし、メンテナンスも不要だし。

(2022-11-19)

ということで、Amazonでポチった安い 5ポート Giga HUB に入れ替え。あんど、munin や nagios4 での Edgerouter の監視を外す。

usacloud monitor-cpu

$ usacloud server list -q
$ usacloud server monitor-cpu ¥
     --start 2022-11-11T00:00:00+09:00 ¥
     --end   2022-11-11T12:00:00+09:00 ¥
     123456789012
$ usacloud server monitor-cpu ¥
     --start 2022-11-15T15:55:00+09:00 ¥
     123456789012 2>/dev/null ¥
  | jq -r ".[].CPUTime" ¥
  | tail -1 
0.012345

自宅ドメインのwhois情報の修正

セキュリティの話をする際に、whois とかを使うこともあるけど、自宅ドメイン名で検索するとクソまじめに登録してあったから住所とかそのまんま検索できていた。

改めてプライバシー対策ということで、さくらインターネット🌸のwhois情報を修正してみた。最初、番地情報を消したりしたけど、エラーが発生して修正できず。レジストラの情報を書くのはアリ見たいだったので、入力フォームにある「さくらインターネット」の情報をそのまま入力したら、エラーも発生せず修正できた。

トラブルが発生しても、一旦レジストラに連絡が行ってから、こちらに連絡が来るんだろうし、これでも問題ないかな。

Buffalo ルータの更新 ver 2.86

JVNから、Buffalo ルータの脆弱性情報が流れてきた。自宅のルータも該当しているので、Buffalo のページからダウンロードして、さっそく適用。ver 2.85→2.86

しかしながら、このセキュリティ対策のおかげで、munin にて ルータのパケット流量をモニタリングするための script が動かなくなって、パケット流量が取れなくなった。

CAA レコードが未設定で dehydrated (Let’s Encrypt) が失敗

自宅ドメインの SSL 証明には、Let’s Encrypt (実体は dehydrated) を使っているけど、CERT の有効期限の確認の処理で警告がでてきて、月に1度実施の更新でエラーを吐いているみたい。

DNS に CAA レコードが無いと失敗する

更新を実行すると、以下の表示が出ている。

ERROR: Challenge is invalid! (returned: invalid) (result: ["type"] "http-01"
:
["error","detail"]      "CAA record for tsaitoh.net prevents issuance"

Let’s Encrypt が更新する際に、ドメイン名の CAA レコードを参照しているけど、CAA レコードが正しくないために、SSL 更新に失敗している。

DNS Certification Authority Authorization とは、ドメイン名の所有者が認証局に対して、自分のドメイン名の公開鍵証明書の発行を許可するかどうかを指定できるようにするインターネットセキュリティポリシーのしくみである。(Wikipedia)

CAAレコードに letsencrypt.org を登録

自宅ドメインは、Dynamic DNS に mydns.jp を使っているので、mydns.jp の設定画面の “DOMAIN INFO” の所で、
「@ CAA 0 issue “\000”」 となっていたので、下記の設定を追加する。

Hostname Type Content Target ID
@ CAA 0 issue “letsencrypt.org” mydnsXXXXX

この設定の後、nslookup では、下記のようなデータが取れるようになった。

$ nslookup -query=CAA tsaitoh.net
tsaitoh.net     rdata_257 = 0 issue "letsencrypt.org"

他の仕事関連のドメイン名も同様の症状が発生するようになるはずなので、mydns.jp 関連の他ドメインで同様設定を追加する。

Edgerouter-x 2.0.9-hotfix4

ふと、ファームウェアの確認などをしたら、Edgerouter-x の最新が数日前に出ていたみたい。

過去の記事をみて、インストール。暑い時期だったのか、最初ファームのルータへのアップロードに失敗して心配だったけど、リトライしたら普通に成功。

nagios4 をインストール

icinga が最新パッケージではサポートされていないので、icinga2 や zabbix をインストールしようとしたけど、データベースの初期化やらが面倒で上手く動かせていない。でも改めて確認したら、nagios3 から 更新しようとしたけど一度諦めた nagios4 のパッケージがインストールしやすくなっていた。しかもDebian12(bookworm)でも使える。

もともと、icinga は nagios からの派生だし、nagios3時代の名残りのファイルも残ってたし、設定ファイルのそれなりの変更は必要だったけど、監視コマンドなどの設定はそのまま流用できた。

設定ではまったこと

設定がそれなりに完成したけど、最初警告メールが飛ばずに悩んだ。

原因は、サービスの設定ファイルのテンプレート generic-service だった。いい加減な設定でメールが飛ぶのを防ぐために、templates.cfg で設定している generic-host や generic-service をそのままサービス監視の定義に使うと、テンプレートの設定の generic-service の定義の最後についている “register 0” によって、これはテンプレートだから…ということで、通知などの機能が動かない様になっている。

そこで generic-service から派生させた local-service などを使うべき。

# ダメなサービス定義
define service{
        use                     generic-service    ; Name of service template to use
        host_name               localhost
        :
}
# 有効なサービス定義
define service{
        use                     local-service    ; Name of service template to use
        host_name               localhost
        :
}

もう少し調整したいところもあるけど、ひとまず使えるようになってきた。

北陸情報通信協議会会長表彰

コロナ禍のなか、CTFを用いた情報セキュリティ教育の活動にて表彰していただきました。
{CAPTION}といっても、ict4e の原さんや、講習会で協力いただいた電子情報OBのおかげです。

postgreyの更新トラブル

postgrey に更新があった(1.36-5.2 ⇒ 1.37-1)ため、外部からのメールが届かなくなり、設定の変更が必要となった。

postgrey trouble

職場で動かしている WordPress の2段階認証メールを自宅サーバに転送しているが、2段階認証のメールが届かなくなった。原因は、怪しいメールは一旦拒絶することで spam を拒否してくれる postgrey がうまく機能していないと思われる。

/var/log/mail.log を見ると、下記のようなエラーで postgrey が起動していない。

May 5 16:53:15 ...: warning: problem talking to server
   127.0.0.1:10023: Connection refused

エラーを探すと /var/log/syslog に以下のメッセージを残して、postgrey 起動に失敗しているので、

May  5 17:11:53 ... postgrey[974882]:
   Option greylist-text requires an argument

/etc/default/postgrey の POSTGREY_TEXT のオプションをコメントアウト。

((( /etc/default/postgrey )))
- POSTGREY_TEXT=""
+ # POSTGREY_TEXT="reject by postgrey"

しかし、この変更後も職場からのメールが reject されている。

May  5 17:19:20 ... postfix/smtpd[975541]:
  NOQUEUE: reject: RCPT from unknown[xxx.xxx.xxx.xxx]:
  450 4.2.0 <t-saitoh@tsaitoh.net>: Recipient address rejected:
  reject by postgrey; from=<www-data@...> to=<...@...> ...

たぶん、職場のサーバは Azureで動かしているが、今回の更新による拒否判定が厳しくなったんだろう。仕方がないので、/etc/postgrey/whitelist_clients.local に、自分の管理している Azure サーバのIPアドレスを書き並べる

((( /etc/postgrey/whitelist_clients.local )))
xxx.xxx.xxx.xxx 職場のWordPressサーバのIPアドレス

でも、postgrey-1.37 の更新は本家の changelog を見ると 2016年 みたいだけど、debian パッケージでは随分遅れての 更新だな。手法的にも、もっと確実な、SPF とか DKIM の対応がすすんで、postgrey は時代遅れなのかな。自宅サーバでは、postgrey で reject しそうな接続元は GEOIP で SMTP 拒否しまくりだし、あまり役に立ってないかも。

postfix backward compatibility

今回のトラブルで改めて、postfix のエラーログを見ているとpostfixの再起動時に以下のようなメッセージが出ている。

May  5 19:06:07 ...: Postfix is running with backwards-compatible default settings
May  5 19:06:07 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details
May  5 19:06:07 ...: To disable backwards compatibility use "postconf compatibility_level=3.6" and "postfix reload"

設定ファイルでは、compatibilty_level が 2 とかになっていたので、書いてある通り 3.6 に上げておく。

((( /etc/postfix/main.cf )))
compatibility_level = 3.6

Google 検索

My Google   Yahoo

Microsoft

ファンサイト