Centosには、クラウンで毎日実行され、/ var / logの内容を分析し、要約レポートを作成して電子メールで送信する標準のLogwatchログアナライザーがあります。 ある晴れた日、このレポートで記録を見つけました。
--------------------- yum Begin ------------------------
インストールされたパッケージ：
lzo2-2.02-3.el5.rf.i386
dnstracer-1.8-1.2.el5.rf.i386
openvpn-2.0.9-1.el5.rf.i386
---------------------- yum End -------------------------
その瞬間、彼女は非常に恥ずかしかった。前日に私はサーバーにログインせず、さらに何もインストールしなかったからだ。 最初に思いついたのは、サーバーが侵害されたことです。 自分は自信のあるLinuxユーザーだと思っていましたが、混乱していました。 幸いなことに、その瞬間、icqは私の元同僚であり、私が知っている最高のシステム管理者であり、非常に優秀な人物でした。
彼はシステムを素早くチェックするのを助けました。 その結果、ハッキングのためにサーバーをすばやくチェックする方法に関する短いHowToを作成しました。 私はそれが多くの勇敢な読者に役立つと確信しています。 ユーザーがLinux / Unixコンソールに精通していることを前提としています。
そのため、まず、ルートパスワードを変更します。
[root @ myhostなど]＃passwd ユーザーrootのパスワードを変更します。 新しいUNIXパスワード： ...
次に、ホストをスキャンして、疑わしいオープンポートを探します。 たとえば、nmapユーティリティを使用して別のUnixマシンからこれを行うことができます。
[root @ myhost〜]＃nmap -P0 123.123.123.123 2011-01-23 11:47 MSKにNmap 4.11（http://www.insecure.org/nmap/）を開始 myhost.myprovider.net（123.123.123.123）の興味深いポート： 表示されていません：1679個のフィルタリングされたポート ポートステートサービス 21 / tcp open ftp 22 / tcp open ssh 25 / TCPオープンSMTP 53 / tcpオープンドメイン 80 / TCPオープンHTTP 106 / tcp open pop3pw 110 / TCPオープンpop3 111 / tcp open rpcbind 135 / tcpフィルタリングmsrpc 136 / tcpフィルタープロファイル 137 / TCPフィルター処理されたnetbios-ns 138 / tcpフィルター処理されたnetbios-dgm 139 / TCPフィルター処理されたnetbios-ssn 143 / TCPオープンimap 443 / TCPオープンhttps 445 / tcpフィルター済みmicrosoft-ds 465 / TCPオープンSMTP 620 / tcp open unknown 993 / TCPオープンimap 995 / tcp open pop3s 3306 / TCPオープンmysql 8443 / TCPオープンhttps-alt
111と620のポートはこのリストで疑わしく見えたため、誰がそれらを聞いているかをさらに調べます。
[root @ myhost〜]＃netstat -anp | grep LISTEN | grep 620 tcp 0 0 0.0.0.0:620 0.0.0.0:* LISTEN 1710 / rpc.statd
[root @ myhost〜]＃netstat -anp | grep LISTEN | grep 111 tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1685 / portmap
これらはnfsコンポーネントであるため、すべてが正常であることが判明しました。 次に、UDP接続を確認します。
[root @ myhost〜]＃netstat –anp | grep udp udp 0 0 0.0.0.0:32773 0.0.0.0:* 2345 /名前付き udp 0 0 127.0.0.1:32780 127.0.0.1:32780 ESTABLISHED 2539 / postmaster udp 0 0 0.0.0.0:32783 0.0.0.0:* 2790 / avahi-daemon： udp 0 0 123.123.123.123:53 0.0.0.0:* 2345 /名前付き udp 0 0 123.123.123.123:53 0.0.0.0:* 2345 /名前付き udp 0 0 127.0.0.1:53 0.0.0.0:* 2345 /名前付き udp 0 0 0.0.0.0:614 0.0.0.0:* 1710 / rpc.statd udp 0 0 0.0.0.0/10353 0.0.0.0:* 2790 / avahi-daemon： udp 0 0 0.0.0.0:617 0.0.0.0:* 1710 / rpc.statd udp 0 0 0.0.0.0:111 0.0.0.0:* 1685 / portmap udp 0 0 0.0.0.0:631 0.0.0.0:* 2069 / cupsd udp 0 0 ::: 32774 ::: * 2345 /名前付き udp 0 0 ::: 32784 ::: * 2790 / avahi-daemon： udp 0 0 ::: 5353 ::: * 2790 / avahi-daemon：
ここでも、すべてが正常であることが判明しました。 最も可能性が高いのは、Centosサーバーにログインするときに、最後のログインが私のIPからであると書いたため、コンソールからサーバーにアクセスできなかったことです。 したがって、/ root / .sshフォルダーを確認する必要がある次の項目は、何らかの方法でそこにsshクライアントのキーを置くことができます。
[root @ myhost〜]＃dir /root/.ssh authorized_keys_
キーファイルのみがここにあることがわかりました。プロバイダーがホストを転送した直後に名前を変更しました。 次に、/ etc / passwdファイルを確認します。 rootを除き、uid = 0のユーザーを含めることはできません。
[root @ myhost〜]＃cat / etc / passwd | もっと ルート：x：0：0：ルート：/ルート：/ bin / bash bin：x：1：1：bin：/ bin：/ sbin / nologin デーモン：x：2：2：デーモン：/ sbin：/ sbin / nologin adm：x：3：4：adm：/ var / adm：/ sbin / nologin lp：x：4：7：lp：/ var / spool / lpd：/ sbin / nologin 同期：x：5：0：同期：/ sbin：/ bin / sync ...
そして、ここでも、すべてが大丈夫でした。 最後のコードは、インストールされているルートキットについてホストをチェックすることでした。 これには無料のrkhunterユーティリティを使用できます。 最新バージョンのアーカイブをダウンロードし、解凍してインストーラーを実行します。 次に、更新してチェックを実行します。
[root @ myhost〜]＃./installer.sh --install --layout / usr / local [root @ myhost〜]＃/ usr / local / bin / rkhunter –-update [root @ myhost〜]＃/ usr / local / bin / rkhunter –-check
Rkhunterは最初に重要なシステムファイルをチェックし、次にルートキットを探します。 さまざまな脆弱性のチェックが行われた後。 最後に、プログラムはApache、OpenSSHなどの一般的な製品のバージョンをチェックします。 最新バージョン用。
Rkhunterはその作業の結果をコンソールに表示し、統合ログ/var/log/rkhunter.logも形成します。 クラウンに対してこのルートキットを毎日実行し、電子メールでスキャンレポートを受信できます。
幸いなことに、rkhunterはサーバー上のマルウェアを検出しませんでした。これにより、落ち着いて、サーバー上でどのような奇妙なインストールが発生したかを考えることができました。 そして、サーバーを受け取った直後に、このサーバーにVPNサーバーをインストールして構成したことを思い出しました。 どうやら、ログウォッチに何らかのエラーがあり、2年前にレポートにデータを追加したようです。
もちろん、攻撃者がすべてを正しく行った場合、Logwatchはトレースを検出せず、サーバーの所有者は長い間何も疑いません。 ただし、このHowToで説明されている手順は、定期的に実行される場合、サーバーが危険にさらされるのを防ぐのに役立ちます。