sshdのポート番号を変えるに至る道のり。

By | 2019年11月17日 , Last update: 2020年1月1日
スポンサーリンク

はじめに

最近、記事を書いている際に画像ファイルが急にアップロードできなくなり、原因を調べてみたところ、本Webサイトのjournalログが激増したせいでfilesystemの使用率が100%となっていました。

ということで、いろいろと対応策を検討&実行した結果、sshdのポート番号を変更することとしましたので、この記事ではsshdのポート番号を変えるに至るまでの経緯について書きます。

journalログの内容を調べてみた。

filesystemの使用率が100%の状況が続くと、思わぬところでファイルを削除してしまう(実際、本Webサイト用にカスタマイズしたPHPファイルのインストール時にこのエラーが発生してファイルがインストールされないどころか、もともとあったPHPファイルも削除されてしまうことがありましたw)等の問題が発生する可能性がありますので、root権限で以下のコマンドを実行して古いjournalログを削除してfilesystemのスペースを少し解放し、いったん落ち着きます。🍵

# journalctl −−vacuum-size=10M

 

filesystemのスペースがあいて落ち着いたところで、以下のコマンドを実行します。

# journalctl | less

 

上記のコマンドの実行結果として出力されるjournalのログをよーく観察すると…

11月 16 18:14:30 pandanote.info audit[13496]: USER_LOGIN pid=13496 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="(unknown)" exe="/usr/sbin/sshd" hostname=? addr=aaa.bbb.ccc.ddd terminal=ssh res=failed'

 

ってな感じのログが大量に出力されてました(IPアドレスの部分は加工しています)。

つまり、

  • 多数のクライアントからのsshdへのアクセスが大量に行われる。
  • アクセス自体は失敗するものの、失敗した旨のメッセージがjournalログに書き込まれる。
  • journalログの大きさが膨れ上がり、filesystemの使用率が100%に達する。
  • 画像ファイルがWordpressにアップロードできなくなる。←今ここ!!

という状況になっていたっぽいです。

「第n種DDoS攻撃のようなもの」が成立していた模様です。👍

最初の解決案

まずは、sshdへのアクセスを試みているクライアントのIPアドレスを抽出すべく、root権限で以下のコマンドを実行してIPアドレスとログに記録されている回数を確認します。

# journalctl -r | grep disconnect | grep ssh | gawk '{{ print $9 }}' | sort | uniq -c

 


スポンサーリンク

上記のコマンドにより抽出されたIPアドレスについてroot権限で以下のコマンドを実行し、アクセスを拒否するよう設定します。

# firewall−cmd −−add−source=aaa.bbb.ccc.ddd/32 −−zone=drop −−permanent
# firewall−cmd −−reload

 

なお、いくつかのIPアドレスを使い分けてsshdにアクセスしている可能性があるものについては、”/32″の部分を”/28″のように小さい数字にすることで、アクセスを拒否するIPアドレスの範囲を広げて設定します。

ここまでの作業を行った後に1時間ほど様子をみたところ、journalログの出力がいったん止まったように見えたので、翌朝に再度確認することにしました。💤

2番目の解決案


スポンサーリンク

次の日の朝に、journalログのファイルサイズを調べてみたところ、10Mバイトにしたはずのjournalログが8時間くらいの間に約130Mバイトになっていました。journalログの内容を調べてみたところ、sshdへのアクセスを試みて失敗した旨のログが大量に記録されていました。

これでは比較的すぐにjournalログのためにfilesystemの使用率が100%になる可能性が高そうです。

そこで、sshd等の設定を変更することによりsshdのポート番号を変更することにしました。

ポート番号を変えるための設定

SELinuxの設定変更

以下のコマンドを実行し、SELinuxの設定を変更します。なお”abcde”には変更後のポート番号を指定します(以下同じです)。

# semanage port −a −t ssh_port_t −p tcp abcde

 

sshdの設定変更


スポンサーリンク

以下の手順でsshdの設定を変更します。

  1. /etc/sshd/sshd_configの設定のうち、
    # Port 22

     
    となっている行のコメントを外し、

    Port abcde

     
    に変更します。

  2. root権限で以下のコマンドを実行し、sshdを再起動します。
    # systemctl restart sshd

     

firewalldの設定変更

最後にfirewalldの設定を変更します。

以下の2通りの方法が考えられますが、どちらでも良いと思います(※個人の意見です)。

portの設定を追加する方法

root権限で以下のコマンドを実行し、abcde番portへのアクセスを許可します。なお、zone名には外部からのアクセスの設定を行っているものを指定します。

# firewall−cmd −−zone=<zone名> −−add−port=abcde/tcp −−permanent
# firewall−cmd −−reload

 

以下のコマンドを実行し、portsに”abcde/tcp”と表示されていれば、設定完了です。

# firewall−cmd −−list−all −−zone=<zone名>
<zone名> (active)
(中略)
ports: abcde/tcp
(後略)

 

専用のサービスを作る方法

firewalldのsshd用の設定ファイルをコピーして書き換えてabcde番port用で接続を待ち受けるsshd用の設定ファイルを作成する方法です。

以下の手順で設定します。

  1. root権限で以下のコマンドを実行し、コピー元となる設定ファイルをカスタマイズをした設定ファイル用のディレクトリにコピーします。
    # cp /usr/lib/firewalld/services/ssh.xml \
    /etc/firewalld/services/ssh-abcde.xml

     

  2. /etc/firewalld/services/ssh-abcde.xmlを適当なエディタで開き、portタグのport属性を以下のように変更し、保存します。
    <port protocol="tcp" port="abcde"/>

     

  3. root権限で以下のコマンドを実行し、ssh-abcde.xmlをサービスとして追加し、sshを削除します。
    # firewall−cmd −−zone=<zone名> −−add−service=ssh-abcde −−permanent
    # firewall−cmd −−zone=<zone名> −−remove−service=ssh −−permanent
    # firewall−cmd −−reload

     

  4. root権限で以下のコマンドを実行し、servicesの項にssh-abcdeが含まれていて、かつsshが含まれていなければ設定完了です。
    # firewall−cmd −−list−all −−zone=<zone名>
    <zone名> (active)
    (中略)
    services: ssh-abcde
    (後略)

     

動作の確認

適当な端末から以下のコマンドを実行し、ログインに成功したら動作確認完了です。

$ ssh -p abcde <server name>

 
お疲れ様でした。🙇‍♂️

sshdのport番号変更後のjournalログの出力状況

sshdのport番号の変更後は、journalログにはsshdへのアクセスが原因と思われるメッセージが出力されなくなりました。

他にもNetworkManagerが大量に出力しているjournalログがあることがわかったので、journalログの出力が本当に必要なメッセージだけになるという状態にはなっていませんが、出力量は1/4程度に減っているようです。

まとめ

sshのポート番号を変えることにより、journalログが激増する感じではなくなりましたので、journalログを大量に出力することによるサーバのパフォーマンスの低下も防げそうです。

また、NetworkManagerがjournalログを出力する原因は不要なインターフェースを短い周期でenableに使用して失敗している旨のメッセージが出力されていることが原因のようですので、そのインターフェースをdownさせることにより、journalログの出力についても何とか適正化できそうです。

この記事は以上です。

スポンサーリンク

References / 参考文献