一部のユーザーに管理アクセスを許可し、ユーザーがシステムで何をするかを制御および確認する場合は、sudoを使用します。 。ただし、sudoを使用しても 、目に見えない問題がかなりあります。シェルアクセスを提供することを考えてみてください。最近のsudo これらの問題を確認し、さらには制御できる機能が追加されました。たとえば、より詳細で処理しやすいログメッセージをオンにして、シェルセッションで実行された各コマンドをログに記録できます。
これらの機能のいくつかは真新しいです。それらのいくつかは、バージョン1.9.0またはそれ以前で導入された機能に基づいています。たとえば、sudo バージョン1.8でも、端末で発生したすべてを記録できます。ただし、システムはこれらの記録をローカルに保存しており、特に記録が最も有用なシェルセッションでは簡単に削除できました。バージョン1.9.0では中央セッションの記録コレクションが追加されたため、ローカルユーザーは記録を削除できません。最近のバージョンではリレーが追加され、コレクションがさらに堅牢になりました。
sudoの基本だけを知っている場合 または、以前はバージョン1.8のみを使用していたので、以前の記事を読むことをお勧めします。
1。 JSON形式のロギング
私が紹介したい最初の新機能は、JSON形式のロギングです。私はロギングマニアです（syslog-ngの作業を開始しました プロジェクトは12年前）であり、この機能は私のOpensource.comの記事以来最初に導入されたものです。有効にすると、sudo より多くの情報をログに記録し、より簡単な方法で解析します。
従来のsyslog sudoによるメッセージ 短く、必要な情報が最小限しか含まれていません。これは、古いsyslog による制約によるものです。 実装：1kサイズを超えるメッセージは破棄または切り捨てられました：
Jan 28 13:56:27 localhost.localdomain sudo[10419]: czanik : TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
最近のsyslog 実装は、はるかに大きなメッセージサイズを処理できます。 syslog-ng デフォルトで最大64kのサイズのログメッセージを受け入れます（ただし、もちろん、実際の構成に応じて、これより小さくしたり大きくしたりできます）。
JSON形式でログインした場合、同じイベントにはさらに多くの情報が含まれます。処理が多いということは、処理が難しいという意味ではありません。JSON形式のメッセージは、多くのログ管理ソフトウェアアプリケーションで解析しやすくなっています。次に例を示します：
Jan 28 13:58:20 localhost.localdomain sudo[10518]: @cee:{"sudo":{"accept":{"uuid":"616bc9efcf-b239-469d-60ee-deb5af8ce6","server_time":{"seconds":1643374700,"nanoseconds":222446715,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submit_time":{"seconds":1643374700,"nanoseconds":209935349,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submituser":"czanik","command":"/bin/bash","runuser":"root","runcwd":"/home/czanik","ttyname":"/dev/pts/0","submithost":"localhost.localdomain","submitcwd":"/home/czanik","runuid":0,"columns":118,"lines":60,"runargv":["/bin/bash"],"runenv":["LANG=en_US.UTF-8","HOSTNAME=localhost.localdomain","SHELL=/bin/bash","TERM=xterm-256color","PATH=/home/czanik/.local/bin:/home/czanik/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin","MAIL=/var/mail/root","LOGNAME=root","USER=root","HOME=/root","SUDO_COMMAND=/bin/bash","SUDO_USER=czanik","SUDO_UID=1000","SUDO_GID=1000"]}}}
sudoersでJSON形式のログメッセージを有効にできます ファイル：
Defaults log_format=json
sudoから、JSON形式のログメッセージを操作する方法について詳しく知ることができます。 私のsyslog-ngブログから。
2。 sudo_logsrvdを使用してログを一元的に収集する
1.9.4のもう1つのロギング関連機能は、すべてのsudoを収集することです。 sudo_logsrvdを使用してメッセージ（失敗を含む）をログに記録する 。以前は、システムはsudo_logsrvdの場合にのみ成功したセッションをログに記録していました 実際に録音しました。ロギングは引き続きsyslog を介して行われます 最後にデフォルトで。
何でこれが大切ですか？まず、sudoに関連するものをすべて収集できます 1か所：セッションの記録と対応するすべてのログメッセージの両方。次に、すべてのsudoの適切なロギングを保証することもできます sudoなどの関連イベント sudo_logsrvdの場合、コマンドの実行を拒否できます アクセスできません。
sudo_logsrvdへのロギングを有効にできます sudoersで次の設定を使用します ファイル（もちろん、IPアドレスを置き換えます）：
Defaults log_servers=172.16.167.150
JSON形式のログメッセージが必要な場合は、[eventlog]で次の設定が必要です。 sudo_logsrvdのセクション 構成：
log_format = json
それ以外の場合は、sudo_logsrvd 従来のsudoを使用します 簡単な変更を加えたログ形式：ログの送信元のホストに関する情報も含まれています：
Nov 18 12:40:16 centos8splunk.localdomain sudo[21028]: czanik : 3 incorrect password attempts ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Nov 18 12:40:23 centos8splunk.localdomain sudo[21028]: czanik : HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; TSID=00000A ; COMMAND=/bin/bash
Nov 18 12:40:30 centos8splunk.localdomain sudo[21028]: czanik : command rejected by I/O plugin ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
システム管理者の詳細
- Sysadminブログを有効にする
- 自動化されたエンタープライズ：自動化によってITを管理するためのガイド
- eBook：システム管理者向けのAnsible自動化
- 現場からの物語：IT自動化に関するシステム管理者ガイド
- eBook：SREおよびシステム管理者向けのKubernetesのガイド
- 最新のシステム管理者の記事
3。リレー
彼らが最初にsudo_logsrvdを導入したとき （バージョン1.9.0）中央セッションの記録収集の場合、クライアントは記録を直接送信することしかできませんでした。バージョン1.9.7では、リレーの概念が導入されました。リレーを使用すると、録音を直接送信する代わりに、ネットワークを構成する複数レベルの中間ホストに録音を送信できます。
何でこれが大切ですか？まず、リレーを使用すると、ネットワークの問題やメンテナンスのために中央ホストが使用できない場合でも、セッションの記録を収集できます。デフォルトでは、sudo 録音を送信できない場合は実行を拒否するため、リレーはsudoを使用できるようにすることができます 24時間。
次に、ネットワークをより厳密に制御することもできます。すべてのホストのファイアウォールを中央のsudo_logsrvdに開く代わりに 、リレーを許可するだけで済みます。
最後に、sudo_logsrvdをインストールできるAWSプライベートネットワークなど、インターネットに直接アクセスしないネットワークからセッションの記録を収集できます。 ゲートウェイホストのリレーモード。
リレーを使用する場合は、sudoを構成します クライアントと中央のsudo_logsrvd 同じまま。リレーホストで、次の行を[relay]に追加します sudo_logsrvd.confのセクション ：
relay_host = 172.16.167.161中央サーバーへのネットワーク接続に問題があることがわかっている場合は、記録を転送する前に記録を保存するようにリレーを構成できます。
store_first = true4。ロギングサブコマンド
sudoを介して開始されたシェルセッション内で何が発生するかを知りたいと思ったことはありませんか ？はい、セッションの記録はありますが、実行されたいくつかのコマンドを確認するためだけに何時間もの記録を見るのは退屈で、時間の無駄です。幸い、バージョン1.9.8ではロギングサブコマンドが導入されました。これで、ログメッセージを定期的にチェックし、疑わしいことが発生した場合にのみ記録を確認するだけで十分です。
シェルアクセスにシェルアクセスを許可するルールは必要ありません。エディターにアクセスするだけです。ほとんどのエディターは外部コマンドを実行できます。私のお気に入りのエディターはJOEです。これは、sudoから開始したときに表示されるものです。 ：
Aug 30 13:03:00 czplaptop sudo[10150]: czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe興味深いことは何もありません。シェルを生成し、そのシェルからいくつかのファイルとパーティションを削除したとしても、エディターだけです。次に、ロギングサブコマンドを有効にするとどうなるか見てみましょう。
Aug 30 13:13:14 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/sh -c /bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/readlink /proc/10889/exe
[...]
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/sed -r s@/*:|([^\\]):@\1\n@g;H;x;s@/\n@\n@
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/tty
Aug 30 13:13:42 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/id
Aug 30 13:13:56 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/ls -A -N --color=none -T 0 /usr/share/syslog-ng/include/scl/
スペースを節約するために数十行を省略しましたが、シェルを開始し、コマンドがbash_profileによって実行されたことがわかります。 ログでも利用できます。
sudoersでロギングサブコマンドを有効にできます 次の設定を使用してファイルを作成します：
Defaults log_subcmds
従来のsudo ログ、sudoから確認できます これらのログがまったく同じsudoからのものであるプロセスID セッション。前に示したように、JSON形式のロギングをオンにすると、sudo より多くの情報をログに記録し、分析を容易にします。
5。サブコマンドの傍受
サブコマンドをログに記録すると、sudoからほとんどの隠れた問題領域が削除されます 、しかし、何が起こっているのかを監視するだけでなく、イベントの流れを制御したい場合もあります。たとえば、ユーザーにシェルアクセスを許可する必要がありますが、それでもユーザーが特定のコマンドを実行できないようにする必要があります。このような場合、傍受が理想的です。もちろん、シェルの組み込みコマンドを制限できないなど、いくつかの制限があります。
whoとしましょう コマンドは危険です。傍受は2つのステップで有効にできます。1つ目は有効にし、2つ目は構成します。この場合、私のユーザーはwhoを実行できません。 ：
Defaults intercept
czanik ALL = (ALL) ALL, !/usr/bin/who
sudoを介してルートシェルセッションを開始するとどうなりますか。 whoを実行してみてください ：
$ sudo -s
# who
Sorry, user czanik is not allowed to execute '/usr/bin/who' as root on czplaptop.
bash: /usr/bin/who: Permission denied
実行中のシェルを簡単に完全に無効にすることができます：
Defaults intercept
Cmnd_Alias SHELLS=/usr/bin/bash, /usr/bin/sh, /usr/bin/csh
czanik ALL = (ALL) ALL, !SHELLS
ただし、sudoを介してシェルセッションを開始できないことも意味します 。それだけでなく、エディタから外部コマンドを実行することもできません。これは、lsを起動しようとするとどうなるかです。 vi内からのコマンド ：
$ sudo vi /etc/issue
Sorry, user czanik is not allowed to execute '/bin/bash -c /bin/ls' as root on czplaptop.
Cannot execute shell /bin/bash
Press ENTER or type command to continue
次は何ですか？
私の記事を読んで、これらの新機能を自分で試してみたいと思うようになることを願っています。最新のsudoをインストールできます パッケージマネージャーからの多くのLinuxディストリビューションおよびUNIXバリアントで、またはSudoWebサイトで入手可能なバイナリインストーラーを使用します。
この記事では、新しい可能性の概要を説明します。これらの機能の詳細については、マニュアルページをホストしているWebサイト、およびSudoブログにアクセスしてください。