「Sysctl」の版間の差分
(同期) |
(他言語へのリンクを追加) |
||
(4人の利用者による、間の31版が非表示) | |||
1行目: | 1行目: | ||
{{Lowercase title}} |
{{Lowercase title}} |
||
[[Category:カーネル]] |
[[Category:カーネル]] |
||
+ | [[Category:コマンド]] |
||
[[en:Sysctl]] |
[[en:Sysctl]] |
||
+ | [[ru:Sysctl]] |
||
[[Wikipedia:sysctl|sysctl]] は稼働中の[[カーネルパラメータ]]を確認・変更するためのツールです ([[公式リポジトリ]]の {{Pkg|procps-ng}} パッケージ)。sysctl は procfs ({{ic|/proc/}} の仮想プロセスファイルシステム) で実装されています。 |
[[Wikipedia:sysctl|sysctl]] は稼働中の[[カーネルパラメータ]]を確認・変更するためのツールです ([[公式リポジトリ]]の {{Pkg|procps-ng}} パッケージ)。sysctl は procfs ({{ic|/proc/}} の仮想プロセスファイルシステム) で実装されています。 |
||
+ | |||
+ | == インストール == |
||
+ | |||
+ | {{Pkg|procps-ng}} パッケージは、{{Pkg|base}} [[メタパッケージ]] の依存関係であるため、すでに [[インストール]] されている必要があります。 |
||
== 設定 == |
== 設定 == |
||
21行目: | 27行目: | ||
{{Note|カーネルドキュメントをインストールしている場合 ({{Pkg|linux-docs}})、sysctl 設定に関する詳細な情報が {{Ic|/usr/lib/modules/$(uname -r)/build/Documentation/sysctl/}} で読めます。sysctl 設定を変更する前にこれらを一読することが強く推奨されています。}} |
{{Note|カーネルドキュメントをインストールしている場合 ({{Pkg|linux-docs}})、sysctl 設定に関する詳細な情報が {{Ic|/usr/lib/modules/$(uname -r)/build/Documentation/sysctl/}} で読めます。sysctl 設定を変更する前にこれらを一読することが強く推奨されています。}} |
||
− | 設定の変更はファイルの操作によるか {{Ic|sysctl}} ユーティリティを使って行います。例えば、一時的に[[ |
+ | 設定の変更はファイルの操作によるか {{Ic|sysctl}} ユーティリティを使って行います。例えば、一時的に[[キーボードショートカット|マジック SysRq キー]]を有効にするには: |
# sysctl kernel.sysrq=1 |
# sysctl kernel.sysrq=1 |
||
34行目: | 40行目: | ||
== セキュリティ == |
== セキュリティ == |
||
− | [[セキュリティ#カーネルの |
+ | [[セキュリティ#カーネルの堅牢化]]を見て下さい。 |
== ネットワーク == |
== ネットワーク == |
||
40行目: | 46行目: | ||
=== パフォーマンスを向上させる === |
=== パフォーマンスを向上させる === |
||
+ | ==== 受信キューのサイズを増やす ==== |
||
− | {{Warning|以下の設定はロードバランシングや NAT を行っている場合にフレームがドロップする可能性があります。ローカルネットワークでしか通信しないサーバーで使ってください。}} |
||
+ | |||
+ | 受信したフレームは、ネットワークカード上のリングバッファから取り出した後、このキューに格納されます。 |
||
+ | |||
+ | 高速なカードの場合、この値を大きくすると、パケットの損失を防ぐのに役立ちます: |
||
+ | |||
+ | net.core.netdev_max_backlog = 16384 |
||
+ | |||
+ | {{Note|SIP ルータなどのリアルタイムな使用用途では、このオプションは高速な CPU を必要とします。そうしないと、キュー内のデータが古くなります。}} |
||
+ | |||
+ | ==== 最大接続数を増やす ==== |
||
+ | |||
+ | カーネルが受け付ける接続数の上限 (デフォルトは 128): |
||
+ | |||
+ | net.core.somaxconn = 8192 |
||
+ | |||
+ | {{Note|1=デフォルト値はカーネル 5.4 で 4096 に上げられました。[https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=19f92a030ca6d772ab44b22ee6a01378a8cb32d4]}} |
||
+ | {{Warning|この値を大きくしてもパフォーマンスの恩恵を受けられるのはおそらく高負荷なサーバのみです。これにより、処理速度の低下 (例: シングルスレッドのブロッキングサーバ) やワーカー・スレッド/プロセス数の不足が発生する可能性があります。[https://serverfault.com/questions/518862/will-increasing-net-core-somaxconn-make-a-difference/519152]}} |
||
+ | |||
+ | ==== ネットワークインターフェイス専用のメモリを増やす ==== |
||
+ | |||
+ | {{Accuracy|このセクションは Cloudflare のブログ記事が動機となっているようですが、 [https://github.com/redhat-performance/tuned/blob/master/profiles/network-throughput/tuned.conf#L10 RedHat の調整済みプロファイル]ではさらに小さい値を提案しており、''これは 40 Gb の速度でのみ必要と思われます'' と主張しています。したがって、これらの設定は一般的なハードウェアでは役に立たないようです。}} |
||
+ | |||
+ | デフォルトでは、Linux ネットワークスタックは、WAN リンクを介して高速で大規模なファイル転送をする (つまり、多くのネットワークパケットを扱う) ように設定されていません。正しい値を設定すると、メモリリソースを節約できる場合があります: |
||
+ | |||
+ | net.core.rmem_default = 1048576 |
||
+ | net.core.rmem_max = 16777216 |
||
+ | net.core.wmem_default = 1048576 |
||
+ | net.core.wmem_max = 16777216 |
||
+ | net.core.optmem_max = 65536 |
||
+ | net.ipv4.tcp_rmem = 4096 1048576 2097152 |
||
+ | net.ipv4.tcp_wmem = 4096 65536 16777216 |
||
+ | |||
+ | デフォルトの UDP 制限 {{ic|4096}} を増やすこともできます: |
||
+ | |||
+ | net.ipv4.udp_rmem_min = 8192 |
||
+ | net.ipv4.udp_wmem_min = 8192 |
||
+ | |||
+ | 詳細および推奨値については、次の資料を参照してください。 |
||
+ | |||
+ | * http://www.nateware.com/linux-network-tuning-for-2013.html |
||
+ | * https://blog.cloudflare.com/the-story-of-one-latency-spike/ |
||
+ | |||
+ | ==== TCP Fast Open を有効にする ==== |
||
+ | |||
+ | TCP Fast Open は、Transmission Control Protocol (TCP) の拡張機能であり、送信側の初期 TCP SYN 中にデータを交換できるようにすることで、ネットワーク遅延の低減に役立ちます。[https://www.keycdn.com/support/tcp-fast-open/] デフォルトの {{ic|1}} の代わりに値 {{ic|3}} を使用すると、着信接続と発信接続の両方で TCP Fast Open が許可されます: |
||
+ | |||
+ | net.ipv4.tcp_fastopen = 3 |
||
+ | |||
+ | ==== 保留中の接続処理を微調整する ==== |
||
+ | |||
+ | {{ic|tcp_max_syn_backlog}} は、'Waiting Acknowledgment' 状態の保留接続の最大キュー長です。 |
||
+ | |||
+ | SYN フラッド DOS 攻撃を受けた場合、このキューはすぐにいっぱいになってしまいます。その時点で [[Wikipedia:ja:SYN cookies|TCP SYN cookies]] が開始され、システムが正規のトラフィックに応答し続け、悪意のある IP をブロックするためのアクセス権を取得できるようにします。 |
||
+ | |||
+ | サーバがピーク時に過負荷になる場合は、この値を少し大きくするとよいかもしれません: |
||
+ | |||
+ | net.ipv4.tcp_max_syn_backlog = 8192 |
||
+ | |||
+ | {{ic|tcp_max_tw_buckets}} は TIME_WAIT 状態のソケットの最大数です。 |
||
+ | |||
+ | この数に達すると、システムはこの状態のソケットの破棄を開始します。 |
||
+ | |||
+ | 単純な DOS 攻撃を防ぐには、この値を大きくします: |
||
+ | |||
+ | net.ipv4.tcp_max_tw_buckets = 2000000 |
||
+ | |||
+ | {{ic|tcp_tw_reuse}} は、新しいタイムスタンプが以前の接続で記録された最新のタイムスタンプよりも大きい場合に、TCP が TIME-WAIT 状態の既存の接続を新しい発信接続で再利用するかどうかを設定します。 |
||
+ | |||
+ | これにより、使用可能なネットワーク・ソケットの不足を回避するのに役立ちます: |
||
− | # reuse/recycle time-wait sockets |
||
net.ipv4.tcp_tw_reuse = 1 |
net.ipv4.tcp_tw_reuse = 1 |
||
− | net.ipv4.tcp_tw_recycle = 1 |
||
+ | ソケットが強制的にクローズされる前に final FIN パケットを待つ秒数を指定します。これは厳密には TCP 仕様に違反しますが、サービス拒否攻撃を防ぐために必要です。Linux 2.2 では、デフォルト値は 180 [https://access.redhat.com/solutions/41776] でした: |
||
− | === TCP/IP スタックの防御 === |
||
+ | net.ipv4.tcp_fin_timeout = 10 |
||
− | 以下では IPv4 プロトコルでカーネルのネットワークセキュリティを厳しくするオプションのパラメータセットを示しています。同一の効果がある IPv6 パラメータも存在します。 |
||
+ | {{ic|tcp_slow_start_after_idle}} は、新しい接続に対してだけ TCP をデフォルトのウィンドウサイズで開始するか、またはアイドル状態が長すぎる既存の接続に対してもTCPを開始するかを設定します。 |
||
− | ユースケースによって、例えば[[ルーター]]として使用するシステムで、他のパラメータが役に立ったり必要になることもあります。 |
||
+ | この設定は、永続的な単一接続のパフォーマンスを無効にし、オフにすることもできます: |
||
− | {{bc|1= |
||
− | #### ipv4 networking and equivalent ipv6 parameters #### |
||
+ | net.ipv4.tcp_slow_start_after_idle = 0 |
||
− | ## TCP SYN cookie protection (default) |
||
− | ## helps protect against SYN flood attacks |
||
− | ## only kicks in when net.ipv4.tcp_max_syn_backlog is reached |
||
− | net.ipv4.tcp_syncookies = 1 |
||
+ | ==== TCP キープアライブパラメータを変更する ==== |
||
− | ## protect against tcp time-wait assassination hazards |
||
− | ## drop RST packets for sockets in the time-wait state |
||
− | ## (not widely supported outside of linux, but conforms to RFC) |
||
− | net.ipv4.tcp_rfc1337 = 1 |
||
+ | [[Wikipedia:ja:キープアライブ#TCPキープアライブ|TCPキープアライブ]]は、相手側が応答を停止したかどうかを判断するのに役立つ TCP 接続のメカニズムです。TCP は、アイドル時間が経過すると、ヌルデータを含むキープアライブプローブをネットワークピアに数回送信します。ピアが応答しない場合、ソケットは自動的に閉じられます。デフォルトでは、TCP キープアライブプロセスはソケットのアクティビティを2時間 (7200秒) 待機してから最初のキープアライブプローブを送信し、75秒ごとに再送信します。TCP/IP ソケット通信が行われていてアクティブである限り、キープアライブパケットは必要ありません。 |
||
− | ## sets the kernels reverse path filtering mechanism to value 1(on) |
||
− | ## will do source validation of the packet's recieved from all the interfaces on the machine |
||
− | ## protects from attackers that are using ip spoofing methods to do harm |
||
− | net.ipv4.conf.all.rp_filter = 1 |
||
− | net.ipv6.conf.all.rp_filter = 1 |
||
+ | {{Note|次の設定では、アプリケーションは120秒後 (60秒+10秒+10秒+10秒+10秒+10秒+10秒) にデッド TCP 接続を検出します。}} |
||
− | ## tcp timestamps |
||
− | ## + protect against wrapping sequence numbers (at gigabit speeds) |
||
− | ## + round trip time calculation implemented in TCP |
||
− | ## - causes extra overhead and allows uptime detection by scanners like nmap |
||
− | ## enable @ gigabit speeds |
||
− | net.ipv4.tcp_timestamps = 0 |
||
− | #net.ipv4.tcp_timestamps = 1 |
||
+ | net.ipv4.tcp_keepalive_time = 60 |
||
− | ## log martian packets |
||
− | net.ipv4. |
+ | net.ipv4.tcp_keepalive_intvl = 10 |
+ | net.ipv4.tcp_keepalive_probes = 6 |
||
+ | ==== MTU プローブを有効にする ==== |
||
− | ## ignore echo broadcast requests to prevent being part of smurf attacks (default) |
||
− | net.ipv4.icmp_echo_ignore_broadcasts = 1 |
||
+ | [[Wikipedia:ja:Maximum Transmission Unit|maximum transmission unit (MTU)]] が長いほどパフォーマンスは向上しますが、信頼性は低下します。 |
||
− | ## ignore bogus icmp errors (default) |
||
− | net.ipv4.icmp_ignore_bogus_error_responses = 1 |
||
+ | これは、パケットが失われると、より多くのデータが再送信されることになり、インターネット上の多くのルータは非常に長いパケットを配信できないためです: |
||
− | ## send redirects (not a router, disable it) |
||
− | net.ipv4.conf.all.send_redirects = 0 |
||
+ | net.ipv4.tcp_mtu_probing = 1 |
||
− | ## ICMP routing redirects (only secure) |
||
+ | |||
− | #net.ipv4.conf.all.secure_redirects = 1 (default) |
||
+ | 詳細については、https://blog.cloudflare.com/path-mtu-discovery-in-practice/ を参照してください。 |
||
− | net.ipv4.conf.default.accept_redirects=0 |
||
+ | |||
− | net.ipv4.conf.all.accept_redirects=0 |
||
+ | ==== TCP タイムスタンプ ==== |
||
− | net.ipv6.conf.default.accept_redirects=0 |
||
+ | |||
− | net.ipv6.conf.all.accept_redirects=0 |
||
+ | {{Warning|TCP タイムスタンプは、TCP で実装されている (ギガビット単位の速度での) シーケンス番号とラウンドトリップタイム計算におけるオーバーフローから保護してくれます。セキュリティリスクが発生する可能性があるため、TCP タイムスタンプをオフにすることはお勧めしません。[https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf]}} |
||
− | }} |
||
+ | |||
+ | タイムスタンプ生成を無効にすると、スパイクが減少し、ギガビットネットワークのパフォーマンスが向上する可能性があります: |
||
+ | |||
+ | net.ipv4.tcp_timestamps = 0 |
||
+ | |||
+ | ==== TCP Selective Acknowledgement ==== |
||
+ | |||
+ | TCP Selective Acknowledgement (TCP SACK) は、受信側が損失セグメントに関するより詳細な情報を送信側に与えられるようにして、再転送の量を減らします。これはブーリアン値 {{ic|tcp_sack}} によって制御されます。これは高レイテンシなネットワークにおいて有用ですが、高速な LAN においてはこれを無効化することでスループットを増加させることができます。また、{{ic|tcp_dsack}} も無効化してください。SACK を送信しない場合、D-SACK を送信したくないでしょうから。Forward Acknowledgement は SACK の上で動作し、SACK が無効化されていると Forward Acknowledgement も無効化されます。[https://cromwell-intl.com/open-source/performance-tuning/tcp.html] |
||
+ | |||
+ | net.ipv4.tcp_sack = 1 |
||
+ | |||
+ | ==== BBR を有効にする ==== |
||
+ | |||
+ | [[Wikipedia:TCP congestion control#TCP BBR|BBR 輻輳制御アルゴリズム]]は、インターネットトラフィックのより高い帯域幅とより低いレイテンシを実現するのに役立ちます。まず、{{ic|tcp_bbr}} モジュールを[[カーネルモジュール#手動でモジュールを扱う|ロード]]してください。 |
||
+ | |||
+ | {{Note|[https://github.com/google/bbr/blob/master/README BBR の GitHub ページ]には、「これは公式の Google 製品ではありません」と書かれてあります。}} |
||
+ | |||
+ | net.core.default_qdisc = cake |
||
+ | net.ipv4.tcp_congestion_control = bbr |
||
+ | |||
+ | ==== エフェメラルポートの範囲を拡大 ==== |
||
+ | |||
+ | {{Accuracy|この変更によってパフォーマンスはどのように向上しますか? [[:en:Talk:sysctl#net.ipv4.ip_local_port_range|英語版の議論ページ]]}} |
||
+ | |||
+ | [[Wikipedia:ja:エフェメラルポート|エフェメラルポート]]は通常、Transmission Control Protocol (TCP) 、User Datagram Protocol (UDP) 、または Stream Control Transmission Protocol (SCTP) によって、クライアント/サーバ通信のクライアント側のポート割り当てとして使用されます。 |
||
+ | |||
+ | net.ipv4.ip_local_port_range = 30000 65535 |
||
+ | |||
+ | === TCP/IP スタックの強化 === |
||
+ | |||
+ | IPv4 プロトコルのカーネルのネットワークセキュリティオプションを強化するためのパラメータセットと、同等のものが存在する関連する IPv6 パラメータを次に示します。 |
||
+ | |||
+ | システムを [[ルーター]] として使用するなど、一部のユースケースでは、他のパラメータも有用な場合や必要な場合があります。 |
||
+ | |||
+ | ==== TCP SYN cookie 保護==== |
||
+ | |||
+ | SYN flood 攻撃からの保護に役立ちます {{ic|net.ipv4.tcp_max_syn_backlog}} に到達したときにだけ起動します。詳細については、 [https://cateee.net/lkddb/web-lkddb/SYN_COOKIES.html] を参照してください。{{Pkg|linux}} 5.10 以降では、デフォルトで設定されています。 |
||
+ | |||
+ | net.ipv 4.tcp_syncookies = 1 |
||
+ | |||
+ | ==== TCP rfc1337 ==== |
||
+ | |||
+ | {{Accuracy|これは TCP 標準の一部ではないようですか?説明が正確でない可能性があります。[https://serverfault.com/questions/787624/why-isnt-net-ipv4-tcp-rfc1337-enabled-by-default]|section=net.ipv4.tcp_rfc1337}} |
||
+ | |||
+ | tcp time-wait assassination hazard から保護し、time-wait 状態のソケットの RST パケットを破棄します。Linux 以外では広くサポートされていませんが、RFC に準拠しています。 |
||
+ | |||
+ | net.ipv4.tcp_rfc1337 = 1 |
||
+ | |||
+ | ==== リバースパスフィルタリング ==== |
||
+ | |||
+ | リバースパスフィルタリングを有効にすると、カーネルはマシン上のすべてのインタフェースから受信したパケットのソース検証を行います。これにより、IP スプーフィング方式を使用して被害を与える攻撃者から保護できます。 |
||
+ | |||
+ | カーネルのデフォルト値は {{ic|0}} (ソース検証なし) ですが、systemd は {{ic|/usr/lib/sysctl.d/50 default.conf}} を、{{ic|net.ipv 4.conf.all.rp_filter}} を {{ic|2}} (loose mode) [https://github.com/systemd/systemd/pull/10971] に設定して出荷します。 |
||
+ | |||
+ | 次に、リバースパスフィルタリングメカニズムを value {{ic|1}} (strict モード) に設定します。 |
||
+ | |||
+ | net.ipv4.conf.default.rp_filter = 1 |
||
+ | net.ipv4.conf.all.rp_filter = 1 |
||
+ | |||
+ | {{ic|net.ipv4.conf.default.*}}、{{ic|net.ipv4.conf.''interface''.*}} および {{ic|net.ipv4.conf.all.*}} については、 [https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html ip-sysctl.html] を参照してください。 |
||
+ | |||
+ | ==== martian パケットをログに記録する ==== |
||
+ | |||
+ | [[Wikipedia:Martian packet|martian packet]] は、Internet Assigned Numbers Authority (IANA) による特殊な使用のために予約されている送信元アドレスまたは宛先アドレスを指定する IP パケットです。詳細は、[[wikipedia:Reserved_IP_addresses|Reserved IP addresses]] を参照してください。 |
||
+ | |||
+ | しばしば martian とルーティング不可能なパケットが危険な目的のために使われるかもしれません。さらなる検査のためにこれらのパケットをログに記録することは有用かもしれません [https://www.cyberciti.biz/faq/linux-log-suspicious-martian-packets-un-routable-source-addresses/] |
||
+ | |||
+ | net.ipv4.conf.default.log_martians = 1 |
||
+ | net.ipv4.conf.all.log_martians = 1 |
||
+ | |||
+ | {{Note|これにより、ログが大量の情報でいっぱいになる可能性があります。テスト用にのみ有効にすることをお勧めします。}} |
||
+ | |||
+ | ==== ICMP リダイレクトを無効にする ==== |
||
+ | |||
+ | 背景は [https://askubuntu.com/questions/118273/what-are-icmp-redirects-and-should-they-be-blocked What are ICMP redirects? Should they be blocked?] です。 |
||
+ | |||
+ | ICMP リダイレクト受け入れをディセーブルにするには、次の手順を実行します。 |
||
+ | |||
+ | net.ipv4.conf.all.accept_redirects = 0 |
||
+ | net.ipv4.conf.default.accept_redirects = 0 |
||
+ | net.ipv4.conf.all.secure_redirects = 0 |
||
+ | net.ipv4.conf.default.secure_redirects = 0 |
||
+ | net.ipv6.conf.all.accept_redirects = 0 |
||
+ | net.ipv6.conf.default.accept_redirects = 0 |
||
+ | |||
+ | ルータ以外で ICMP リダイレクト送信をディセーブルにするには、次の手順を実行します。 |
||
+ | |||
+ | net.ipv4.conf.all.send_redirects = 0 |
||
+ | net.ipv4.conf.default.send_redirects = 0 |
||
+ | |||
+ | ==== ICMP エコー要求を無視する ==== |
||
+ | |||
+ | ICMP エコー (別名 ping) リクエストを無効にするには: |
||
+ | |||
+ | net.ipv4.icmp_echo_ignore_all = 1 |
||
+ | net.ipv6.icmp.echo_ignore_all = 1 |
||
+ | |||
+ | {{Note|これにより、ICMP エコー応答に依存する監視ツールやアプリケーションで問題が発生する可能性があることに注意してください。}} |
||
+ | |||
+ | === その他 === |
||
+ | |||
+ | ==== 特権を持たないユーザが IPPROTO_ICMP ソケットを作成できるようにする ==== |
||
+ | |||
+ | {{Out of date|{{ic|/usr/lib/sysctl.d/50 default.conf}} は、{{ic|net.ipv4.ping_group_range}} を {{ic|0 2147483647}} に設定します。}} |
||
+ | |||
+ | IPPROTO_ICMP ({{man|7|icmp}}) ソケットタイプを使用すると、{{man|7|raw}} ソケット (CAP_NET_RAW [[ケイパビリティ]] または SUID ビットを適切な特権所有者で開く必要のある操作) を開くことなく、 ICMP_ECHO メッセージを送信し、対応する ICMP_ECHOREPLY メッセージを受信できるようになります。これらの ICMP_ECHO メッセージはアプリケーションによって送信されるため、IPPROTO_ICMP ソケットは ICMP エコーソケットとは別に [[ping]] ソケットとも呼ばれます。 |
||
+ | |||
+ | {{ic|ping_group_range}} は、ユーザが IPPROTO_ICMP ソケットを作成できるグループの GID 範囲を決定します。さらに、 CAP_NET_RAW 機能の所有者も IPPROTO_ICMP ソケットを作成することができます。 |
||
+ | デフォルトでは、この範囲は {{ic|1 0}}で、root 以外の誰も IPPROTO_ICMP ソケットを作成できないことを意味します。 |
||
+ | |||
+ | この設定を利用するには、現在 raw ソケットを使っているプログラムは、代わりに IPPROTO_ICMP ソケットを使うように移植する必要があります。 |
||
+ | たとえば、QEMUはSLIRP (User-mode networking) に IPPROTO_ICMP を使用するため、QEMU を実行しているユーザーが IPPROTO_ICMP ソケットを作成できるようにすると、ゲストから ping を実行できるようになります。 |
||
+ | |||
+ | GID 100 のグループのメンバーであるユーザーのみが IPPROTO_ICMP ソケットを作成できるようにするには、次のようにします。 |
||
+ | |||
+ | net.ipv4.ping_group_range = 100 100 |
||
+ | |||
+ | システム内のすべてのユーザーが IPPROTO_ICMP ソケットを作成できるようにするには、次のようにします。 |
||
+ | |||
+ | net.ipv4.ping_group_range = 0 65535 |
||
== 仮想メモリ == |
== 仮想メモリ == |
||
− | Linux カーネルの |
+ | Linux カーネルの [[Wikipedia:virtual memory|virtual memory]] サブシステムの動作や、ディスクへのダーティデータの書き出しを調整するための重要なパラメータがいくつかあります。詳細については、公式の [https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html Linux kernel documentation] を参照してください。例: |
+ | * {{ic|1=vm.dirty_ratio = 10}} |
||
− | {{bc|1= |
||
+ | : 空きページと再利用可能ページを含む使用可能なメモリの合計に対する割合として、ディスク書き込みを生成するプロセスがダーティデータの書き込みを開始するページ数を含みます。 |
||
− | # Contains, as a percentage of total system memory, the number of pages at which |
||
− | # a process which is generating disk writes will start writing out dirty data. |
||
− | vm.dirty_ratio = 3 |
||
+ | * {{ic|1=vm.dirty_background_ratio = 5}} |
||
− | # Contains, as a percentage of total system memory, the number of pages at which |
||
+ | : バックグラウンドカーネルフラッシャのスレッドがダーティデータの書き込みを開始するページ数を、空きページと再利用可能ページを含む使用可能なメモリの合計に対する割合として含みます。 |
||
− | # the background kernel flusher threads will start writing out dirty data. |
||
+ | |||
− | vm.dirty_background_ratio = 2 |
||
+ | パラメータのコメントに記載されているように、これらの値を設定する場合は RAM の合計容量を考慮する必要があります。たとえば、使用可能なメモリの代わりに、インストールされているシステム RAM を使用すると簡単です。 |
||
+ | |||
+ | {{Warning| |
||
+ | * 比率の値を大きくすると、パフォーマンスが向上し、データ損失のリスクも高くなります。 |
||
+ | * この値を {{ic|0}} に設定すると、ディスクおよびスパイクで待機時間が長くなる可能性があります。 |
||
+ | 詳細については、https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ を参照してください。 |
||
}} |
}} |
||
+ | * RAM の {{ic|vm.dirty_ratio}} を 10% に設定することは、RAM が例えば 1GB (10%は {{#expr: 1000/10 round 0}} MB) の場合、妥当な値です。しかし、マシンの RAM がもっと大きい場合、たとえば 16GB (10%は {{#expr: 16/10 round 1 }} GB) になると、回転中のディスクに数秒の書き戻しが行われるため、割合が不釣り合いになることがあります。この場合、より妥当な値は {{ic|3}} です (16GB の 3% は約 491MB です) 。 |
||
− | コメントで説明されているように、これらの値を設定する際は RAM の合計量を考慮する必要があります。 |
||
+ | * 同様に、{{ic|vm.dirty_background_ratio}} を {{ic|5}} に設定することは、メモリ値が小さい場合は問題ありません、RAM 容量を考慮して調整してください。 |
||
+ | |||
+ | === VFS キャッシュ === |
||
+ | [https://www.kernel.org/doc/html/latest/filesystems/vfs.html virtual file system] (VFS) キャッシュパラメータの値を小さくすると、システムの応答性が向上する場合があります。 |
||
− | * {{ic|vm.dirty_ratio}} のデフォルトは 10 です (RAM の 10%)。RAM が 1GB の半分のときは RAM の 10% というのがコンセンサスで (つまり 10% は 50 MB 以下) 磁気ディスクならば合理的な値です。ただし RAM が大きい、例えば 16 GB のときは (10% は 1.6 GB 以下) 磁気ディスクにライトバックするのに数秒かかるのであまり良くありません。この場合に合理的な値は 3 です (16*0.03 ~ 491 MB)。 |
||
+ | * {{ic|1=vm.vfs_cache_pressure = 50}} |
||
− | * {{ic|vm.dirty_background_ratio}} は同じように、メモリが少ない時はデフォルトの 5 (% の RAM) が丁度良いですが、システムの RAM の量によって調整するべきです。 |
||
+ | : ディレクトリや inode オブジェクトのキャッシュ (VFS キャッシュ) に使用されるメモリをカーネルがどれくらい回収するか制御する値です。デフォルト値の 100 から低くするとカーネルは VFS キャッシュをあまり回収しなくなります (0 に設定してはいけません。メモリ不足状態になる可能性があります)。 |
||
== MDADM == |
== MDADM == |
||
140行目: | 322行目: | ||
vm.dirty_bytes = 4194304 |
vm.dirty_bytes = 4194304 |
||
+ | {{Note|{{ic|dirty_background_bytes}}および{{ic|dirty_bytes}} パラメータは、{{ic|dirty_background_ratio}} および {{ic|dirty_ratio}} ( [[sysctl#仮想メモリ]] を参照) に対応します。一度に指定できるパラメータは1つだけです。}} |
||
− | {{ic|kernel.io_delay_type}} を変更してみる (x86 のみ): |
||
− | * 0 - IO_DELAY_TYPE_0X80 |
||
− | * 1 - IO_DELAY_TYPE_0XED |
||
− | * 2 - IO_DELAY_TYPE_UDELAY |
||
− | * 3 - IO_DELAY_TYPE_NONE |
||
== 参照 == |
== 参照 == |
||
− | * |
+ | * {{man|8|sysctl}} と {{man|5|sysctl.conf}} |
− | * Linux カーネルドキュメント |
+ | * [https://www.kernel.org/doc/Documentation/sysctl/ /proc/sys/ の Linux カーネルドキュメント] |
* カーネルドキュメント: [https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt IP Sysctl] |
* カーネルドキュメント: [https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt IP Sysctl] |
||
+ | * [http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.html sysctl のカーネルネットワークパラメータ] |
||
− | * SysCtl.conf Tweaked for Security and Cable Speed [http://blog.gotux.net/code/config/sysctl/] |
||
+ | * [https://sysctl-explorer.net sysctl-explorer.net – an initiative to facilitate the access of Linux' sysctl reference documentation] |
||
− | * sysctl のカーネルネットワークパラメータ [http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.html] |
||
+ | * [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-server_security-disable-source-routing Disable Source Routing - Red Hat Customer Portal] |
||
+ | * [https://www.suse.com/documentation/sles11/book_hardening/data/sec_sec_prot_general_kernel.html SUSE handbook about Security Features in the Kernel] |
2024年3月21日 (木) 16:00時点における最新版
sysctl は稼働中のカーネルパラメータを確認・変更するためのツールです (公式リポジトリの procps-ng パッケージ)。sysctl は procfs (/proc/
の仮想プロセスファイルシステム) で実装されています。
目次
インストール
procps-ng パッケージは、base メタパッケージ の依存関係であるため、すでに インストール されている必要があります。
設定
sysctl のプリロード/設定ファイルは /etc/sysctl.d/99-sysctl.conf
に作成することができます。systemd では、/etc/sysctl.d/
と /usr/lib/sysctl.d/
はカーネルの sysctl パラメータにどちらも使えるディレクトリです。名前と元のディレクトリによって処理される順番が決まります。最後のパラメータによって前の方のパラメータが置き換えられるので順番は重要です。例えば、/usr/lib/sysctl.d/50-default.conf
に書かれたパラメータは /etc/sysctl.d/50-default.conf
や両方のディレクトリよりも後に処理される設定ファイルにある同じパラメータによって置き換えられます。
全ての設定ファイルを手動でロードするには、次を実行します:
# sysctl --system
適用される階層が出力されます。単一のパラメータファイルを指定してロードすることも可能です:
# sysctl -p filename.conf
詳しくは the new configuration files や systemd の sysctl.d man ページ を見て下さい。
利用可能なパラメータは /proc/sys/
以下に並んでいます。例えば、kernel.sysrq
パラメータはファイルシステム上の /proc/sys/kernel/sysrq
ファイルにあたります。sysctl -a
コマンドを使うことで現在利用可能な値を全て表示することができます。
設定の変更はファイルの操作によるか sysctl
ユーティリティを使って行います。例えば、一時的にマジック SysRq キーを有効にするには:
# sysctl kernel.sysrq=1
もしくは:
# echo "1" > /proc/sys/kernel/sysrq
再起動後も変更を維持させるには、/etc/sysctl.d/99-sysctl.conf
や他の /etc/sysctl.d/
内の適用されるパラメータファイルに適切な行を追加・編集してください。
セキュリティ
セキュリティ#カーネルの堅牢化を見て下さい。
ネットワーク
パフォーマンスを向上させる
受信キューのサイズを増やす
受信したフレームは、ネットワークカード上のリングバッファから取り出した後、このキューに格納されます。
高速なカードの場合、この値を大きくすると、パケットの損失を防ぐのに役立ちます:
net.core.netdev_max_backlog = 16384
最大接続数を増やす
カーネルが受け付ける接続数の上限 (デフォルトは 128):
net.core.somaxconn = 8192
ネットワークインターフェイス専用のメモリを増やす
デフォルトでは、Linux ネットワークスタックは、WAN リンクを介して高速で大規模なファイル転送をする (つまり、多くのネットワークパケットを扱う) ように設定されていません。正しい値を設定すると、メモリリソースを節約できる場合があります:
net.core.rmem_default = 1048576 net.core.rmem_max = 16777216 net.core.wmem_default = 1048576 net.core.wmem_max = 16777216 net.core.optmem_max = 65536 net.ipv4.tcp_rmem = 4096 1048576 2097152 net.ipv4.tcp_wmem = 4096 65536 16777216
デフォルトの UDP 制限 4096
を増やすこともできます:
net.ipv4.udp_rmem_min = 8192 net.ipv4.udp_wmem_min = 8192
詳細および推奨値については、次の資料を参照してください。
- http://www.nateware.com/linux-network-tuning-for-2013.html
- https://blog.cloudflare.com/the-story-of-one-latency-spike/
TCP Fast Open を有効にする
TCP Fast Open は、Transmission Control Protocol (TCP) の拡張機能であり、送信側の初期 TCP SYN 中にデータを交換できるようにすることで、ネットワーク遅延の低減に役立ちます。[3] デフォルトの 1
の代わりに値 3
を使用すると、着信接続と発信接続の両方で TCP Fast Open が許可されます:
net.ipv4.tcp_fastopen = 3
保留中の接続処理を微調整する
tcp_max_syn_backlog
は、'Waiting Acknowledgment' 状態の保留接続の最大キュー長です。
SYN フラッド DOS 攻撃を受けた場合、このキューはすぐにいっぱいになってしまいます。その時点で TCP SYN cookies が開始され、システムが正規のトラフィックに応答し続け、悪意のある IP をブロックするためのアクセス権を取得できるようにします。
サーバがピーク時に過負荷になる場合は、この値を少し大きくするとよいかもしれません:
net.ipv4.tcp_max_syn_backlog = 8192
tcp_max_tw_buckets
は TIME_WAIT 状態のソケットの最大数です。
この数に達すると、システムはこの状態のソケットの破棄を開始します。
単純な DOS 攻撃を防ぐには、この値を大きくします:
net.ipv4.tcp_max_tw_buckets = 2000000
tcp_tw_reuse
は、新しいタイムスタンプが以前の接続で記録された最新のタイムスタンプよりも大きい場合に、TCP が TIME-WAIT 状態の既存の接続を新しい発信接続で再利用するかどうかを設定します。
これにより、使用可能なネットワーク・ソケットの不足を回避するのに役立ちます:
net.ipv4.tcp_tw_reuse = 1
ソケットが強制的にクローズされる前に final FIN パケットを待つ秒数を指定します。これは厳密には TCP 仕様に違反しますが、サービス拒否攻撃を防ぐために必要です。Linux 2.2 では、デフォルト値は 180 [4] でした:
net.ipv4.tcp_fin_timeout = 10
tcp_slow_start_after_idle
は、新しい接続に対してだけ TCP をデフォルトのウィンドウサイズで開始するか、またはアイドル状態が長すぎる既存の接続に対してもTCPを開始するかを設定します。
この設定は、永続的な単一接続のパフォーマンスを無効にし、オフにすることもできます:
net.ipv4.tcp_slow_start_after_idle = 0
TCP キープアライブパラメータを変更する
TCPキープアライブは、相手側が応答を停止したかどうかを判断するのに役立つ TCP 接続のメカニズムです。TCP は、アイドル時間が経過すると、ヌルデータを含むキープアライブプローブをネットワークピアに数回送信します。ピアが応答しない場合、ソケットは自動的に閉じられます。デフォルトでは、TCP キープアライブプロセスはソケットのアクティビティを2時間 (7200秒) 待機してから最初のキープアライブプローブを送信し、75秒ごとに再送信します。TCP/IP ソケット通信が行われていてアクティブである限り、キープアライブパケットは必要ありません。
net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 10 net.ipv4.tcp_keepalive_probes = 6
MTU プローブを有効にする
maximum transmission unit (MTU) が長いほどパフォーマンスは向上しますが、信頼性は低下します。
これは、パケットが失われると、より多くのデータが再送信されることになり、インターネット上の多くのルータは非常に長いパケットを配信できないためです:
net.ipv4.tcp_mtu_probing = 1
詳細については、https://blog.cloudflare.com/path-mtu-discovery-in-practice/ を参照してください。
TCP タイムスタンプ
タイムスタンプ生成を無効にすると、スパイクが減少し、ギガビットネットワークのパフォーマンスが向上する可能性があります:
net.ipv4.tcp_timestamps = 0
TCP Selective Acknowledgement
TCP Selective Acknowledgement (TCP SACK) は、受信側が損失セグメントに関するより詳細な情報を送信側に与えられるようにして、再転送の量を減らします。これはブーリアン値 tcp_sack
によって制御されます。これは高レイテンシなネットワークにおいて有用ですが、高速な LAN においてはこれを無効化することでスループットを増加させることができます。また、tcp_dsack
も無効化してください。SACK を送信しない場合、D-SACK を送信したくないでしょうから。Forward Acknowledgement は SACK の上で動作し、SACK が無効化されていると Forward Acknowledgement も無効化されます。[6]
net.ipv4.tcp_sack = 1
BBR を有効にする
BBR 輻輳制御アルゴリズムは、インターネットトラフィックのより高い帯域幅とより低いレイテンシを実現するのに役立ちます。まず、tcp_bbr
モジュールをロードしてください。
net.core.default_qdisc = cake net.ipv4.tcp_congestion_control = bbr
エフェメラルポートの範囲を拡大
エフェメラルポートは通常、Transmission Control Protocol (TCP) 、User Datagram Protocol (UDP) 、または Stream Control Transmission Protocol (SCTP) によって、クライアント/サーバ通信のクライアント側のポート割り当てとして使用されます。
net.ipv4.ip_local_port_range = 30000 65535
TCP/IP スタックの強化
IPv4 プロトコルのカーネルのネットワークセキュリティオプションを強化するためのパラメータセットと、同等のものが存在する関連する IPv6 パラメータを次に示します。
システムを ルーター として使用するなど、一部のユースケースでは、他のパラメータも有用な場合や必要な場合があります。
TCP SYN cookie 保護
SYN flood 攻撃からの保護に役立ちます net.ipv4.tcp_max_syn_backlog
に到達したときにだけ起動します。詳細については、 [7] を参照してください。linux 5.10 以降では、デフォルトで設定されています。
net.ipv 4.tcp_syncookies = 1
TCP rfc1337
tcp time-wait assassination hazard から保護し、time-wait 状態のソケットの RST パケットを破棄します。Linux 以外では広くサポートされていませんが、RFC に準拠しています。
net.ipv4.tcp_rfc1337 = 1
リバースパスフィルタリング
リバースパスフィルタリングを有効にすると、カーネルはマシン上のすべてのインタフェースから受信したパケットのソース検証を行います。これにより、IP スプーフィング方式を使用して被害を与える攻撃者から保護できます。
カーネルのデフォルト値は 0
(ソース検証なし) ですが、systemd は /usr/lib/sysctl.d/50 default.conf
を、net.ipv 4.conf.all.rp_filter
を 2
(loose mode) [9] に設定して出荷します。
次に、リバースパスフィルタリングメカニズムを value 1
(strict モード) に設定します。
net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.*
、net.ipv4.conf.interface.*
および net.ipv4.conf.all.*
については、 ip-sysctl.html を参照してください。
martian パケットをログに記録する
martian packet は、Internet Assigned Numbers Authority (IANA) による特殊な使用のために予約されている送信元アドレスまたは宛先アドレスを指定する IP パケットです。詳細は、Reserved IP addresses を参照してください。
しばしば martian とルーティング不可能なパケットが危険な目的のために使われるかもしれません。さらなる検査のためにこれらのパケットをログに記録することは有用かもしれません [10]
net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.all.log_martians = 1
ICMP リダイレクトを無効にする
背景は What are ICMP redirects? Should they be blocked? です。
ICMP リダイレクト受け入れをディセーブルにするには、次の手順を実行します。
net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0
ルータ以外で ICMP リダイレクト送信をディセーブルにするには、次の手順を実行します。
net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.send_redirects = 0
ICMP エコー要求を無視する
ICMP エコー (別名 ping) リクエストを無効にするには:
net.ipv4.icmp_echo_ignore_all = 1 net.ipv6.icmp.echo_ignore_all = 1
その他
特権を持たないユーザが IPPROTO_ICMP ソケットを作成できるようにする
IPPROTO_ICMP (icmp(7)) ソケットタイプを使用すると、raw(7) ソケット (CAP_NET_RAW ケイパビリティ または SUID ビットを適切な特権所有者で開く必要のある操作) を開くことなく、 ICMP_ECHO メッセージを送信し、対応する ICMP_ECHOREPLY メッセージを受信できるようになります。これらの ICMP_ECHO メッセージはアプリケーションによって送信されるため、IPPROTO_ICMP ソケットは ICMP エコーソケットとは別に ping ソケットとも呼ばれます。
ping_group_range
は、ユーザが IPPROTO_ICMP ソケットを作成できるグループの GID 範囲を決定します。さらに、 CAP_NET_RAW 機能の所有者も IPPROTO_ICMP ソケットを作成することができます。
デフォルトでは、この範囲は 1 0
で、root 以外の誰も IPPROTO_ICMP ソケットを作成できないことを意味します。
この設定を利用するには、現在 raw ソケットを使っているプログラムは、代わりに IPPROTO_ICMP ソケットを使うように移植する必要があります。 たとえば、QEMUはSLIRP (User-mode networking) に IPPROTO_ICMP を使用するため、QEMU を実行しているユーザーが IPPROTO_ICMP ソケットを作成できるようにすると、ゲストから ping を実行できるようになります。
GID 100 のグループのメンバーであるユーザーのみが IPPROTO_ICMP ソケットを作成できるようにするには、次のようにします。
net.ipv4.ping_group_range = 100 100
システム内のすべてのユーザーが IPPROTO_ICMP ソケットを作成できるようにするには、次のようにします。
net.ipv4.ping_group_range = 0 65535
仮想メモリ
Linux カーネルの virtual memory サブシステムの動作や、ディスクへのダーティデータの書き出しを調整するための重要なパラメータがいくつかあります。詳細については、公式の Linux kernel documentation を参照してください。例:
vm.dirty_ratio = 10
- 空きページと再利用可能ページを含む使用可能なメモリの合計に対する割合として、ディスク書き込みを生成するプロセスがダーティデータの書き込みを開始するページ数を含みます。
vm.dirty_background_ratio = 5
- バックグラウンドカーネルフラッシャのスレッドがダーティデータの書き込みを開始するページ数を、空きページと再利用可能ページを含む使用可能なメモリの合計に対する割合として含みます。
パラメータのコメントに記載されているように、これらの値を設定する場合は RAM の合計容量を考慮する必要があります。たとえば、使用可能なメモリの代わりに、インストールされているシステム RAM を使用すると簡単です。
- RAM の
vm.dirty_ratio
を 10% に設定することは、RAM が例えば 1GB (10%は 100 MB) の場合、妥当な値です。しかし、マシンの RAM がもっと大きい場合、たとえば 16GB (10%は 1.6 GB) になると、回転中のディスクに数秒の書き戻しが行われるため、割合が不釣り合いになることがあります。この場合、より妥当な値は3
です (16GB の 3% は約 491MB です) 。 - 同様に、
vm.dirty_background_ratio
を5
に設定することは、メモリ値が小さい場合は問題ありません、RAM 容量を考慮して調整してください。
VFS キャッシュ
virtual file system (VFS) キャッシュパラメータの値を小さくすると、システムの応答性が向上する場合があります。
vm.vfs_cache_pressure = 50
- ディレクトリや inode オブジェクトのキャッシュ (VFS キャッシュ) に使用されるメモリをカーネルがどれくらい回収するか制御する値です。デフォルト値の 100 から低くするとカーネルは VFS キャッシュをあまり回収しなくなります (0 に設定してはいけません。メモリ不足状態になる可能性があります)。
MDADM
カーネルがソフトウェア raid デバイスの resync を実行するときは、システムに高負担をかけないように速度を制限しています。sysctl を使って速度制限を上げたり下げたりすることが可能です。
# Set maximum and minimum speed of raid resyncing operations dev.raid.speed_limit_max = 10000 dev.raid.speed_limit_min = 1000
mdadm が md_mod
モジュールとしてコンパイルされている場合、上記の設定はモジュールがロードされた後にのみ使うことができます。/etc/sysctl.d
を使って起動時に設定をロードする場合、md_mod
モジュールは /etc/modules-load.d
で事前にロードすることができます。
トラブルシューティング
定期的にシステムがフリーズする
ダーティバイトを十分小さい値に設定 (例えば 4M):
vm.dirty_background_bytes = 4194304 vm.dirty_bytes = 4194304
参照
- sysctl(8) と sysctl.conf(5)
- /proc/sys/ の Linux カーネルドキュメント
- カーネルドキュメント: IP Sysctl
- sysctl のカーネルネットワークパラメータ
- sysctl-explorer.net – an initiative to facilitate the access of Linux' sysctl reference documentation
- Disable Source Routing - Red Hat Customer Portal
- SUSE handbook about Security Features in the Kernel