海外からDDoS攻撃してくるカメラをシャットダウンしてしまうのは不正アクセスなのか?自首してみたが返答がない!そして泥沼のDDoSへ
顛末を記録した雑多なログになっているので整理されていない部分が多々あります.
2万文字を超えているので気合を入れて読むか適当に読み飛ばしてください.
これでも不要な調査データを省いたりしてスリム化したのですが超巨大化してしまいました.
2018-11-07から自宅のネットワークの調子が悪すぎる
自宅のネットワークが死んでいました.
J:COMの回線現在98%パケットロスするという状態になっています pic.twitter.com/Vfe0O3p5j2
— エヌユル (@ncaq) 2018年11月7日
今日の私
— エヌユル (@ncaq) 2018年11月7日
14時 サーバが落ちていることが通知される,サーバにDHCPがアドレス振ってくれてない
15時 ucomがついに死んだかと思いjcomに移行する
16時 移行できたけどOP25Bどうしよう
17時 jcom回線が98%パケットロス状態
18時 なんとなくucomに戻してみたらDHCPからアドレス振られた
私の午後返して…
ucom回線に戻して治って良かった良かったと思ったらucom回線も90%以上のパケットロスが発生するようになったこの世の終わりだ pic.twitter.com/8jlpYuVYc8
— エヌユル (@ncaq) 2018年11月7日
そのせいでこのサーバも頻繁に落ちてしまっていました.
1日だけの現象かと思いきや, 今日(2018-11-08)になってもまたサーバが落ちるので, 回線業者ではなく他の要因を探しました.
リモートワークしている時は回線が死んでいたら業務が不可能になるので仕事にも関わってしまいます.
データ受信量が異常
% ifconfig
lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::213:3bff:fe0f:a075 prefixlen 64 scopeid 0x20<link>
ether 00:13:3b:0f:a0:75 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 29 bytes 2210 (2.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 28 base 0x1000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 290693 bytes 41917043 (39.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 290693 bytes 41917043 (39.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 113.34.245.188 netmask 255.255.255.128 broadcast 113.34.245.255
inet6 fe80::468a:5bff:fe65:a15b prefixlen 64 scopeid 0x20<link>
ether 44:8a:5b:65:a1:5b txqueuelen 1000 (Ethernet)
RX packets 34105281 bytes 29752489195 (27.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 85902 bytes 38060178 (36.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 29 base 0x9000
見ての通り,
wan0の受け取ったデータが27GiBに達しています.
これはサーバを再起動してから数十分でこうなってしまい,
再起動する前は一時は100GiBを超える受信量になっていました.
今(2018-11-18)は296.6GiBになっています.
何で今さらifconfigなの?
という件についてはテキトーに眺める分にはこっちの方が楽だからです.
よって私はDDoS攻撃を疑いました.
DNSリフレクション攻撃を受けていることがわかりました
繋がる時にサーバで
sudo tcpdump -i wan0 -n not arp and not port 22
をして,
arpとsshを除いて通信を確認しました.
大量に受け取っている内容がDNSのレスポンスであることがわかりました.
色々考えてやっと DNSリフレクション攻撃であることがわかりました.
知識としては知っていましたが, 今どき攻撃可能になってるマシンがそんなに存在するとは思っていませんでした. なので気がつくのがずいぶんと遅れてしまいました.
即座に気がつけずにプロバイダの調子が悪いことを疑ってしまったのは私の汚点です…
操られていた機器をシャットダウンしました
とりあえず攻撃してくるIPアドレスを調査しました.
とあるIP情報サイトによるとこれはカンボジアのIPアドレスのようです.
DNSサーバが動いているかチェック.
% dig google.com @悪用不可能.なように.IPアドレスは.伏せています
; <<>> DiG 9.12.2-P2 <<>> google.com @悪用不可能.なように.IPアドレスは.伏せています
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46441
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 51 IN A 216.58.196.46
;; AUTHORITY SECTION:
google.com. 265609 IN NS ns3.google.com.
google.com. 265609 IN NS ns4.google.com.
google.com. 265609 IN NS ns1.google.com.
google.com. 265609 IN NS ns2.google.com.
;; ADDITIONAL SECTION:
ns3.google.com. 86668 IN A 216.239.36.10
ns4.google.com. 86668 IN A 216.239.38.10
ns1.google.com. 86668 IN A 216.239.32.10
ns2.google.com. 86668 IN A 216.239.34.10
;; Query time: 301 msec
;; SERVER: 悪用不可能.なように.IPアドレスは.伏せています#53(悪用不可能.なように.IPアドレスは.伏せています)
;; WHEN: 木 11月 08 18:37:26 JST 2018
;; MSG SIZE rcvd: 180
DNSサーバがオープンリゾルバとして動いていることを確認しました.
とりあえずnmap.
% nmap -A 悪用しにくい.ように.IPアドレスは.伏せています
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-08 18:37 JST
Nmap scan report for 悪用しにくい.ように.IPアドレスは.伏せています
Host is up (0.30s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
53/tcp open domain (generic dns response: NOTIMP)
80/tcp open http
| fingerprint-strings:
| GetRequest:
| HTTP/1.1 200 OK
| CONNECTION: close
| Date: Thu, 08 Nov 2018 16:46:14 GMT
| Last-Modified: Sat, 30 Sep 2017 11:48:58 GMT
| Etag: "1506772138:62bc"
| CONTENT-LENGTH: 25276
| CACHE-CONTROL: max-age=0
| P3P: CP=CAO PSA OUR
| CONTENT-TYPE: text/html
(伏せ)
| HTTPOptions:
| HTTP/1.1 200 OK
| CONNECTION: close
| Date: Thu, 08 Nov 2018 16:46:18 GMT
| Last-Modified: Sat, 30 Sep 2017 11:48:58 GMT
| Etag: "1506772138:62bc"
| CONTENT-LENGTH: 25276
| CACHE-CONTROL: max-age=0
| P3P: CP=CAO PSA OUR
| CONTENT-TYPE: text/html
(伏せ)
|_http-title: WEB SERVICE
2000/tcp open bandwidth-test MikroTik bandwidth-test server
8291/tcp open unknown
58080/tcp open http MikroTik router config httpd
| http-robots.txt: 1 disallowed entry
|_/
|_http-title: RouterOS router configuration page
2 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at https://nmap.org/cgi-bin/submit.cgi?new-service :
(伏せ)
Service Info: OS: RouterOS; Device: router; CPE: cpe:/o:mikrotik:routeros
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 197.65 seconds
本体はネットワーク接続可能なカメラだったようですね.
80番ポートを指定した時のスクショを撮っていないのでどのメーカのカメラかわからなくなってしまいました. 残念.
Dahua と言う所が少し怪しいですが確証はありません.
58080ポートを指定してブラウザを開いたらRouterOSのコンソールが認証無しで開かれました. これ以上攻撃に加担しなくて済むように, なるべく他の箇所を見ないでシャットダウンしてあげました.
ログを見れば犯人がアクセスした手段とかわかるかなと一瞬思いましたが, 他人の機器に自衛目的以外でアクセスするのってただのクラッカーだなと思ったので行いませんでした.
これがメインの攻撃手段だったようで, これを落とせば攻撃のほとんどが止みました.
他にMySQLとPostgreSQLが動いているWindows Server 2008とかが攻撃に加わっているようでしたが, 回線に影響はほぼ出ない程度のものでした. なので放置です.
私の行動は不正アクセスなのでしょうか?
シャットダウンしてから気がついたのですが, 私の行為が不正アクセスに当たるのかもと気がついてしまいました.
私の行動は不正アクセスに当たるのでしょうか?
不正アクセスとは、本来アクセス権限を持たない者が、サーバや情報システムの内部へ侵入を行う行為です。
RouterOSのシャットダウンボタンはインターネットに繋げる人ならば誰でも押すことが出来ました. なので私は｢本来アクセス権限を持たない者｣ではないはずです. また私は何の脆弱性も利用していません. そもそもRouterOSには認証機構はありませんでした.
しかし判例では認証機構がない所にアクセスしても不正アクセスになることはあるようです.
「プログラムに設定の間違いや脆弱性があったとしても、それだけでアクセス制御がなかったとは言えない」とした。
これはディレクトリトラバーサルを使ったようなので, 私のようにトップページにアクセスしたら普通にシャットダウンボタンがあったという
ACCS vs Office 事件なら、CGI のディレクトリトラバーサル脆弱性を突いて FTP の認証機能を迂回したという話 (参考： https://t.co/FO1J9aFpLw ) なので、アクセス元の IP 入力してブラウザアクセスしたら WEB カメラの管理画面が認証なしで見えたという場合とは事情が異なるかと。
— 茂木 和洋 (@kzmogi) 2018年11月9日
私は法律にはたいして詳しくないので, 私のやったことが不正アクセスになることはわかりません.
しかし褒められた行為ではないことは分かっています. 幾ら攻撃に加担しているとは言っても, 他人の機器を勝手にシャットダウンしてしまったのですから.
では我々は何の手立てもないまま, ネットワークを攻撃され, 死ねと言うのか!
ただこのカメラをシャットダウンしない限り, 私の回線とサーバは死んだままになってしまいます. 大量にデータを送ってきて回線ごと抹殺するという相手の手段上, ブロックする行為も有効ではありませんし, カンボジアの警察に連絡して止めてもらえる語学力も私は持ち合わせていません.
仮に英語が出来たとしてもカンボジアの警察とか日本への攻撃で動く気がしませんし, 仮に動いたとしても月単位で時間がかかるでしょう.
IPアドレスさえわかれば可能な攻撃である以上, 私がwebサーバの公開をやめれば止まる攻撃でもありません.
私の行為は許されないものなのでしょうか? 黙って攻撃を受けて, インターネット回線が使われなくなる嫌がらせを受けるべきだったのでしょうか?
仮にこれが不正アクセス認定されたら, 私のような個人はどうやって対策をすれば良いのですか? iptablesで遮断しても, 回線自体をパンクさせているので対処が出来ません.
またこの攻撃は対象のIPアドレスさえわかっていれば可能なので, サーバを公開しなければ良いとかいう問題ではありません. これを見ているあなたも突然インターネットが全く使えなくなる嫌がらせを受ける可能性は高いということです.
実際私のJ:COM回線も現在サーバを建てていないのに攻撃を受けています.
このページを見ているあなたのIPアドレスは(Torなどを使っていない限り), 私にわかっているので私が攻撃することは十分可能ということです. もちろん私はそんなことはしませんが.
ところでこの攻撃は私のncaq.netドメインに紐付けられてるIPアドレスに行われているのですが,
このIPアドレスに他社サービスのIPアドレスを指定したら何かの罪になるんですかね?
相手はドメインを見て攻撃対象を決めているようなので,
これをするのは負荷分散になってある程度有効な攻撃回避手段になります.
このページを見ているあなたに攻撃対象を擦り付けることも十分可能です.
もちろんそんなことは私はやりませんが.
自首してみた
でもみんな電波法違反とかしてますが何のお咎めもありませんよね…
と思って技適で検索してたら読んだことのある記事が出てきました.
技適マークのない機器で無線を使っていたので自首してきた。 | Tojikomorin
そうだこの人みたいに自首すれば良いんだ.
というわけで最寄りの下北沢警察署に自首してみることにします.
ということで下北沢 北沢警察署に自首してみました.
すると以下の返答を貰いました.
- 交番レベルじゃわからない
- サイバー捜査課とかに聞いて
- 攻撃食らってたのが埼玉の自宅なら埼玉県警に言って
ここに自首してみたんですが「交番レベルじゃ対処できないし場所が埼玉なら埼玉県警に行って」と言われてしまいました pic.twitter.com/mFkBhlYvZD
— エヌユル (@ncaq) 2018年11月8日
埼玉県警に聞いてみました
埼玉県警の浦和警察署に電話して自首してみることにしました. 交番の警察官によると電話相談でも良いということなので, 出勤の合間に聞くことが出来ました.
通話内容は以下のような感じでした.
- 私: 私のしたことが不正アクセスかどうか教えてほしいんですが
- 警察: 被害届が無いと対処できないしどうなるかわからないよ
- 私: でも不正アクセスは親告罪ではないですよね?
- 警察: わからないしIPAに聞けば?
2018-11-14にまたサイバー攻撃
2018-11-14にまたサーバが落ちる現象が発生しました.
Mackerelを導入していたのでデータ通信量が跳ね上がることが確認できました.
Mackerelを実験として自宅サーバに導入しました - ncaq
また攻撃受けたっぽい pic.twitter.com/wRFQLW5RWH
— エヌユル (@ncaq) 2018年11月14日
パケットキャプチャの準備
攻撃受けてからパケットキャプチャ開始しては遅いので, サーバで常にパケットキャプチャを行うことにしました.
tcpdumpかtsharkを使ってキャプチャすれば良いことはわかりましたが, サーバの容量をパンクさせずにログを取る方法がわからずしばし戸惑いました.
tsharkのインストールとフィルタ・自動停止オプションの使い方まとめ | OXY NOTES
を参考にして
[Unit]
Description=tshark
After=network-online.target nss-lookup.target
[Service]
ExecStart=/usr/bin/tshark -b filesize:1000000 -b files:20 -f 'port not 22 and not arp' -i wan0 -w /var/log/tshark.pcapng
[Install]
WantedBy=multi-user.target
というsystemdユニットファイルを書いてログを取ることにしました.
IPAに連絡(出来なかった)
情報セキュリティ安心相談窓口：IPA 独立行政法人 情報処理推進機構
2018-11-14に電話してみたんですが17時で相談が終わってしまいました. とりあえず後回しにします. 正直独立行政法人が法的に取り締まるかどうかを判断できるとは思っていません.
2018-11-18に電話. 土日祝日は相談受け付けてないのね…
2018-11-21にやっと時間とれたので電話したら相談ににつなぐ前に ｢犯罪に関わる相談は受け付けていません｣ というガイダンスが流れてきてダメでした.
サイバー犯罪対策課に連絡
電話してみましたが｢ここでは判断はしかねます｣しか言わなくて話になりませんでした… ｢事件の相談は警察署に｣と言ってますがもう浦和警察署には一蹴されてるんですよね. ｢情報提供をフォームでしてください｣と繰り返し言われましたが
原則としてメールへの回答は致しません。
と書いているんですよね… 私は私が不正アクセスしたかどうかを知りたいんですよ.
と言ったのですが｢回答するかどうかはサイバーの人が決めることなので｣と言われて, ｢原則としてだから回答するかもしれないことですね?｣と質問してそういうことだと回答を貰いました.
なので一応情報提供という形で投稿してみます.
そうしたらこのような返事が帰ってきました. (迷惑メールフォルダに入れられてた)
こちらは、埼玉県警察本部生活安全部サイバー犯罪対策課です。寄せられた情報を確認しました。
事案を判断するためには、今回の件に関する資料を見ながら、直接お話しを聞く必要があります。
ご自身の居住地を管轄する警察署（交番ではなく本署）に電話連絡の上、教示された資料などを持参して相談して下さい。
当方は情報提供専用窓口であり、被害の届出や相談の受理等は、行っておりませんので、ご理解のほど、よろしくお願い致します。 ******************************************* 埼玉県警察本部生活安全部サイバー犯罪対策課 ******************************************* ※当メールアドレスは送信専用であり返信はできません。
やっぱり相談の受理してないじゃないか!
既に浦和警察署に電話したけど相手されなかったって書いてるんですけど, 無視されたみたいですね
2018-11-16にまた攻撃が始まって今度はDoSからDDoSに変化しました
リモートワークやってる時に攻撃が始まりました. 完全に業務妨害ですね…
回線を移し替えることでとりあえず仕事することを試みましたが, 相手側は両方の回線を攻撃していますね.
テザリングするしかないです. いい加減にして欲しい.
攻撃してくるIPアドレスの例です.
% nmap -A 伏せた.通信会社.の.IPアドレス
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-16 16:26 JST
Nmap scan report for ns.通信会社のhost.co.jp (伏せた.通信会社.の.IPアドレス)
Host is up (0.22s latency).
Not shown: 987 closed ports
PORT STATE SERVICE VERSION
23/tcp filtered telnet
25/tcp open smtp Postfix smtpd
|_smtp-commands: mail.通信会社のhost.co.jp, PIPELINING, SIZE 51200000, VRFY, ETRN, AUTH CRAM-MD5 LOGIN DIGEST-MD5 PLAIN, AUTH=CRAM-MD5 LOGIN DIGEST-MD5 PLAIN, ENHANCEDSTATUSCODES, 8BITMIME, DSN,
53/tcp open domain ISC BIND 9.3.6-P1 (RedHat Enterprise Linux 5)
80/tcp open http Apache httpd
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Apache
|_http-title: 404 Not Found
110/tcp filtered pop3
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
|_ 100000 2 111/udp rpcbind
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
443/tcp open ssl/http Apache httpd
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Apache
|_http-title: Apache HTTP Server Test Page powered by CentOS
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Not valid before: 2010-07-16T20:05:24
|_Not valid after: 2011-07-16T20:05:24
|_ssl-date: 2018-11-16T07:27:30+00:00; 0s from scanner time.
445/tcp filtered microsoft-ds
777/tcp open http mini_httpd 1.19 19dec2003
|_http-server-header: mini_httpd/1.19 19dec2003
|_http-title: GIDEON AntiVirus
999/tcp open ssl/http mini_httpd 1.19 19dec2003
|_http-server-header: mini_httpd/1.19 19dec2003
|_http-title: GIDEON AntiVirus
| ssl-cert: Subject: organizationName=GIDEON Corp./stateOrProvinceName=Kanagawa/countryName=JP
| Not valid before: 2005-09-15T02:43:51
|_Not valid after: 2025-09-15T02:43:51
|_ssl-date: 2018-11-16T07:27:30+00:00; 0s from scanner time.
| sslv2:
| SSLv2 supported
| ciphers:
| SSL2_DES_64_CBC_WITH_MD5
| SSL2_RC4_128_EXPORT40_WITH_MD5
| SSL2_RC4_128_WITH_MD5
| SSL2_RC2_128_CBC_WITH_MD5
| SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
| SSL2_DES_192_EDE3_CBC_WITH_MD5
|_ SSL2_IDEA_128_CBC_WITH_MD5
1723/tcp filtered pptp
Service Info: Host: mail.通信会社のhost.co.jp; OS: Linux; CPE: cpe:/o:redhat:enterprise_linux:5
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 62.21 seconds
% dig usadf.gov @伏せた.通信会社.の.IPアドレス
; <<>> DiG 9.12.2-P2 <<>> usadf.gov @伏せた.通信会社.の.IPアドレス
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12578
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;usadf.gov. IN A
;; ANSWER SECTION:
usadf.gov. 2108 IN A 198.49.23.145
usadf.gov. 2108 IN A 198.185.159.144
usadf.gov. 2108 IN A 198.185.159.145
usadf.gov. 2108 IN A 198.49.23.144
;; AUTHORITY SECTION:
usadf.gov. 2108 IN NS auth120.ns.uu.net.
usadf.gov. 2108 IN NS auth111.ns.uu.net.
;; ADDITIONAL SECTION:
auth111.ns.uu.net. 2108 IN A 198.6.1.115
auth120.ns.uu.net. 2108 IN A 198.6.1.154
;; Query time: 19 msec
;; SERVER: 伏せた.通信会社.の.IPアドレス#53(伏せた.通信会社.の.IPアドレス)
;; WHEN: 金 11月 16 17:20:06 JST 2018
;; MSG SIZE rcvd: 187
はい特定のクエリに反応するオープンリゾルバですね.
今どきRed Hat Enterprise Linux 5のサーバをインターネットに公開するんじゃあない. (nmapはRed HatじゃなくてRedHatと出力するんですね)
とりあえずこのサーバは身元が日本国内かもしれない (私が騙されてて本当は海外のサーバかも?まあNTT回線で千葉松戸だから大丈夫でしょうが) ので連絡してみます. ITの会社のくせに53ポートを公開するなよ…
とりあえずお問い合わせに電話番号公開されてるから電話するかー. と思って電話してみたら｢現在この電話番号は使用されていません…｣ なんだこの会社.
メールで問い合わせしてみるけど反応あるか微妙. IPAにも同時に連絡しましょう. このサーバは国内なのでIPAも対応してくれるはず. と思ったけどソフトウェアの脆弱性とウェブサイトの脆弱性しか受け付けてないので, オープンリゾルバについて受け付けてくれるか微妙. whoisでネームサーバに設定されているからウェブサイトの脆弱性としてごり押ししていきますか.
これで対応してくれないなら, オープンリゾルバを増やしまくる通信会社として名前を出して注意喚起するしかない.
現在(2018-11-18)返答は通信会社からもIPAからも帰って来ませんね.
2018-11-19追記 通信会社のDNSサーバは治りました
読み直してみたら, これはDNS権威サーバなので53ボートが公開されているのは別におかしくないですね. 私がおかしいことを述べていました.
もちろんどのクエリにも反応する状態になっていたのはおかしいことで, 自分の管理下にあるドメインの情報だけを返すべきであることは変わらないのですが.
そしてDNS権威サーバを公開している通信会社から今日メールで返信が入って, どうやら自分の管理下のドメイン以外には反応しなくなっていることがわかりました.
IPAの介入を待たずに修正してくれたのはありがたいことです.
DDoSの踏み台の解析
前回はメインで攻撃してくるホストが主に1だったことからDDoSとは言い難くDoSと表現していましたが, 今回は攻撃してくるIPアドレスが大量にあるので対策が取れない…
DoSではなくDDoSであることは
を見てもらえればわかると思います. 記録し始めたのは2018-11-17からですが… (2018-11-18現在)
最初はDoSだと思ってすぐに対応出来ると思いましたがDDoSだったので諦めてテザリングして仕事します.
DNSリフレクション食らっているのは, DNSのQueryが799なのに比べてResponseが649917なのでほぼ間違いないと思います. DNSと認識されないフラグメントも多い中DNSと認識されるやつだけでこの数ですからね.
mergecapで4GBのpcapngを合成してwiresharkで解析してたらwiresharkがsegvしました.
Wiresharkでレスポンス見てて分かったのですがどいつもこいつも
US African Development Foundation
のレスポンスを返してきますね.
もしくはそのnsであるns.uu.net系何故だろう?
IPアドレスが複数あってDNSKEYやTXTが容量が大きいとは思いました.
% dig usadf.gov @8.8.8.8 any
; <<>> DiG 9.12.2-P2 <<>> usadf.gov @8.8.8.8 any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57044
;; flags: qr rd ra; QUERY: 1, ANSWER: 24, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;usadf.gov. IN ANY
;; ANSWER SECTION:
usadf.gov. 1064 IN SOA auth111.ns.uu.net. hostmaster.uu.net. 8023 1800 600 1728000 3600
usadf.gov. 1064 IN RRSIG NSEC3PARAM 7 2 3600 20181128030523 20181121020523 36894 usadf.gov. Cc49Q6U7hvNivlPFQHb6O14YjIXhZh7Vx+GCQKTPON/b3R0+Jpn0Az3F aFgu81xIZY9r/dqhH2ZDPsvDyaqSbzFJ7OJPWV9a/K8QZewm4Gyjn1hk WunMm9Usv3dvIg9R0R4oswPpX6OJnEz6MZVrGm5Cra4nvFJ+nUuo59ke K/n2JNDaggpTT8C/AoB2AODK0lJRm9b3N4yVseDDdEoecRaDlaN6AWYr GhQIo+eNWluQ2P8rp2lI/SOXM3oiWBHDhO2+FeNYtb5S4hadfLi2hdvC Xllpy/EVmfAgMnCL8J3W3+C/4O/hRrKjfqmqf0lrqKHOLHQcJ6gLgudu tiZ1/A==
usadf.gov. 1064 IN RRSIG DNSKEY 7 2 3600 20181128030523 20181121020523 36894 usadf.gov. dSr9xbP+w1nvYdQ+scgCgvaPnGQGUmY8eT8gWZiZnnTgx1+kXCVnVdUU t/mNpw2VJ5wkbya9DBOYvRraMEARQoGhBr5X8jlm16pLSkk0TFavaB6a T4VXLx+2UkaaqqMEaLY7U32gm0/8MRRTmJzoL2pOJghdno6JBnaBv6He KauqfthxpFCUjm4IXUwbP3KMqPjdOr0SlGn6QqhdTY938Yhi8LMuTzvd vd3tGpBX/TJgYMCXu2VkO/tYUoFg+FpyKCbslAXNm3NZCwQwqXYvOMgs Lm/2WMy1VtuLMBa7NA7oYDLEH9rJAfnRAfnBwS1VkOrufVwHsxQSbVtI 4HdouQ==
usadf.gov. 1064 IN RRSIG DNSKEY 7 2 3600 20181128030523 20181121020523 40159 usadf.gov. GHplEiCP3VonVGC+LO5Ve7wE1k5Np+SNfeNZLAVsDeHzLctiAgDWLbO+ C8gYArvvhML4NCDFlOuMVVKB3xKQyj0slJ57MfdsKOPn6H9qmH42h6R+ FWra1QD4b/aE9eJobWlyemXihCJ+5ut19w8SMqjw5pQPZz89UxybxpqI Y02GRFM2qB3wvMC4ovjtohvQV0qA2OWhvYJ4T11XbBrathtBRoF9JKId mWvGrlSKGE32mD8tA2Vz4Ow+un9KreMavSyYqXreH3BDDwx7sQqYefEZ WZ8RYNkg0SpnVfcd2+LWil/inNpgY12F0msbPGKjLw+8WDa4u3JtYE2H U6TEDg==
usadf.gov. 1064 IN RRSIG SOA 7 2 3600 20181128030523 20181121020523 36894 usadf.gov. VZdn5bbH/8SjawNwqpR2OKcCRV+tvXZOjd6QK8+q3aBkx/yTMtTX9hkz O9R96gg/KX7AA13XsTFQcGyGa3T+AcOmL67hJ1/OhS3Sl8Ulu5X8hua2 /jPe4ToCyj0Vj/5AsBc97wgyJ47EU/V6ROL0VAo/oUVDW6emTiczNmjP NXKz5TwBGWbkQ4GLWegNKybmzfsIqi7NTZci7n+J1H2p20kDqFvAAgG+ zCndnF/J+W+pxUVB9Tv9tUg1VYy0Y4fE/Mtph/7nvq4pj8fcQTF6V4LF 7O5eKQBRBEQ87noSD4gdf6TR3u3++QDlEb7Gsqw9IyPFIALze8b8TU/h NVpkTw==
usadf.gov. 1064 IN RRSIG A 7 2 3600 20181128030523 20181121020523 36894 usadf.gov. N3YXmahFb6ED7qmxWluQlw8K0p48fjaql07gTPWgZ/otiMotDlRZE5AY 8RmzcmK9esdJq0jESMkvGEzQDRO21zKI567Vzoz9YhtBPdwzHFAUJffY tixucFn3h3f+fTxwilju3WpWQU8Pq1xhzxHi0OjeBnnIsqnCVasrdVAl sPgNzcya4yRSAoYOXQoek6pvvuWXjKq5osoyafDLN8+kkKTMr8wkkJQw QKx/IyuMGmsoKiTyK5VBJgcZSudy3s/uk3Od1KvXJUxFDL46lrCgkNXW GqaMic907TaqsgIryD2kBWyM+UjFBxjNNnkZNLs15qotXC0tMRFcenid 6OHRFA==
usadf.gov. 1064 IN RRSIG TXT 7 2 3600 20181128030523 20181121020523 36894 usadf.gov. QCZaarmL8JnetDAmwjjilvQhb+wfBaEOxZmeEE8Aswgq95JiR2nZrLf8 Mo2tr5SX+TDHj7ZveyN+K62r+X7VObcAQ9TDn7Vp4yKoDK2QI1sAqWio GMw+Q2hb/9lyhNcdy97oiIKhpgtKVlsYmXtdLMlHMgbzpTfsk7DnAMqm ZXBRYG2CT1jfDP6AiKUoEigs8FWy6QgOA8rf8nfeoqUoWszrIhwOR6zv fyF9b92cRskb/aEU+tOYqaeO0JHAHUD1RMOvbUbVLjS+v/v/HcV+s318 cfiXvf3mLSo+7NBrAy1/PrbZusiDOFU5D01vTN5hNPI3hEyCRLUZq0zw Knd0fg==
usadf.gov. 1064 IN RRSIG MX 7 2 3600 20181128030523 20181121020523 36894 usadf.gov. hscjipy/7sXJBiG5PJr6h/E63odzvF6KAFG957xn67gSef8M9lta6ID4 U6KKAOQicEDnpbNiE2i2yEBZuNBgf68UbiJ9PBX5BRAnWSngGP9uG8OF +kdOwaS2A8sqHQ40twTzWrkYH9+l0Jxczq4AI8X/D6ZofGhw5vci9e/7 rZkuHpCN/LQP5JtasDh0W26bFessZuD6fy3it8tp1PA9dYN/iZ4V9kh+ +5MPLyyp3hKbYT+yPHFenFNeSQ0TiTqjq5pVz742EyP8xHYvOn/9MjMU VLxyN33NTQzcRrNEJJ7KQwuefwFTQ8D6qU3QlBKDntFioOaulHJaPxCQ zaZe5Q==
usadf.gov. 1064 IN RRSIG NS 7 2 3600 20181128030523 20181121020523 36894 usadf.gov. dA/hhIeermV8184hib7piVhettO74WHtbti23/E4WO4nKXpy6LTfRv8c qM/ZoWKgfl6baZDLMjpsPcB8jQ3XNmfYL4DsSI74JlaD0/hGaIapJ2x6 CluZdErYZrcBjv59O6n9pLdvbUAumdDjRHadArWRjQD1Y7EhZ+KnWget 2EKesxdMox3zgajhKuZlhQsOe/yq7YdIgjBls0e2d3WtoOcLKV34fMb7 eZxP7I0l46mvu407EiitqDXMxWXxOVhtzVVQmag03M22h3jn1yadmy1C fgT8kqaYtbfhXvAnopbSUMuRPWIr9+y62dZdn1JV0b8js56W+USH1YHs gb7XNA==
usadf.gov. 1064 IN NSEC3PARAM 1 0 12 AABBCCDD
usadf.gov. 1064 IN DNSKEY 257 3 7 AwEAAZcAqbnIfQLJDzw6JZYh4jDYLovOA967lLfkDOdHD65tF5ACQu/8 4kzB87RZDcJcc/5SBMsOENxKIgyAWlBcf9ky4+xUDVfZNlgULJcvZoXK pm01AAtiqwnPm47mZ7fB/9CWrpx6Qjc0KgrIq+mv0sRT0bb/I6MeKzwx gixWnY1eemrmhgImVkKj3dUnxmZEDqZwXVQaoGmR80aysYEBgP6nQ3Fg DP1gg0rMm4uHC4Zh3ltd2M6ITnDmLG7o8NQ/cF+aG18N4fYKIKcGl2dz uT3HnThFry1D2VUktvNd6DnwF/nsNP2psQNUH4k4H++9EhfrG5sqPprs 8R7AoZaeUoM=
usadf.gov. 1064 IN DNSKEY 256 3 7 AwEAAYl4zOc2W1q53Xj9ZTZFSYAVrmdyMJIRonThDo0kbmMAjRwWRIi6 X9DW03ehKxGJzbE+Gf+RDRL6002McVCgVn64vgHgBoJnSVe8WazQIypX XEjrLvDLFGhwmn8TXkf4Q7Nb8vxQjVX8hfoF3ZQefLkaQZqgau4MJrTO TJstPiVNf0ok60H8oWze2nAoqZol0vVf1B/ruZYC7bV5MU2Ah0Xq0w7B C7+Qe1lyZn2PyywqKlC87toAeaVbxep3bJQf5qgjevtgdYOZIdY89G4x 2GCSxqfbbluORMHZ0ucFHOBrglQ9CGy2wngCgXN6zL4W0kZ5Q1T2gYFj 2qAuM476Gr0=
usadf.gov. 1064 IN DNSKEY 256 3 7 AwEAAZVsWxqpgPQJ0t+2y2pA0h0MLLUwSqmvfNj91Tlx2U43v68yn3nt KpKLTwiZOWKLrOF6a0c0WreydGxONZ+noj9+Um0TdBqLp+Jbg5kFXdpE aFxep/ZJjFiV0lFRFWikO46nyuPG1dbrO95U18ZN8WNrXfwUXmjpK6ZV qVcaQ6b9OamvQuiOkNBaidIuBMAlFrNXxhK+FBFgl6zhIGfTkXNyJq9N HzuSceGhaSxXLWi6Jg7fZ75goQaSjMUqC0PXT8oe3zVymRJQXKyoH2BO Nkd8NOHYaQLgPu/dg5M/2pM/kf+sXxVaErxEO/OVr82u3dqE0ovBYAGD G9VEAOP+WQ8=
usadf.gov. 1064 IN DNSKEY 257 3 7 AwEAAXo/+XWOCidlFjo2BAgvoDUUdC4BkCAv63ehJmjSOO1ll8z1H5sL DKkK/f5qfrh2IhwQ92nfRy3VmZVG84cqdxgkwWTxUEAjoIhBJ17nkfV2 fFN3ORFR/YK22wczqgruVsfVjnnWgDNxNWAIE6BWNJ5MOEWW+rfGSEy2 sA/VJZFSXf6OlrtJJsgbiO4Cw7gDTZ/Z+6YHHjX9HuwAmddXQCjKcJLP 2oaGByapLag4X/CBE+o3hIFpB67Vh0rjLuIANXlqc1PKC8pbkUmpMBkb /rbB1rW9DdM/L9PBmsH6biXUYzAaIK7AxImz0aneybugVj2IRHaNSzWk y4jiY9JfJ48=
usadf.gov. 1064 IN A 198.49.23.144
usadf.gov. 1064 IN A 198.49.23.145
usadf.gov. 1064 IN A 198.185.159.145
usadf.gov. 1064 IN A 198.185.159.144
usadf.gov. 1064 IN TXT "MS=ms52799582"
usadf.gov. 1064 IN TXT "MS=ms77622563"
usadf.gov. 1064 IN TXT "v=spf1 include:spf.protection.outlook.com -all"
usadf.gov. 1064 IN MX 0 usadf-gov.mail.protection.outlook.com.
usadf.gov. 1064 IN NS auth111.ns.uu.net.
usadf.gov. 1064 IN NS auth120.ns.uu.net.
;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: 水 11月 21 17:02:13 JST 2018
;; MSG SIZE rcvd: 3867
DNSSECってデータ増幅幅を増やす悪なのでは? (錯乱)
しかしもっとデータが大きいところはあるはずです. 他のドメインには反応しないオープンリゾルバも多いので, 何かのソフトウェアの脆弱性でこのドメインにだけは反応するように設定されてしまっている?
オープンリゾルバに悩まされるあまり, きちんとした運営を条件とする登録されたオープンリゾルバ以外は全部遮断しろって考えに至りつつあります.
OP25Bなんて迷惑メールが多少来るだけじゃねえか. こっちはネットワークの帯域が消滅してどうしようもないから基本IP53Bしてくれ. DNSリフレクションなどへの対応をきちんとしている事業者だけがオープンリゾルバ運営して良いことにしてくれ. そんな過激な思考に走りそうになっています. 実際IP53Bをやっているプロバイダは少数存在するようです.
IP53Bの実施について｜会員サポート｜プロバイダ ASAHIネット
他にも沢山IPアドレスを調べましたが, オープンリゾルバが多いですね.
そしてMikroTik社のルータが多く, 世界中にオープンリゾルバを販売しています. もうMikroTikのルータは販売を禁止にしろ. プリセットルールでオープンリゾルバ状態になるとか出荷して良い製品ではない.
［注意喚起］RouterOSのオープンリゾルバ対策 #routerboard #mikrotikRBUG JP Portal Site
大抵のMikroTikルータは無認証で入ることは出来ないらしいですね. その素晴らしいセキュリティ意識の高さでオープンリゾルバも止めておいて欲しかったです.
場所はエクアドルだったりアメリカだったり…
送ってきたデータが多い上位50件をWiresharkでCSVに吐き出させて集約してnmapかけてみたんですが,
vncが空いていたりして闇が垣間見えます.
nmap上では53ポートが開いていないように見えますが,
実際にdigでusadf.govの解決を頼むとオープンリゾルバであることが確認できます.
% cut -d ',' -f 3 graph.csv|sed 's/"//g'|parallel --keep-order 'nmap -A {}'
見てみるとメールサーバが多かったです.
サイバー攻撃にそこまで詳しくない私は詳細はもうこれ以上あまりわからないですし, たとえ一つ一つ侵入できる箇所を見つけてシャットダウンしたとしても, 私のネットワークに攻撃してくるサーバは軽く10000を超えるので, 対処することは不可能です.
プロバイダの上流の方で攻撃自動検知して貰ってブロックするしか無いのですが, 多分家庭向けプロバイダにそんな能力はない気がします.
そう言えば法改正でNICTが国内IPアドレスにポートスキャンをするそうですが, オープンリゾルバも検知して警告して欲しいところですね.
メールサーバも運用しているのでCloudflareを導入しても解決にはならない
Cloudflareを使って自宅サーバのIPアドレスを隠蔽すれば, 犯人は自分のサーバを使ったりして私のIPアドレスを特定する手間が発生して, 私はDDoS攻撃から逃れられると思う人も多いでしょう.
しかしそういうわけにはいかないのです. 私がwebサーバだけを運用していればおそらくそれで問題は解決したことでしょう. しかし私はwebだけではなくメールサーバも運用しています.
webだけなら無料だったり月20ドル程度でCloudflareを導入可能です.
もちろんCloudflareはSMTPなどに対する保護サービスを提供しています. ただしそれにはEnterpriseプランの契約が必要です.
Cloudflare Spectrum | Cloudflare
個人にはとても無理.
しかしCloudflareにはサーバが落ちている時にとりあえずキャッシュを配信する機能があったはずなので, とりあえずこれを使ってみます.
落ちてても見れるようにするのは大事ですしね. この記事を公開してもすぐ落ちてしまうようでは意味がありません.
と思って適当に適用しようとしましたがダメですね.
ncaq.netごと保護してしまうとsmtpだけではなくimapやsmtpにも影響を及ぼします.
www.ncaq.netだけ保護してキャッシュしてもらうようにしますか.
あれwww.ncaq.netだけ適用するのってネームサーバ変更する以上無理っぽい?
いやそんなことはないな,
ncaq.netは生のIP出しておいて,
cloudflare.ncaq.netとかはプロキシ通した場所にすれば良いのか.
ncaq.netはDNSオンリーにして,
cloudflare.ncaq.netをプロキシ通してサブドメインはCNAMEで参照するようにしました.
本来の目的の防護には全く役に立ってないがそれは仕方がない.
ncaq.netも落ちてしまいますが検索結果から飛ぶ時に見れれば良いという判断を下しました.
すべてのユーザーに必須のPage Rule | Cloudflare
を読んでAlways Onlineを有効にしつつPage RuleでCache LevelをCache Everythingにしたのですが, nginxを落としてみたら普通に読めなくなりますね.
add_header Cache-Control no-cache;
しているのが良くないのでしょうか. しかしこれを外したらコンテンツを更新した時にブラウザが新しいコンテンツを読み込んでくれない…
ヘルプ文章をちゃんと読んでみたところサーバが500とかを返さないと動作しないらしい. これじゃサーバ自体が完全に落ちた時に対処できないじゃないですか.
と思ったけどどうもそれは関係ないらしい.
Always Online cache is built from Cloudflare's Always Online crawler. We crawl Free customers once every 7 days, Pro customers once every 3 days, and Business and Enterprise customers daily.
Cloudflareのキャッシュが表示されると思ったので, キャッシュされたデータがそのまま表示されると思ったのですが, Always Onlineのクローラはまた別なんですね… そして無料版だと1週間に1度しかクロールしてくれない.
これじゃオフライン対策にはならないですね… 本来なら生のIPを完全に隠すことでDDoS対策になるのですが, 私の環境ではそれも出来ないですし.
Page Rulesでほぼ変更しない割に, 全てのページで読み込まれるfeedの画像やfaviconを常にキャッシュさせるぐらいしかやること無いですね.
location = /favicon.png {
add_header Cache-Control public;
}
location = /favicon.ico {
add_header Cache-Control public;
}
location = /feed.svg {
add_header Cache-Control public;
}
のように書くことでPage Rulesを追加すること無く,
ブラウザのキャッシュをネットワークツールで無効化しても,
nginx側にfavicon.icoへのアクセスが来なくなりました.
CloudflareがCache-Control publicを察知してキャッシュしてくれるようになったんですね.
このようにほぼ変更のないコンテンツをCloudflareに対してキャッシュさせることで, 初見の訪問者が来てもサーバにアクセスさせることがなくなるから負荷軽減になりますね.
普通にキャッシュをpublicにするだけでは出来ない負荷軽減ですね.
もし変更することになってもキャッシュを消去すれば良いわけですし, ここにきて初めてCDNのありがたみをしった感があります. 遅くない?
まあ一番良いのはYesodみたいにstaticディレクトリの中身はtag付きのURLでルーティングして, staticディレクトリ以下はpublicキャッシュさせて, 変更したらtagを変更することなのでしょうけど.
このように変更するかしないかを人間の手で考えて設定するのはよくない. よくないけど静的サイトなのでそういう動的なことをするのは少し難しいですね.
変更あることを考慮しても真面目にアクセス殺到した時のことを考えたら,
画像とかは5分ぐらいの有効期限でno-cacheは付けずにキャッシュさせて,
5分反映が送れるのは諦めた方が良いのかも.
まあ本来私のwebサーバはそんなに負荷がやばいことはまったくなくて, 前にバズって10万PVぐらい来た時も余裕でさばいていたのです. DDoSさえ来なければCDNなんて導入する気すら無かったのですよ. なのであんまりwebサーバの負荷対策は導入する気はありません.
なんか一部キャッシュされてないアクセスがあるみたいですけど, これはエッジが複数あるからキャッシュされてるエッジにアクセスしたかどうかの差ですかね?
負荷軽減になったのは良いのですが, Always Online機能が無料版だとあまり使えないことがわかって, 本来Cloudflareに期待していた機能は全く使えませんでしたね… 残念です.
やはりメールサーバやめてCloudflareの影に隠れるべきなのでしょうか.
と思ったのですがキャッシュをno-cache基本的にやめてPublicにして期限を1minぐらいにしていったら,
サーバが落ちてもしばらくサイトが見れるようになったようですね.
意味は一応あったみたいです.
とりあえずwebサーバだけでもGitHub Pagesに移行すれば良いのでは?
自宅のネットワーク回線が攻撃されるのはとりあえず置いておいて, このwebサイトだけでもGitHub Pagesに移行すれば良いのではと思う方も居るかもしれません.
このサイトが月間10000円の収益を生み出すならそうしていました. しかし実際はこれはただの趣味なので, あんまり真面目にサイトが見れる状態を維持するきにはなれません.
あくまで私が一番問題にしているのは自宅ネットワークが攻撃されて使えなくなることです.
もちろん攻撃されてサーバ運用の趣味を妨害されるのも困るのですが.
一応プロバイダにも連絡をしました
攻撃されたことが発覚してから連絡してなかったので, プロバイダのJ:COMに改めて連絡してみました.
なお私はJ:COM回線で現在サーバは建ててありません. 一度DNSに紐づけたIPアドレスを変更してみたら攻撃に巻き込まれてこちらも使えなくなっただけです.
電話担当はDDoSMonのページを見ることも出来ないらしく, 攻撃を受けてることを証明できませんでした. Google検索結果とDDoSMonのトップページ見れるのになんでDDosMonのページは見れないんですか… どっちも同じGETですよ. おかしい…
機器に異常が無いことははっきりしているのにまずは訪問しないとわからないとか言い出して, 仕方がないので予定を無理やり開けて訪問してもらうことにしました.
IPアドレス変更してもらうぐらいなら電話越しでも簡単に出来るのではないかと期待をしてみたんですが, それも機器に異常がないか確認しないと無理ということ. ええ… IPアドレスとMACアドレスの紐づけの解除ぐらい即座にやって欲しかった. J:COM回線のIPアドレスは今後DNSで公開する予定が無いので変更してくれればこちらだけは守られるのですが.
ucomの方はIPアドレス変更して貰ってもDNSの紐づけですぐに新しいIPアドレスバレて無意味なのと, 契約形態が実はよくわかってないので(マンション契約なので)連絡していません.
これからどうするか
最初は攻撃はすぐに止むと思っていたので, 被害届は出さないで私の行動が不正アクセスかどうか判定してもらえばそれで良いと思っていました.
不正アクセスじゃないなら攻撃が来てもこちらで対処すれば良いとも思っていました.
しかしDDoSに攻撃が進化して10000を超える踏み台から攻撃が来てしまい, これは個人で無報酬で対処するのは不可能だと判断しました.
私が大企業から依頼を受けた人なら黙って Enterpriseプラン | Cloudflare を契約するだけなのですけどね.
よってこの件は警察に任せたいと思っています. ただ警察は普通に連絡しても被害届を受け取って貰えないことが, これまでの様々な経験からわかってしまっているので, 今回は弁護士を通して弁護士を介して被害届を出して貰えないかと考えています.
どうしても無理なら
自宅サーバ諦めてwebはHerokuかGitHub Pagesあたりに移行して.
メールサーバを運用する趣味は断念して, Gmail(G Suiteによる独自ドメインの利用)に移行しようかと思っています. メールサーバを普通のクラウドサーバやレンタルサーバに移行することは出来ません. IPアドレスがスパム扱いされてしまうので.
Gmailは有料というだけではなく, 私の趣味を諦めることにも繋がります.
それはとても悲しいことですが, DDoSの攻撃対象を誰かに擦り付けるような真似をするよりはマシでしょう.
攻撃者へ
お前なんで攻撃してるのに金銭要求とか脅迫とかしてこないんだ? 要求されても無視しますけど… やっぱり個人的な恨みなんですかね?
MikroTikへ
オープンリゾルバをバラ撒くな, ルータ販売をやめろ.
IPAへ
オープンリゾルバ報告サイト作って専用に収集して欲しい. 別に今回IPAは悪くないですが…
全世界のプロバイダへ
デフォルトでIP53Bして申し込んだ人だけ簡単に解除できるような制度の導入を望みます.
J:COMへ
IPアドレス変更申請ぐらい訪問なしに出来るようにして欲しい. DDoSMonのページぐらい見て欲しい. こちらはサーバ問題ではないとは言え.
警察へ
自首した人を｢わからない｣という理由で門前払いしないで欲しい. 攻撃されてることも言ってるんだから取り締まりに動いて欲しい.
セキュリティ研究者へ
誰か助けてくれ.
2018-11-19追記 アドバイスに感謝
アドバイスをくださりありがとうございます.
とりあえず弁護士を探すのは継続したままJPCERT/CCなどにも相談してみることにします.
2018-11-21追記 相談の追加
休日になったので色々な場所に相談追加することにしました.
J:COM
訪問が来たので, ｢攻撃受けているのが原因なので機器の異常ではありません｣ と告げたら, ｢じゃあなんで私は来たんですか! 私に出来ることはありません!｣ と反論されました.
私が知りたいですよ! 電話口で何度も攻撃が原因で機器が原因じゃないことは推定できていることをもう伝えてるんですよ!
訪問者もDNSリフレクションとか帯域幅攻撃を理解していないらしく, ｢モデムがあるからモデムから先に攻撃は来ません｣ などと言っていました. 回線自体が攻撃を受けていることを説明しても理解できないようです. DDoSMonのページも見せたのに…
｢IPアドレスは固定されてないので移り変わる｣ と言ってたので, ｢でも半日電源切ってDHCPのリース待ったのですが変わりませんでしたよ?｣ と言ったら ｢そんな時間で変わるわけない, DHCPのリース期間とか専門的なことは私にはわかりません｣ と怒られました.
でもとりあえず機器を交換することしか出来ないとのことなので, MACアドレス変わったらIPアドレスも変わるかなと期待して交換してもらいました.
そしたらIPアドレスは変わったので, この新しいIPアドレスがバレるまではJ:COM回線は使えるようになりました. また攻撃食らったらモデム交換してもらいましょう.
でもJ:COM回線はレイテンシが異常に悪い上に, 攻撃受けて無くても頻繁に通信障害が起きますし, いざ攻撃受けてもHUMAXの低機能ルータだとパケットキャプチャが出来ないし詳細なログも出ないので, 出来れば使いたくないんですよね…
J:COM回線が繋がらなくなったのでUCOMに戻してみたらレイテンシが超改善されました, しかし自作ルータは不安定なのでどうにかしたい - ncaq
埼玉県警察本部
｢DDoS攻撃って何ですか?｣ ｢ここじゃ何も言えないので浦和警察署に直接出向いてください｣
サイバー犯罪対策課
当初は｢埼玉県人は埼玉県警に相談して｣の一点張りでしたが, 浦和警察署や埼玉県警のサイバー犯罪対策課に門前払い食らったことを話したら割と親身に相談乗ってくれました. ある程度は技術の分かる人でCloudflareの導入を提案してくれたり, (実際は前述の通りEnterpriseでないと対策にならないのですが) 30分に及んで話をしていました.
基本的に捜査の調査は電話では出来ないこと, 基本海外のサーバに対して捜査は出来ないことなどを話されました. 日本の会社の1つはメールして止めてもらったことを話しました.
しかし結論は ｢サーバ建てるのやめてIPアドレス隠せば良いのでは? 別に困るわけじゃないでしょ?｣ というものでした…
｢埼玉県警向けにDNSリフレクションの説明資料作った方が良いですかねハハハ｣ ｢わかんない人も多いでしょうからあったら用意したほうが良さそうですね｣
みたいな会話もしていました.
IPA
前述の通り犯罪に関する相談はアナウンスで門前払いでした.
JPCERT/CC
最初は電話しようかと思いましたけどよく見たらweb相談フォームがちゃんとあるのでこの記事のURLを送りつけます.
後オープンリゾルバを簡単に集計して50個ぐらい情報提供しました.
なんで浦和警察署に直接行かないの?
過去にTwitterのDMで包丁の画像と｢そろそろ死んでもらえますか｣という文面を送られたことがあるのですが.
これ警察捜査してくれるかなあ,私としては話し合いで解決したいんですけど pic.twitter.com/gQqIzzY40W
— エヌユル (@ncaq) 2017年5月24日
その後の会話で和解も無理そうだしリアルに会うこともあり得る人なのでこれは警察沙汰だな! 相手の本名もだいたいの所在地も勤務先もfacebookで公開してるし捕まえてくれるだろう!
と思って浦和警察署に行ったら｢これは脅迫ではないですね｣とのことで, 被害届を受け取ってくれすらしなかった経験があるので, 警察というものは市民の被害届を受け取らないものなんだなという考えがあるからです. ほぼ1日使って受け取られないのは心理的にも負担が大きいです.
なので弁護士を通して被害届を出していきたいと考えています.
2018-12-16追記
何故か攻撃が止みました.
相当のお金がかかることを考えて弁護士さんなどへの相談は攻撃がまた再開するまで取り止めることにしました.
教えてもらったJPCERT/CCへの情報提供は特に返答がありませんでした. まあ向こうさんも海外のオープンリゾルバの情報を提供されても困りますよね…
hatena-bookmark