3月12日火曜日に始まったPublickeyへのDDoS攻撃に対して、これまでサーバの強化、Cloudflareの導入とDDoS対策のための設定を行ってきました。 その結果、3月24日日曜日の夜に始まり3月27日水曜日の朝まで3日間連続で続いたDDoS攻撃のあいだもWebサイトの閲覧と記事更新などを問題なく行える状態となり、DDoS攻撃がWebサイトの運営の大きな障害ではなくなりました。 ちなみにそれ以後DDoS攻撃は止んでいますが、今後はいつDDoS攻撃を受けてもWebサイトの運営に支障がでることはなくなったと考えられます。この記事では結局どのような対策を行ったのか、実際に効果を発揮したDDoS対策を紹介していきます。 これまでの経緯は下記の記事をご参照ください。 Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ 続、Publickeyが受けたDoS攻撃、これまでの経緯と

MTA-STSとは MTA-STSとは、メールの配送経路上のメールサーバーとメールサーバーの間の暗号化の仕組みを少し強くするためのものです。 具体的には、受信側が、送信サーバーに対して STARTTLSを必ず使う TLS1.2以上を必ず使う 証明書が有効でなければ配送しない ようにしてもらうことを、お願いする仕組みです。 STARTTLSだけでは、何が不足なのかということについては、後ほど説明します。 例として、sender.example.comからreceiver.example.jpへのメールの配送を考えてみます。 まず、あらかじめ、receiver.example.jpのメール管理者は、自分のところのreceiver.example.jpにメールを送るときには、ちゃんと暗号化してね、とMTA-STSのポリシーでアピールしておきます。 receiver.example.jpのMTA-

Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better

はじめに Wi-Fiルータのセキュリティについて、2023年4月5日に警視庁より「家庭用ルーターの不正利用に関する注意喚起」が行われました。この中で対策として、次の4つが挙げられています。 初期設定の単純な ID やパスワードは変更する。 常に最新のファームウェアを使用する。 サポートが終了したルーターは買換えを検討する。 見覚えのない設定変更がなされていないか定期的に確認する。 定期的な設定確認が現実的に可能なのか疑問はありますがそれはさておき、今回は３番目のサポート終了についてです。 たとえばWindowsであればいつサポートを終了するのかずいぶん前に告知がありますし、他のソフトウェア製品についてもLTS(Long Term Support)の設定があるものは計画的にアップグレードを行えます。一方で家庭用のWi-Fiルーターについて、いつサポートが終了するのかわからないまま買っていまし

2022年11月30日03:24（東京）に、AdGuard DNSに深刻な障害が発生し、マイアミ、ニューヨーク、ロンドンの3ヶ所のサーバーが影響を受けました。 障害発生中、これら3つの拠点に接続されているすべてのお客様のインターネットが事実上遮断されました。 これは、AdGuard DNSの全顧客の約20％、すなわち1000万人以上の方がインターネットに問題を抱えたことになります。 影響を受けた方に、このような事態になったことを心からお詫び申し上げます。 今後このような問題が発生しないよう対策を講じる所存です。 何が起きたのか 小さなミスがいくつも重なり、問題発生に至りました。 これらのミスは、それぞれ単独なら致命的ではなく、障害を引き起こすものではありませんでした。 しかし、残念なことに、これらのミスが重なったことこそが、より大きなトラブルの原因となりました。 最初のミスは、11月28日

NECサイバーセキュリティ戦略本部セキュリティ技術センターの日下部です。 エンジニアの方にとって、システムのネットワーク構成を設計する機会は多々あるかと思います。 ネットワーク構成を検討する際、機器の役割や設置場所によって異なるネットワークアドレスを付与するネットワーク分割を実施することになります。ネットワーク分割の方法はファイアウォールやルータといった装置での分割の他に、サーバやPCに二枚のNIC（Network Interface Card）を使用してネットワークを分割するいわゆる”NIC二枚挿し”という方法もあります。しかし、この方法はセキュリティ上推奨しないという考え方があります。 本記事では、セキュアな産業制御システム（ICS : Industrial Control System）を構築するためのガイドであるNIST SP800-82を参考にNIC二枚挿しによるネットワーク分割

IoTや産業用デバイス向けにセキュリティソリューションを提供するForescoutが、「NAME：WRECK」と呼ばれる数百万台のIoTや産業用デバイスに影響をおよぼす可能性のある脆弱性の存在を報告しています。 NAME:WRECK - Forescout https://www.forescout.com/research-labs/namewreck/ NAME:WRECK vulnerabilities impact millions of smart and industrial devices | The Record by Recorded Future https://therecord.media/namewreck-vulnerabilities-impact-millions-of-smart-and-industrial-devices/ How the NAME:W

