Linux の sysctl net.ipv4. icmp_echo_ignore_broadcasts / macOS (XNU) sysctl net.inet.icmp.bmcastecho の実装を読む

Linuxsysctl net.ipv4. icmp_echo_ignore_broadcasts と、 macOS / XNU の sysctl net.inet.icmp.bmcastecho の実装を調べたエントリです

何の sysctl ですか?

Linuxsysctl net.ipv4. icmp_echo_ignore_broadcastsCIS BenchmarksSmurf 攻撃対策として取り上げられています。

www.cisecurity.org

Smurf 攻撃とは何ですか?

Smurf 攻撃自体の説明は他のサイトで確認してください

ja.wikipedia.org

SMURF攻撃とは、攻撃者が標的となるサーバーをInternet Control Message Protocol(ICMP)パケットで圧倒させようとする分散サービス妨害(DDoS)攻撃です。1つまたは複数のコンピューターネットワークに対して、標的のデバイスのスプーフィングIPアドレスでリクエストを行うことにより、コンピューターネットワークは標的サーバーに応答し、初期攻撃トラフィックを増幅し、潜在的に標的を圧倒し、アクセス不能にします。この攻撃ベクトルは一般に、解決された脆弱性と見なされており、もはや流行していません。

引用: https://www.cloudflare.com/ja-jp/learning/ddos/smurf-ddos-attack

sysctl net.ipv4. icmp_echo_ignore_broadcasts の詳細

sysctl net.ipv4. icmp_echo_ignore_broadcasts あるいは /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts の説明を、Red Hat Cusotmer Portal から引用します。

icmp_echo_ignore_all 及び icmp_echo_ignore_broadcasts — 各ホストからの ICMP ECHO パケット、もしくはブロードキャスト及びマルチキャストのアドレスを起点とする ICMP ECHO パケットのみを無視することをそれぞれカーネルに許可します。0 の値は、カーネルによる応答を許可し、1 の値はパケットを無視します。

引用: https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-dir-sys

macOS / XNU にも同様の sysctl 設定はあるのか?

macOS ( XNU ) では、Linux と同様に機能する sysctl として sysctl net.inet.icmp.bmcastecho が用意されています。なお、bmcastechoBroadcast Multicast Echo の略称のようです。

sysctl の実装を読もう

Smurf 攻撃の sysctl の設定方法を取り扱った記事はたくさんありますが、実装 (= カーネルのソース) まで踏み込んでるエントリは無いようなので、調べて見ましょう。

macOS ( XNU ) のソースも調べてました

続きを読む

UNIX Domain Socket の SO_SNDBUF, SO_RCVBUF についての覚書 (2) - macOS XNU のnet.local.stream.sendspace 周辺のソースを読む

hiboma.hatenadiary.jp

このエントリの続きです。

このエントリの内容

macOSカーネル ( XNU ) をソースで sysctl net.local.stream.sendspace の周辺のコードを眺める内容です。

私はBSD系のカーネルに馴染みがないので、手探りで調べつつ内容を書き記した内容になります。詳細・正確な記述・説明を読みたい場合は、別のサイトや文献を当たってください。

続きを読む

UNIX Domain Socket の SO_SNDBUF, SO_RCVBUF についての覚書

macOSLinuxUNIX Domain Socket の SO_SNDBUF, SO_RCVBUF について調べていた。

経緯

会社で @kurotaky のトラブルシューティングの相談を受けた際の覚書。

下記のように UNIX Domain Socket を挟んで IPC しているコードがあり、macOSLinux で挙動が違っているのを調べていた。Linux では Go Ethereum が送ってくるデータを全部読み出せるが、macOS だと一部 ( 8192 バイト 注1 ) しか読み出せないとのことだった。

Ruby のコード <----- UNIX Domain Socket -----> Go Ethereum

色々調べてみたところ、macOS / LinuxUNIX Domain Socket のデフォルトの SO_SNDBUF, SO_RCVBUF (注2) が違うことで、Ruby 側で 1回の recvmsg(2) で取り出せるデータのサイズが異なっているのが問題だったようだ。

続きを読む

Semantic Software Design - Chapter 2. The Production of Concepts

learning.oreilly.com

2章の途中まで流し読み。抽象度の高い話が続いていて、咀嚼できない。実践的な話だけ拾い集めて読む。3章に入ると「脱構築」や「デリダ」とか出てくるぽくて、そこまで風呂敷広げるんかい〜 。そういうこともあって、Google 翻訳 / DeepL 翻訳で読んでるとちょいと辛い感じがある


Part of the work of the new architect-creative is to help create those requirements, both functional and nonfunctional. To see what needs to be done, what might work, what structure accounts for what we think we want the system to do, or what we think someone else we’ve never met might want or need the system to do three years from now when it’s harder to change and how to accommodate that.

新しいアーキテクト=クリエイティブの仕事の一部は、機能的なものも非機能的なものも含めて、そうした要求の作成を支援することである。何が必要で、何が機能し、どのような構造で、私たちがシステムに何をさせたいと考えているか、あるいは私たちが会ったことのない誰かが3年後にシステムを変更することが難しくなったときに何をしたいか、何を必要とするかを説明し、それにどう対応するかを確認することです。


