Xinetdは、インターネットからコンピューターへのアクセスを管理する保護者です。これは常に実行され、接続またはサービス要求をすべてのポートでリッスンするデーモンです。サーバーを実行しない場合、xinetdは必要ありません。ただし、ご使用のコンピューターが家庭用である場合でも、将来のある時点で他のユーザーがコンピューター上のサービスにアクセスできるようにする必要があります。するとき, xinetdをインストールして、悪意のある活動からコンピューターを保護する必要があります。.
オペレーティング・システム
xinetdユーティリティは、UnixおよびUnixライクシステム用に作成されました。したがって、LinuxおよびMac OSにインストールされますが、Windowsにはインストールされません。. このプログラムは無料で使用でき、GitHubからアクセスできます。.
このマスターリポジトリからプログラムを取得でき、コードのフォークも1つあります。これはよく知られた信頼性の高いプログラムであり、何度もダウンロードおよびインストールされているため、プログラムが悪意のある偽物である危険性を心配する必要はありません。.
xinetdの目的
xinetシステムは次のように機能することを目的としています サーバー. 通常のインターネット接続では、あるコンピューターが別のコンピューターに接続することをご存知でしょう。連絡を開始するコンピューターは、「クライアント」と連絡されたプログラムは「サーバ.接続の通常の理由は、クライアントがサーバーからサービスを取得できるようにするためです。ただし、連絡先のコンピューターでは、プログラムを実行して、要求を待機する必要があります。これはxinetdの機能です.
xinetdの基本的な要件は、要求を受信し、それを正しいアプリケーションに転送することです。これは、到着する接続またはサービス要求のヘッダーに書き込まれたポート番号で示されます。 xinetdプログラムは、実際には要求されたサービスを提供しませんが、ゲートキーパーとして機能します.
代替案:xinetd vs inetd
xinetdの開発者は、ネットワーク上で着信要求をリッスンするプログラムのアイデアを思いついた最初の人ではありませんでした。実際、xinetdは、このタスクを実行した元のプログラム(inetdと呼ばれる)を改良することを目的としています。.
「xinetd」という名前は、「拡張インターネットサービスデーモン」。 「インターネットサービスデーモン」は元の inetd. inetdを使用すると、xinetdが提供するのと同じサーバー要求監視を取得できます。ただし、このデーモンには防御メカニズムがないため、現在は安全ではないと見なされています.
古いinetdは単独では機能しませんでした。にリクエストを渡しました tcpd, 許可ファイルをチェックしました(hosts.allow そして hosts.deny)。名前が示すように、tcpdはTCP接続要求を処理します。ただし、UDPポートも検査するため、トランスポートレイヤーインターフェイスの実装です。また、TCPラッパーの言及が表示される場合があります。これはtcpdの単なる別の名前です。 tcpdを含めることにより、アクセス制御が改善されました。ただし、許可プロセスは手動で入力された2つのファイルによって行われたため、非常に包括的なセキュリティソリューションではありませんでした.
Xinetdの機能
xinetdの動作モードは、tcpdと組み合わせたinetdの動作に似ています。ただし、xinetdソリューションには、inetd / tcpdの組み合わせよりも優れたセキュリティ機能があります。デーモンの機能は次のとおりです。
- TCPおよびUDPのアクセス制御
- 接続の成功と失敗を記録するイベントロギング
- 時間セグメントに基づくアクセス制御
- 同時サーバー制限–サービス拒否(DoS)攻撃に対する防御
- ログファイルのサイズ制限
- 特定のサービスをプライベートネットワークに限定できるようにする、異なるインターフェイスへのサービスの割り当て
- ネットワークアドレス変換を含むプロキシ機能
Xinetdは、メディエーターとして動作することができます RPCサービス. ただし、この機能はあまり実装されていません。 RPCにセキュリティ機能がないため、そのサービスへのアクセスの需要が減ったため、xinetdの開発者がRPCインターフェイスの完成に時間を費やすことは疑わしい.
アクセス制御方法
inetd、xinetdのように リクエスタのIPアドレスに従って接続を許可またはブロックできます. inetdを使用すると、ホスト名またはドメイン名によって許可およびブロックされた接続ソースを識別することもできます。これらの各オプションには、検索手順が必要です。ホスト名オプションの場合、ネットワークのDNSシステムにこれらの名前を設定する必要があります。ドメインについては、おそらくパブリックDNSシステムに依存する方が良いでしょう。.
IPアドレス、ホスト名、またはドメイン名でリクエスターを識別するかどうかの選択はあなた次第です。しかしながら, IPアドレスに固執すると接続が速くなります ルックアップフェーズが不要になるため.
システム構成
xinetdを使用するには、まずインストールしてから、 構成ファイルを更新する. 基本的に、構成ファイルはxinetdのコマンドセンターです。このプログラムはデーモンなので、一度起動すると, それは永遠に実行され続けます. コマンドラインで調整できるインタラクティブなユーティリティではありません。プログラムとのすべての通信は、構成ファイルを介して行われます.
デーモンは、外部から要求を受信するたびに構成ファイルのチェックを継続します。起動時に構成をメモリにロードしません。つまり 実行中にデーモンのパフォーマンスを調整できます 構成ファイルに保持されている指示を変更することにより.
xinetの構成ファイルは、他のユーティリティの構成システムよりもはるかに重要です。これは、xinetdプログラムを停止して再起動する必要なく、構成を介してデーモンの指示を変更できるためです。.
構成ファイルのセットアップ
ファイルを探す /etc/xinetd.conf. これはプログラムのメイン構成ファイルであり、アプリケーションが読み込む接続を許可し、呼び出すサービスを決定するためにアプリケーションが読み取るルックアップテーブルとして機能します。.
既存のxinetd.confファイルを作成できます inetd.conf とファイル xconv.pl xinetdのGitHubリポジトリからダウンロードできるパッケージの一部を形成するプログラム。次のコマンドで変換プログラムを実行します。
/usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf
新しい構成ファイルは完全ではなく、xinetdを起動する前にさらに変更する必要があります。.
構成ファイルのデフォルトセクション
新しく生成されたxinetd.confファイルを見るとき、2つの重要な構成セクションに焦点を合わせる必要があります。これらの最初は デフォルト セクションと2番目は サービス セクション.
おそらく既に推測されているように、defaultsセクションはxinetdに、servicesセクションで現在のタスクに関する特定の指示が見つからない場合の対処方法を指示します.
デフォルトセクションで設定できる主なオプションは次のとおりです。
- only_from
- アクセスなし
- log_type
- log_on_success
- log_on_failure
- インスタンス
- per_source
次のセクションでは、これらのオプションについて詳しく説明します.
アクセス条件
Only_from そして アクセスなし 特定のアドレスまたはアドレス範囲をブロック(アクセスなし)または許可(only_from)するという同じタスクを効果的に実行します。これらのオプションのいずれかを使用して、デフォルトですべてをブロックし、構成ファイルの下位にあるサービスのリストを作成することをお勧めします。この戦略により、あなたが説明しなかったイベントが発生した場合、あなたは自分自身をカバーします.
これらの2つのオプションは、servicesセクションに含める有効なコマンドでもあります。だからあなたはできる デフォルトですべての禁止を開始してから、サービスを追加します. xinetdが受信する接続要求タイプに関連するサービスセクションがある場合、設定のデフォルトセクションは表示されません。.
サービスの説明にあるonly_fromおよびno_accessの指示は、defaultsセクションのonly_fromおよびno_accessステートメントをオーバーライドします。.
これら2つのオプションの形式は
=
アドレスは、IPアドレス、ホスト名、またはドメイン名として表現できることに注意してください。ただし、IPアドレスに固執することをお勧めします。 CIDR表記を使用して範囲を指定できます。これらのオプションの使用方法の2つの例を次に示します。
no_access = 0.0.0.0/0
これは、すべてのユーザーをブロックするため、おそらくデフォルトセクションの最も一般的な行です。デフォルトセクションは設定ファイル内にのみあり、サービスセクションでカバーされていないサービスリクエストが発生した場合にxinetdに何をすべきかを伝えます。コンピューターが提供できるすべてのサービスの種類について特定の指示を提供できるという前提で作業する必要があります。したがって、他のすべての要求がブロックされていると述べるのが妥当です。専属VIPパーティーのドアマンは、「リストに載っていないなら、入場していない」と言うでしょう。
この戦略に代わる方法は、全員を参加させることです。これは次の方法で実装します。
only_from = 0.0.0.0/0
このポリシーは、デフォルトセクションではあまり意味がありません。デフォルトセクションは、サービスの指示を入力していない場合にのみ参照されるため、xinetdがデフォルトに頼ると、指示が提供されていないケースがあります。そのため、そのような状況でアクセスを許可すると、xinetdにリクエストの処理方法を指定していないため、エラーが発生します。サービスの説明内でこのcatch-all only_fromオプションを使用することは論理的であるため、このメッセージは、すべての可能なソースからのリクエストがそのサービスを使用できるようにxinetdに指示します.
残念ながら、上記のポリシーを実装した場合に競合が発生するonly_fromおよびno_accessオプションの機能があります。あれは, no_accessとonly_fromの両方がグローバルです xinetdは、実行するタスクがあるたびに両方をチェックします。したがって、両方を設定している場合、デーモンは、有効なサービス構成が設定されていても、defaultsセクションのno_accessステートメントに対して着信要求を検証します.
グローバルなno_accessとonly_fromのこの癖は、次のポリシーを決定することで克服できます。 xinetd.confファイルでどちらか一方のみを使用する. only_fromに固執し、no_accessオプションを無視するのが一般的な方法です。デフォルトセクションのアドレスリストを空白のままにすると、キャッチオールのみの命令を作成できます。つまり、only_from = これにより、xinetdプログラムはサービスの説明でonly_from設定を使用できるようになります。これは、デフォルトセクションのonly_from値がサービスのonly_from設定によって上書きされるため、競合を引き起こすことなく発生します。.
うるさい, defaultsセクションにonly_fromまたはno_accessステートメントを配置しない場合、xinetdはすべての接続を許可します あなたがサービスセクションでカバーしていないこと、それはおそらくエラーを作成します.
これらのオプションの両方のパラメーターとして複数のアドレスをリストする形式は、各アドレスの間にスペースを残します(コンマなし)。リストにCIDR範囲を含めることもできます.
ログファイルコマンド
の log_type, log_on_success, そして log_on_failure オプションはすべて一緒に機能します。それぞれにパラメーターとしてオプションに入力する必要がある一連の定数があります.
log_type属性を使用して ログファイルのパスと名前を与える また、log_on_successおよびlog_on_failure属性を使用して、各イベントのログファイルレコードに書き込むフィールドを指定します。.
たとえば、次のようにログファイルアドレスを書き込みます。
log_type = FILE / usr / log / internetlog
log_type属性で使用できる別のオプションはSYSLOGで、syslogdによって報告されるこれらのイベントのメッセージレベルを設定します。可能な値は次のとおりです。
- デーモン
- auth
- ユーザー
- local0-7
例は次のとおりです。
log_type = SYSLOG local1
の SYLOG 属性は必須ではなく、それは ファイル オプション。 xinetdに書き込むログファイルの名前を本当に指定する必要があります。イベントメッセージのSyslogレベルを指定する必要はありません。.
log_on_successで利用可能なレポートオプションは次のとおりです。
- PID –内部xinetdサービスの場合は0
- HOST –クライアントのアドレス
- USERID –リモートユーザーのID
- EXIT –プロセスの終了ステータス
- DURATION –セッション期間
log_on_failureのレポートオプションは次のとおりです。
- HOST –クライアントのアドレス
- USERID –リモートユーザーのID
- 試行–失敗したアクセス試行をログに記録します
- RECORD –クライアントに関するすべての利用可能な情報
各log_on_successおよびlog_on_failure行に複数のオプションを含めることができます。これらのオプションは、句読点のないスペースで区切る必要があります。例えば:
log_type = FILE / usr / log / internetlog
log_on_success =ホストPID USERID DURATION EXIT
log_on_failure =ホストUSERID試行記録
ファイル内の連続する行でlog_type、log_in_success、およびlog_on_failureステートメントを保持するのが一般的な方法です.
容量制御
xinetd.confに追加する必要がある2つのオプションは、サーバーが受け入れる同時接続の数を制限します。これは重要な要素であり、サービス拒否(DoS)攻撃を打破するためのシンプルだが強力な方法です。この戦略を実装する2つのオプションは次のとおりです。 インスタンス そして per_source.
デフォルトセクションのインスタンスオプションは、xinetdが同時に実行できる接続の数を指定し、per_sourceオプションは、デーモンが同じソースアドレスから応答する接続要求の数を指定します. 分散型サービス拒否攻撃 (DDoS)はper_source制限を回避しますが、instancesオプションは回避しません。残念ながら、このサービス制限の実装により、攻撃の間、正規のユーザーがブロックされます.
これら2つのオプションの形式は非常に単純です。
=数.
per_source値は、インスタンス値よりも低くする必要があります.
デフォルトセクションの例
このセクションで説明した詳細をすべてまとめると、xinetd.confのデフォルトステートメントは次のようになります。
デフォルト
{
インスタンス= 20
per_source = 5
log_type = FILE / usr / log / internetlog
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure =ホストUSERID試行記録
only_from =
}
各xinetd.confファイルにはdefaultsステートメントが必要です。サービスに関する声明は必要ありません.
サービス構成セクション
サーバーに配信するサービスごとに、xinetd.confにサービス指示セクションを作成する必要があります。設定ファイルにサービスを記述しない場合、xinetdはデフォルトセクションに記載されている仕様を使用します。また、サービスを定義するために書かれたセクションで異なる値でそれらの属性を再定義することにより、デフォルトセクションで定義された設定を上書きすることができます.
サービスの種類
サービスセクションで使用できる属性は、3つのサービスカテゴリごとに異なります。これらは:
- 内部
- 限定公開
- RPC
サービスのカテゴリ(INTERNAL / UNLISTED / RPC)は、属性で指定できます タイプ. ただし、この属性は必須ではなく、しばしば省略されます.
サービス属性の定義
属性仕様を記述する場合、すべてのフィールドはスペースまたはキャリッジリターンで区切られます–定義に区切り文字や句読点を使用しないでください.
サービスステートメントのレイアウトは、デフォルトセクションの場合と同じです。
サービス
{
属性演算子の値
}
通常、属性ステートメントに使用される演算子は等しい(“=「)。既存のリストに値を追加できる属性はほとんどなく、「+=」または「でリストから削除」-=」–どちらの場合も、ここに示す引用符なしで演算子を記述します.
以下に利用可能な属性があります 内部 サービスの種類:
- socket_type
- 旗
- いいね
- 待つ
- プロトコル(/ etc / servicesにリストされていない場合)
- ポート(/ etc / servicesにリストされていない場合)
- cps
- access_times
に使用できる属性 RPC サービスは次のとおりです。
- socket_type
- 旗
- ユーザー
- サーバ
- server_args
- いいね
- 待つ
- プロトコル
- rpc_version
- rpc_number
- cps
- access_times
の 限定公開 サービスタイプには、次の属性のいずれかを指定できます。
- socket_type
- 旗
- ユーザー
- サーバ
- server_args
- 最大荷重
- いいね
- 待つ
- プロトコル(/ etc / servicesにリストされていない場合)
- ポート(/ etc / servicesにリストされていない場合)
- access_times
- cps
サービス属性の目的
これらの属性の意味を次の表に示します。
タイプ | 内部、RPC、非公開、または内部非公開 |
socket_type | ストリーム(TCP)、dgram(UDP)、raw(IP直接アクセス)、またはseqpacket(). |
id | このサービスの一意の名前を作成します |
旗 | 以下の表で説明 |
ユーザー | サーバーの優先順位を指定します |
サーバ | サービスのパスとプログラム |
サーバー引数 | サービスコールで渡す引数 |
最大荷重 | サービスの同時プロセスの数 |
いいね | サービスの優先度を上げます |
待つ | はい| no-新しいリクエストの同時処理をブロックまたは許可します |
プロトコル | プロトコルが/ etc / protocolsにリストされている場合は省略できます |
港 | ポート番号は/ etc / servicesにも存在し、同じ番号でなければなりません |
rpc_version | RPCのバージョン |
rpc_number | RPC番号 |
cps | 接続制限、2番目の引数はオプションであり、制限に達したときに待機する秒数を指定します |
access_times | サービスを実行できる時間 |
練る | 特定のIPアドレスへの接続に応答する |
リダイレクト | サービスの要求を別のコンピューターに転送します |
の 旗 属性には次の値を設定できます。
ただ:識別サーバーを持つクライアントからの接続のみを受け入れます
ノリトリー:接続障害時に新しいプロセスの作成を防ぎます
NAMEINARGS:の最初の引数 server_args それは サーバ 値。 tcpdを呼び出すときに使用
上記の属性に加えて、デフォルトセクションで使用可能なオプションをサービスの定義に書き込むこともできます。これらは:
- only_from
- アクセスなし
- log_type
- log_on_success
- log_on_failure
- インスタンス
- per_source
これらの属性を再度使用すると、デフォルトセクションで設定されたすべての値が上書きされます。ただし、 only_from そして アクセスなし 属性はグローバルなので、これらのオプションの使用を整理して、パラメーターの競合を回避する必要があります.
サービス宣言の例
以下は、サービスの定義の2つの例です。.
サービスntalk
{
socket_type = dgram
待つ=はい
ユーザー= nobody
サーバー= /usr/sbin/in.ntalkd
access_times = 7:00-12:30 13:30-21:00
only_from = 192.168.1.0/24
}
サービスFTP
{
socket_type =ストリーム
wait no =いいえ
ユーザー= root
サーバー= /usr/sbin/in.ftpd
server_args = -l
インスタンス= 4
いい= 10
}
の使用法に注意してください access_times の中に ntalk 定義。これは、開始時間と終了時間をスペースなしのダッシュ(「–」)で区切った2つの時間範囲を使用します。 2つの時間範囲はスペースで区切られます。時間定義では24時間形式を使用します.
の only_from の属性 ntalk 定義により、このサービスへのアクセスが制限されるため、ローカルネットワーク上のアドレスのみがこのサービスを使用できます。.
の ntalk サービスには socket_type の dgram, これは、UDPサービスであることを意味します。の socket_type の中に ftp 定義は ストリーム, これは、これがTCPサービスであることを意味します.
サービスの複数のインスタンスを作成する
サービス定義では、デフォルトでサービス名を識別子として使用します。ただし、サービスのコピーを複数作成して、それぞれ異なる属性を付与することもできます。サービス名は、で使用される名前と一致する必要があるため / etc / services ファイルの場合、実行中のサービスのいくつかのバージョンを取得することは不可能です。ただし、id属性はこの操作戦略を有効にします.
このシナリオの非常に一般的な使用法の1つは、作成する場合です。 内部および外部アクセス用の異なるFTPサーバー. この方法により、オフィスのファイルストレージを、一般に公開するダウンロード可能なファイルとは完全に分離しておくことができます。.
この使用例では、「Service ftp」を2回定義します。次に、1つのインスタンスに属性を与えます id = ftp-internal そして他の id = ftp-external. それ以降、xinetdは2つを区別できます。各インスタンスをさまざまな対象者が利用できるようにするには、 only_from ftp-internalサービスへのアクセスをネットワーク上のアドレスのみに制限し、ftp-externalサービスへのアクセスをすべての非ネットワークアドレスに制限する属性.
アドレスをサービスにバインドする
内部ユーザーと外部ユーザーに異なるサービスを作成するシナリオは、バインド属性によって大いに役立ちます。用語 “練る」は、TCPプログラミングで頻繁に使用されます。通常、接続をポートに関連付け、セッションのIDを作成することを意味します。ただし、この場合、「バインド」とは何か異なることを意味します。 FTPサーバーへの内部および外部アクセスの例, コンピューターのネットワークアドレスをftp-internalインスタンスにバインドし、そのコンピューターのパブリックIPアドレスをftp-externalインスタンスにバインドできます。.
この例では、サービスの定義でonly_from属性を省略することができます。ただし、これらの制限を残す方が安全です。したがって、内部および外部FTPサーバーの完全な定義は次のようになります。
サービスFTP
{
id = ftp-external
サーバー= /usr/sbin/in.ftpd
server_args = -l
インスタンス= 4
only_from = 0.0.0.0/0
バインド= 202.19.244.130
}
サービスFTP
{
id = ftp-internal
socket_type =ストリーム
サーバー= /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24
バインド= 192.168.1.5
}
この戦略では、FTPサーバーにパブリックアクセス用に割り当てられた静的IPアドレスが必要です。また、内部FTPサーバーに同じアドレスを予約するようにDHCPサーバーをセットアップする必要があります。上記のシナリオは、内部アクセスと外部アクセスの両方に単一のコンピューターを使用する場合に機能しますが、FTPインスタンスごとに別々のコンピューターのアドレスを割り当てることもできます.
inetd固有のサービスを無効にします
がある 3つのxinetdサービス システムに関する情報を提供します.
- サーバー:使用中のサーバーに関するレポート
- サービス:利用可能なサービス、プロトコル、およびポートに関するレポート
- xadmin:上記の2つのコマンドを組み合わせます
これらのサービスはセキュリティ上の弱点です ハッカーがネットワークやサーバーに関する情報を取得するために使用できるためです。したがって、それらを無効にすることをお勧めします。 disabled属性を使用してこれを行うことができます。これは、 デフォルト 定義。これらの機能を削除するには、デフォルトセクションに次の行を追加します。
無効=サーバーサービスxadmin
上記の構成ファイルの変更により、xinetdの使用を開始できます.
xinetdの実行
コマンドラインでxinetdを起動します。このコマンドはバッチファイルからも実行できるため、コンピューターの起動手順に追加できます。プログラムは、次のオプションで実行できます。
-d | デバッグモード | |
-syslog | syslog_facility | confファイルのデフォルトのlog_type SYSLOGと同じ |
-ファイルログ | ログファイル | confファイルのデフォルトのlog_type FILEと同じ |
-f | config_file | 構成ファイルを指定します-デフォルトは/etc/xinetd.confです |
-pidfile | pid_file | プロセスIDをpid_fileに書き込みます |
-生き残る | 終了しない | |
-限定 | proc_limit | 同時に実行できるプロセスの最大数 |
-logprocs | 限定 | 同時に実行できるサーバーの最大数 |
-バージョン | xinetdバージョンを印刷する | |
-inetd_compat | /etc/inetd.confおよびxinetd構成ファイルを読み取ります。 | |
-cc | 間隔 | interval秒ごとに一貫性チェックを実行する |
オプションなしでxinetdを起動することも可能です.
xinetdを使用する
Linuxコンピューターを使用している場合は、xinetdが既にインストールされている可能性があります。実行して確認できます xinetd-バージョン. 代わりにコンピューターがinetdを実行している場合、Linuxを実行していない可能性があります。プログラムをxinetdに置き換え、上記で説明したように構成ファイルをinetd互換からxinetdの使用に変換します.
現在、xinetdを使用していますか?にメッセージを残す コメント 以下のセクションであなたの経験をコミュニティと共有してください.
こちらもご覧ください: 15の無料Syslogサーバー
画像:Pixabayのネットワークインターネット接続。 CC0クリエイティブコモンズの下でライセンス
Xinetdは、インターネットからコンピューターへのアクセスを管理する保護者であり、常に実行され、接続またはサービス要求をすべてのポートでリッスンするデーモンです。このプログラムはUnixおよびUnixライクシステム用に作成され、LinuxおよびMac OSにインストールされますが、Windowsにはインストールされません。xinetdの目的は、要求を受信し、それを正しいアプリケーションに転送することであり、到着する接続またはサービス要求のヘッダーに書き込まれたポート番号で示されます。xinetdプログラムは、実際には要求されたサービスを提供しませんが、ゲートキーパーとして機能します。xinetdの機能には、TCPおよびUDPのアクセス制御、接続の成功と失敗を記録するイベントロギング、時間セグメントに基づくアクセス制御、同時サーバー制限、ログファイルのサイズ制限、特定のサービスをプライベートネットワークに限定できるようにする、異なるインターフェイスへのサービスの割り当て、ネットワークアドレス変換を含むプロキシ機能があります。xinetdを使用するには、まずインストールしてから、構成ファイルを更新する必要があります。デーモンは、外部から要求を受信するたびに構成ファイルのチェックを継続します。xinet