こんにちは、SSTでWeb脆弱性診断用のツール(スキャンツール)開発をしている坂本(Twitter, GitHub)です。 先日DeNA様がGitHub上で公開された PacketProxy を触ってみました。 https://github.com/DeNA/PacketProxy ここがすごい PacketProxyすごい!! 名前の通り、パケットレベルで中身を見たり、編集するのに向いてる。 javaソースで約4万8千行とそれなりの規模。 フレームワークやライブラリはあまり使わず、HTTP/WebSocketのパースなどを手作りしてる。 ソケット周りも Java8 時代のJDKライブラリベースで、Nettyみたいなフレームワークは使ってない。でも手作りでここまで作れるのはすごい。 DNS偽装 + invisible https proxy でスマホの通信を intercept できるよう

たとえば、かつてiptablesで設定していたIPv4に関連するパケットフィルタリング設定は、nftablesにおいては「ip」というアドレスファミリに紐付けたテーブルを作成することで設定できる。同様に、ip6tablesやarptables、ebtablesで設定していたものはそれぞれ「ip6」や「arp」、「bridge」というアドレスファミリに紐付けたテーブルで設定する。 「inet」「および「netdev」アドレスファミリはnftablesで新たに導入されたもので、まず「inet」はIPv4およびIPv6の両方を対象にした設定を行えるアドレスファミリだ。従来IPv4とIPv6の両方にまたがったフィルタリングルールを設定したい場合はiptablesとip6tablesの両方で同じようなルールを追加する必要があったが、nftablesではinetアドレスファミリで指定することで単一の設

はじめに 昨年から DNS over TLS （DoT）、DNS over HTTPS （DoH） にまつわる動きが急速に活発になっています。 DoT は2016年に RFC7858 が出てしばらくは大きな動きはありませんでしたが、2017年11月にサービス開始した public DNS である Quad9 （9.9.9.9）、昨年4月開始の Cloudflare （1.1.1.1）が相次いで DoT に正式対応し、遅れて今年1月には Google Public DNS （8.8.8.8） も対応しました。クライアント側としては昨年8月リリースの Android 9 “Pie” が DoT に対応しています。 DoH は仕様の標準化より実装の方が先行しています。Cloudflare は DoT だけでなく DoH も昨年4月のサービス開始当初からサポートしています。Mozilla Fire

AWS EC2環境でのDNS Rebindingについて検証したので紹介します。 まずは、「前回までのおさらい」です。先日以下の記事でSSRF攻撃およびSSRF脆弱性について紹介しました。 SSRF(Server Side Request Forgery)徹底入門 この記事の中で、以下のように紹介しました。 ホスト名からIPアドレスを求める際にも以下の問題が発生します。 DNSサーバーが複数のIPアドレスを返す場合の処理の漏れ IPアドレスの表記の多様性（参考記事） IPアドレスチェックとHTTPリクエストのタイミングの差を悪用した攻撃（TOCTOU脆弱性） リクエスト先のWebサーバーが、攻撃対象サーバーにリダイレクトする 上記のTOCTOU(Time of check to time of use)問題は、DNSの名前解決の文脈ではDNS Rebindingとも呼ばれます。 DNS R

なぜ今までのDNSでは問題があるのか インターネット上の通信の多くは、ブラウザを利用したウェブによるものです。 セキュリティ向上のため、GoogleやFireFoxといった大手ブラウザベンダーが平文通信であるHTTPから暗号通信であるHTTPSへの移行を推奨し、盗聴・改竄・なりすましといった問題を解決することが出来ます。 しかしながら、そのHTTPS通信をする前のDNSによるドメイン解決は暗号化されておらず盗聴でアクセスするホスト名を把握される、なりすましで偽の応答を返されるといった可能性があります。 それを防ぐための方法の1つが、DNS over HTTPSです。 DNS over HTTPSとは 今までDNSサーバ（フルリゾルバ）の（主に）UDPポート53番に対して行われていたDNSによる名前解決を、TCPポート443番に対するHTTPS(HTTP/2 over TLS)通信上で行うプ

SNI とは 一つのIPアドレスと一つのTCPポートで、複数のWebサイトをホスティングする技術の一つに、virtualhostがあります。 これは、HTTPリクエスト内で指定するドメイン名から、同じIPに対するアクセスをドメインごとに振り分ける機能です。 たとえば、以下のコマンドを実行すると、こんな出力がされます。 （ちなみに、vがリクエストヘッダの表示、 Iがボディの非表示のオプションです。） $ curl -v -I example.com * Trying xxxxx... * TCP_NODELAY set * Connected to example.com (xxxxx) port 80 (#0) > HEAD / HTTP/1.1 > Host: example.com > User-Agent: curl/7.62.0 > Accept: */* > …（省略） 真ん中の