This book has a single primary purpose among many purposes: to help you better design software. To do so, it advances a new model, a new approach, a new set of ideas and tools called semantic software design.

本書は、多くの目的の中で、たった一つの主要な目的、すなわち、より良いソフトウェア設計を支援することを目的としています。そのために、セマンティックソフトウェアデザインと呼ばれる新しいモデル、新しいアプローチ、新しいアイデアとツールのセットを進めています。

抽象度の高い話が続いていて迷子になりそうなところで、なんのための本なんだっけ? を改めて再確認する


The problem with software—a chief reason our projects fail—is a failure of our language. We are not architects. Not even close. We do not build buildings with an obvious and known prior purpose, which is an approximate copy of the same kind of building people have been making and using for thousands of years, using tangible commodity materials on a factory line. Quite the opposite.

ソフトウェアの問題点、つまりプロジェクトが失敗する最大の理由は、言葉の問題です。私たちはアーキテクトではありません。それどころではありません。私たちは、何千年も前から人々が作って使ってきたのと同じような建物を、目に見える商品材料を使って、工場のラインでほぼコピーしたような、明白で既知の事前目的の建物を作ることはしません。全く逆だ。

あんちぽさんか、しばたさんが、ソフトウェアってコード書き出すまでは頭の中にあるもんだから みたいな話をずっと前にしてたの思い出す。


Accomplish, Avoid, Fix

To be useful in a typical software project, your concept will generally be about one of three things: accomplishing something, avoiding something, or fixing something:

一般的なソフトウェアプロジェクトで役に立つには、一般的に「何かを達成する」「何かを回避する」「何かを修正する」という3つのうちのどれかをコンセプトとすることになります。

...

顧客が達成したいこと、避けたいこと、修正したいことを考える。文章で、この質問に答えてください。 誰が、いつまでに、どのような理由で、何を望んでいるのか?


Divergent and convergent thinking

As you work through your concept, you should go through two stages, divergent thinking, followed by convergent thinking.

コンセプトを練る際には、発散的思考と収束的思考の2段階を経る必要があります。

なんでもかんでもあげてみる考え方から、コンセプトに絞り込んでいく考え方の話。

convergent thinking は以下の通り続く

1. What absolute constraints are known?
2. How might these candidates fit within a budget, if known?
3. How might these candidates fit within a timeline?
4. What known elements of the business or technology strategy do these candidates support?
5. What new opportunities does this create?
6. What positive and negative elements of our current landscape of People, Process, and Technology does this enhance or aggravate?
7. What people or roles would need to approve or work together with these candidates?

エレベーターピッチ的なフレームワーク紹介への導入の文章


ここで 著者の Concept Canvas が図示で紹介される

f:id:hiboma:20220107103950p:plain

1. Concept statement
2. Statement of need
3. Alignment with strategy
4. Idea components
5. Path forward

ここまで読んで終わり。

Semantic Software Design - Chapter 1. Origins of Software Architecture

learning.oreilly.com

1章を流し読み。目に留まった箇所の引用を掲載する。引用の翻訳は DeepL による。


This is a way of saying that software didn’t even know it existed as its own field, separate from hardware, a mere 50 years ago. Very smart, accomplished professionals in the field were not sure whether software was even a “thing,” something that had any independent value.

これは、ほんの50年前までは、ソフトウェアがハードウェアとは別の独立した分野として存在することさえ知らなかったということを意味している。その分野の非常に賢い、熟練した専門家たちは、ソフトウェアが「もの」であり、独立した価値を持つものであるかどうかさえ分からなかったのです。

ソフトウェア/ハードウェアが別物として当然だと思っていたので、古典の話は興味深い。


The term “architect” as used in software was not popularized until the early 1990s. Perhaps the first suggestion that there would be anything for software practitioners to learn from architects came in that NATO Software Engineering conference in Germany in 1968, from Peter Naur:

ソフトウェアで使われる「アーキテクト」という言葉が一般化したのは、1990年代初頭のことです。おそらく、ソフトウェアの実務家がアーキテクトから学ぶべきことがあるという最初の提案は、1968年にドイツで開催されたNATOソフトウェアエンジニアリング会議において、Peter Naur氏からなされたものでしょう。

提案自体はずいぶんと古いものらしい (ただし、続く本文で The problem with Naur’s statement is obvious: it’s simply false. It’s also unsupported. として、声明自体が間違っていると主張されている)


Dividing roles into distinct responsibilities within a process is one useful and very popular way to approach production in business. Such division makes the value of each moment in the process, each contribution to the whole, more direct and clear. This fashioning of the work, the “division of labor,” has the additional value of making each step observable and measurable.

ビジネスにおける生産活動のアプローチとして、工程内での役割を明確に分けることは有効であり、非常によく知られている方法の一つです。 このような分割により、プロセスの各瞬間の価値、全体への各貢献がより直接的かつ明確になる。このような仕事の組み立て、すなわち「分業」には、各ステップを観察し、測定できるようにするという付加価値もある。

GitHub Actions で一個のステップ実行時間が長くデバッグが大変だったのを、分割して解決しようとした ... というのを思い出したりした。その他、日々の開発でも意識せずにやってることもあるだろう

付録

https://learning.oreilly.com/library/view/semantic-software-design/9781492045946/ch01.html