【セキュリティ対策】単純なパスワードの危険性とブルートフォース 攻撃によるハッキングの実態 | Apple iOS 開発 YouTube セミナー 53


セキュリティ対策


- サーバーのパスワード管理とセキュリティの基本
- ブルートフォース攻撃の手口と実態
- fail2banとsshdの管理と設定


セキュリティ対策を強化してサーバーをブルートフォース 攻撃から守る


「以下は動画のハイライトです。」

パスワードを盗み取る手口は様々ですが、サーバーを運営すると必ず直面するのがこのブルートフォース攻撃です。

別名総当たり攻撃とも呼ばれます。例えば6桁の英数字のみのパスワードであればPCの性能にもよりますが、すべてのパターンのパスワードのパターンをトライされることにより数時間で解除される危険性があります。最もセキュリティ対策が全くない状態のことですが。

iOSアプリをサーバーと連携させると非常に様々なことができるようになりますが同時に管理も大変になります。ここでは基礎的なセキュリティ対策について解説させていただければと思います。

まず、標準的なlinuxサーバーでは以下のコマンドでsshdによるアクセスログを確認することができます。


cat /var/log/secure

Mar 4 06:39:13 myIPaddress sshd[31833]: Received disconnect from 178.23.151.66 port 40735:11: Bye Bye [preauth]
Mar 4 06:39:13 myIPaddress sshd[31833]: Disconnected from 178.23.151.66 port 40735 [preauth]
Mar 4 06:45:40 myIPaddress sshd[32159]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=178.23.151.66 user=root
Mar 4 06:45:40 myIPaddress sshd[32159]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Mar 4 06:45:42 myIPaddress sshd[32159]: Failed password for root from 178.23.151.66 port 40460 ssh2
Mar 4 06:45:42 myIPaddress sshd[32159]: Received disconnect from 178.23.151.66 port 40460:11: Bye Bye [preauth]
Mar 4 06:45:42 myIPaddress sshd[32159]: Disconnected from 178.23.151.66 port 40460 [preauth]



ポート番号をデフォルトの22などにしないということも必要な防御策の一つではありますが、自分のサーバーに不正アクセスの履歴がたくさんあると少しゾッとします。


IP address: 178.23.151.66



ここで一つ特徴的なものとして、この攻撃では同一のIPアドレスからのアクセスが連続で起きていました。そこでこうした手口に有効なものはfail2banというソフトがあります。


[root@myIPaddress directory]# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 10
| |- Total failed: 3562
| `- Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
|- Currently banned: 0
|- Total banned: 10
`- Banned IP list: 178.23.151.66
[root@myIPaddress directory]#



うまく機能するとこのように特定のIPアドレスを捉えてアクセスを禁止することができます。禁止されたIPアドレスはBanned IP listに格納されます。

どういう時に特定のIPアドレスを捉えるかは以下で設定できます。


jail.local
[ssh-iptables]
enabled =
ports =
filter =
logpath =
maxretry =



maxretryに設定する値は何回パスワードを間違っても良いかを指定します。例えば5と設定すると5回パスワードの入力を間違うとそのIPアドレスからのアクセスを禁止することが可能です。

ただ、fail2banでもプロキシなどから毎回IPアドレスを変えながら攻撃されるとうまく捉えることができません。次の例ではIPアドレスが毎回変更されながらブルートフォース 攻撃を仕掛けられている時のログです。


Mar 26 18:17:36 myIPaddress sshd[27771]: Received disconnect from 35.199.73.100 port 33200:11: Bye Bye [preauth]
Mar 26 18:17:36 myIPaddress sshd[27771]: Disconnected from 35.199.73.100 port 33200 [preauth]
Mar 26 18:18:19 myIPaddress sshd[27785]: Invalid user winfrey from 15.165.73.38 port 49864
Mar 26 18:18:19 myIPaddress sshd[27785]: input_userauth_request: invalid user winfrey [preauth]
Mar 26 18:18:19 myIPaddress sshd[27785]: Received disconnect from 15.165.73.38 port 49864:11: Bye Bye [preauth]
Mar 26 18:18:19 myIPaddress sshd[27785]: Disconnected from 15.165.73.38 port 49864 [preauth]
Mar 26 18:18:47 myIPaddress sshd[27800]: Invalid user the from 171.220.243.179 port 53966
Mar 26 18:18:47 myIPaddress sshd[27800]: input_userauth_request: invalid user the [preauth]



アクセスするタイミングを変えたり、ユーザー名を変えたり、またIPアドレスまでも変えながら不正アクセスを試みてきます。こうなってしまうとfail2banで特定のIPアドレスのアクセスを遮断する方法は取れません。

そこでこのような手法に対抗する防御策は以下のsshdのアクセス設定を変更することです。



vi /etc/ssh/sshd_config

root -> NO
sshd -> NO



直書きでこのようにrootでのアクセスやsshd自体のアクセスを不可にすることができますが、自分もリモートアクセスできなくなってしまう欠点があります。またviなどの直書きで毎回、必要に応じて設定変更するのはかなり面倒くさいです。

作業効率を考えてどうしても一時的に変更したいとのことでしたら、直書きで変更するより、コマンド入力でon offを切り替えると良いでしょう。

以下にその一例を記載します。


Yesにする
rm -f sshd_config; cp on/sshd_config sshd_config;
Noにする
rm -f sshd_config; cp off/sshd_config sshd_config;



カーレンとディレクトリに2つのonとoffというディレクトリを作成しその中に、一方はsshdをYesに書き換えたもの、他方はsshdをNoに書き換えた物を用意します。後は上記のコマンドのコピペで切り替えることができます。

rm でカーレンとディレクトリのsshd_configを削除した後、バックアップ用に作成したその二つのディレクトリから必要なファイルsshd_configをコピーします。

これにより、一時的にsshdを解放したいということがあれば簡単に切り替えを行うことができます。

ただ、この方法の難点は一時的に解放しなければならないということです。パスワードを10桁以上の複雑なものにしていればさほど心配することもないですが、やはり完全に封鎖した状態で作業するというのも理想的です。

最後にご紹介する方法はこちらです。


Good Sync

Attacked Server <-> GoodSync <-> Some Cloud <- Upload



Good SyncというMacアプリを使用してPC上の所定のフォルダをCloudサービスにアップロードします。Good Syncの良いところはCloudの一部のフォルダやファイルのみを同期させることができるということです。これによって高速に勝つ確実にファイルを同期させることができます。

クラウドのサービスによっては反映に時間がかかったり、実は同期してなかったりと不安なところもありますがこちらは視覚的にいつ同期したかなど確認することもできるのでサーバー管理という点では色々と有難いところがあります。

GoodSyncを利用しなくても良いのですが、セキュリティ上のポイントとしては攻撃を受けているAttacked Serverのsshdを完全に遮断している状態で、そのサーバーにファイルをリモートで送ることができます。

Google ドライブやDrop BoxなどのSome CloudをAttacked Serverにマウントしてcrontabなどで定期的に更新ファイルがないか確認させるという手段をとるということができます。更新されたファイルがあればコピーして自分のところに持ってくるという動作をさせればAttacked Serverの設定を変えずに済みます。


ソースコード入手方法はYouTubeのコメント欄に記載します。

目次へ戻る

2020年03月30日