mariadbが終わらない
今更ですがDebianをjessieからstretchにUpgradeしました。
Upgrade自体はいつもどおり /etc/apy/sources.list のjessieをstretchに置き換えて、
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
でほぼ通ったのですが、この際にmaeiadb-serverが依存関係でエラーはいてちょっとハマりました。
症状：
・mariadb-serverがupgradeできない
・たぶんmariadb-clientとの依存関係
・でもmariadb-serverをremoveもできない
・メッセージは「mariadb-serverが走ってるから手動で止めてよ」みたいなこと言ってるけど、systemctlとかserviceでは止まってる（というかFialedになってる）
原因：
どうやらmariadb-serverがsafe modeで走ってて、これを強制的に止めてやればよかった
対処：
ps でプロセス番号調べてkill -9
止まったの確認してからautoremoveなりremoveなりupgradeなりすればおｋ
1.発端
jessieからstretchへのUpgrade作業にてdist-upgrade時にエラーが出ていたので、まずは普通に修復を試みる。
$ sudo apt-get autoremove
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
これらを直すためには 'apt --fix-broken install' を実行する必要があるかもしれません。
提案パッケージ:
mariadb-test netcat-openbsd tinyca
以下のパッケージは「削除」されます:
mariadb-server-10.0 mariadb-server-core-10.0
以下のパッケージが新たにインストールされます:
libjemalloc1 mariadb-client-10.1 mariadb-client-core-10.1 mariadb-server-10.1 mariadb-server-core-10.1 socat
アップグレード: 0 個、新規インストール: 6 個、削除: 2 個、保留: 266 個。
693 個のパッケージが完全にインストールまたは削除されていません。
21.8 MB 中 0 B のアーカイブを取得する必要があります。
この操作後に追加で 78.2 MB のディスク容量が消費されます。
続行しますか? [Y/n] y
パッケージを事前設定しています ...
apt (1.4.8) を設定しています ...
新バージョンの設定ファイル /etc/apt/apt.conf.d/01autoremove をインストールしています ...
新バージョンの設定ファイル /etc/kernel/postinst.d/apt-auto-removal をインストールしています ...
usermod: 変更はありません
Created symlink /etc/systemd/system/timers.target.wants/apt-daily-upgrade.timer → /lib/systemd/system/apt-daily-upgrade
.timer.
Created symlink /etc/systemd/system/timers.target.wants/apt-daily.timer → /lib/systemd/system/apt-daily.timer.
Removing obsolete conffile /etc/cron.daily/apt ...
(データベースを読み込んでいます ... 現在 194534 個のファイルとディレクトリがインストールされています。)
mariadb-server-10.0 (10.0.32-0+deb8u1) を削除しています ...
1500
There is a MySQL server running, but we failed in our attempts to stop it.
Stop it yourself and try again!
dpkg: パッケージ mariadb-server-10.0 の処理中にエラーが発生しました (--remove):
サブプロセス インストール済みの pre-removal スクリプト はエラー終了ステータス 1 を返しました
Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.
invoke-rc.d: initscript mysql, action "start" failed.
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: failed (Result: exit-code) since Fri 2017-12-08 11:21:13 JST; 19ms ago
Docs: man:systemd-sysv-generator(8)
Process: 3153 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)12月 08 11:20:42 tminserver /etc/init.d/mysql[3180]: 171208 11:20:42 mysqld_safe A mysqld process already exists
12月 08 11:20:42 tminserver mysqld_safe[3227]: A mysqld process already exists
12月 08 11:21:13 tminserver mysql[3153]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . .…failed!
12月 08 11:21:13 tminserver systemd[1]: mysql.service: control process exited, code=exited status=1
12月 08 11:21:13 tminserver systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
12月 08 11:21:13 tminserver systemd[1]: Unit mysql.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: error while cleaning up:
サブプロセス インストール済みの post-installation スクリプト はエラー終了ステータス 1 を返しました
処理中にエラーが発生しました:
mariadb-server-10.0
W: システムにサンドボックスユーザ '_apt' がありません。権限を削除できません
E: Sub-process /usr/bin/dpkg returned an error code (1)
ダメです。
ちなみに apt --fix-broken install しても、apt-get remove mariadb-serverしても dpkg --configure -a してもだめです。
ポイントはここだった模様。
There is a MySQL server running, but we failed in our attempts to stop it.
Stop it yourself and try again!
2.対処1（失敗）
なんかMySQLが走ってるとか言ってるので、systemctlで状態確認。
$ systemctl status mysql
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: failed (Result: exit-code) since Fri 2017-12-08 11:21:13 JST; 2min 0s ago
Docs: man:systemd-sysv-generator(8)
Process: 3153 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)
Failしてます。
手動で止めようとしてみます。
$ sudo systemctl stop mysql
$ systemctl status mysql
● mysql.service - LSB: Start and stop the mysql database server daemon
Loaded: loaded (/etc/init.d/mysql)
Active: failed (Result: exit-code) since Fri 2017-12-08 11:21:13 JST; 2min 17s ago
Docs: man:systemd-sysv-generator(8)
Process: 3153 ExecStart=/etc/init.d/mysql start (code=exited, status=1/FAILURE)$ journalctl -xe
Hint: You are currently not seeing messages from other users and the system.
Users in the 'systemd-journal' group can see all messages. Pass -q to
turn off this notice.
No journal files were opened due to insufficient permissions.
変わってません。ここでautoremoveとかしてもやはり同じ。
つかFailしてるのに起動してるとは何事？
3.対処2（成功）
実はsafemodeでmariadbが起動していた模様です。
psで確認。
$ ps aux | grep sql
root 672 0.0 0.1 19524 3484 ? S 11:32 0:00 /bin/bash /usr/bin/mysqld_safe
mysql 753 0.1 4.4 735512 85424 ? Sl 11:32 0:02 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --skip-log-error --pid-file=tminserver.pid
root 754 0.0 0.0 26444 1284 ? S 11:32 0:00 logger -t mysqld -p daemon error
tmin 14764 0.0 0.0 12264 992 pts/0 S+ 12:05 0:00 grep sql
プロセスがわかったので、kill -9 で強制終了
$ sudo kill -9 672
$ sudo kill -9 753
$ sudo kill -9 754
ちゃんと終了したか確認。
$ ps aux | grep sql
tmin 14764 0.0 0.0 12264 992 pts/0 S+ 12:05 0:00 grep sql
apt 再実行
$ sudo apt --fix-broken install
mariadb-server-10.0 (10.0.32-0+deb8u1) を削除しています ...
以前に未選択のパッケージ mariadb-client-core-10.1 を選択しています。
(データベースを読み込んでいます ... 現在 194442 個のファイルとディレクトリがインストールされています。)
.../mariadb-client-core-10.1_10.1.26-0+deb9u1_amd64.deb を展開する準備をしています ...
mariadb-client-core-10.1 (10.1.26-0+deb9u1) を展開しています...
以前に未選択のパッケージ libjemalloc1 を選択しています。
.../libjemalloc1_3.6.0-9.1_amd64.deb を展開する準備をしています ...
libjemalloc1 (3.6.0-9.1) を展開しています...
以前に未選択のパッケージ mariadb-client-10.1 を選択しています。
.../mariadb-client-10.1_10.1.26-0+deb9u1_amd64.deb を展開する準備をしています ...
mariadb-client-10.1 (10.1.26-0+deb9u1) を展開しています...
(データベースを読み込んでいます ... 現在 194499 個のファイルとディレクトリがインストールされています。)
mariadb-server-core-10.0 (10.0.32-0+deb8u1) を削除しています ...
以前に未選択のパッケージ mariadb-server-core-10.1 を選択しています。
以前に未選択のパッケージ mariadb-server-core-10.1 を選択しています。
(データベースを読み込んでいます ... 現在 194419 個のファイルとディレクトリがインストールされています。)
.../mariadb-server-core-10.1_10.1.26-0+deb9u1_amd64.deb を展開する準備をしています ...
.../mariadb-server-core-10.1_10.1.26-0+deb9u1_amd64.deb を展開する準備をしています ...
mariadb-server-core-10.1 (10.1.26-0+deb9u1) を展開しています...
mariadb-server-core-10.1 (10.1.26-0+deb9u1) を展開しています...
以前に未選択のパッケージ socat を選択しています。
.../socat_1.7.3.1-2+deb9u1_amd64.deb を展開する準備をしています ...
socat (1.7.3.1-2+deb9u1) を展開しています...
以前に未選択のパッケージ mariadb-server-10.1 を選択しています。
.../mariadb-server-10.1_10.1.26-0+deb9u1_amd64.deb を展開する準備をしています ...
/var/lib/mysql: found previous version 10.0
mariadb-server-10.1 (10.1.26-0+deb9u1) を展開しています...
libjemalloc1 (3.6.0-9.1) を設定しています ...
socat (1.7.3.1-2+deb9u1) を設定しています ...
mariadb-client-core-10.1 (10.1.26-0+deb9u1) を設定しています ...
libc-bin (2.24-11+deb9u1) のトリガを処理しています ...
systemd (232-25+deb9u1) のトリガを処理しています ...
man-db (2.7.6.1-2) のトリガを処理しています ...
mariadb-client-10.1 (10.1.26-0+deb9u1) を設定しています ...
mariadb-server-core-10.1 (10.1.26-0+deb9u1) を設定しています ...
mariadb-server-10.1 (10.1.26-0+deb9u1) を設定しています ...
新バージョンの設定ファイル /etc/init.d/mysql をインストールしています ...
新バージョンの設定ファイル /etc/logrotate.d/mysql-server をインストールしています ...
新バージョンの設定ファイル /etc/mysql/debian-start をインストールしています ...
Created symlink /etc/systemd/system/mysql.service → /lib/systemd/system/mariadb.service.
Created symlink /etc/systemd/system/mysqld.service → /lib/systemd/system/mariadb.service.
Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → /lib/systemd/system/mariadb.service.
insserv: warning: current start runlevel(s) (empty) of script `mysql' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `mysql' overrides LSB defaults (0 1 6).
mariadb-server (10.1.26-0+deb9u1) を設定しています ...
systemd (232-25+deb9u1) のトリガを処理しています ...
通りましたね。
状態確認。
$ ps aux | grep sql
mysql 17785 0.2 4.1 677900 79808 ? Ssl 12:09 0:00 /usr/sbin/mysqld
tmin 18694 0.0 0.0 12264 936 pts/0 S+ 12:15 0:00 grep sql
このあと再度dist -upgradeすると、止まってた更新たちもちゃんと入ります。
しかし、普通mysqlのsafemodeってsystemctlとかserviceで起動・停止ができたと思うんだけど・・・
sshdへのアタックログをみてみよう＆対策しよう
ちょっと外出先からsshで自宅サーバに繋いで色々したいときとか多くて、
ルータのport転送とか使って外からssh接続できるようにしました。
したら毎日のsshへのブルートフォースがすごいことになってた。
■教訓
外部からアクセスできるsshサーバで、rootログイン許可は即刻やめるべき。
外部からアクセスできるsshサーバで、パスワード認証はできるだけやめるべき。
外部からアクセスできるsshサーバで、デフォルトポート(22）での運用はできるだけやめるべき。
外部からアクセスできるsshサーバでは、fail2banとかiptablesでアクセス制限かけたほうがいい。
■sshへの攻撃者はどのようにアクセスしてくるのか。
Debianなので、ログは/var/log/auth.logに出ます。（CentOSなら/var/log/secure）
というわけでログから調べますよっと。
ログイン失敗のログの一部
Dec 6 18:45:41 tminserver sshd[5876]: Failed password for root from 42.7.26.91 port 22754 ssh2
Dec 6 18:45:44 tminserver sshd[5876]: Failed password for root from 42.7.26.91 port 22754 ssh2
Dec 6 18:45:46 tminserver sshd[5876]: Failed password for root from 42.7.26.91 port 22754 ssh2
Dec 6 18:45:49 tminserver sshd[5876]: Failed password for root from 42.7.26.91 port 22754 ssh2
Dec 6 18:45:58 tminserver sshd[5878]: Failed password for root from 42.7.26.91 port 49250 ssh2
Dec 6 18:46:00 tminserver sshd[5878]: Failed password for root from 42.7.26.91 port 49250 ssh2
Dec 6 18:46:03 tminserver sshd[5878]: Failed password for root from 42.7.26.91 port 49250 ssh2
Dec 6 18:46:06 tminserver sshd[5878]: Failed password for root from 42.7.26.91 port 49250 ssh2
Dec 6 18:46:09 tminserver sshd[5878]: Failed password for root from 42.7.26.91 port 49250 ssh2
Dec 6 18:46:11 tminserver sshd[5878]: Failed password for root from 42.7.26.91 port 49250 ssh2
ちなみに件数
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec 1' | wc -l
0
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec 2' | wc -l
6572
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec 3' | wc -l
14007
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec 4' | wc -l
21951
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec 5' | wc -l
12345
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec 6' | wc -l
23431
tmin@tminserver:~$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec 7' | wc -l
5261
20000超とか来てますね。
圧倒的に多いのはrootで入ろうとしてFailed password（パスワード認証失敗）
root以外は何が多いかなっということで、Failed password forで出てるエラーログからユーザーのカラム抜き出して集計。
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec' | cut -d ' ' -f 10 | sort -n | uniq -c | sort -nr
82233 root
1266 invalid
19
11 mysql
9 sync
9 postfix
9 man
5 uucp
4 sshd
4 nobody
2 backup
1 sys
圧倒的にroot多し。他にはプロセス名とかでありそうなのを打ち込んでるのが少々。
invalid は存在しないユーザ名打ち込んでエラーになってるので別途集計。
該当ログはこんな感じ
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec' | grep 'invalid' | more
Dec 2 20:10:03 tminserver sshd[17682]: Failed password for invalid user 0101 from 5.188.10.156 port 46964 ssh2
Dec 2 20:10:18 tminserver sshd[17687]: Failed password for invalid user 0 from 5.188.10.156 port 49623 ssh2
Dec 2 20:10:29 tminserver sshd[17689]: Failed password for invalid user 1234 from 5.188.10.156 port 47647 ssh2
Dec 2 20:10:59 tminserver sshd[17697]: Failed password for invalid user admin from 5.188.10.156 port 50191 ssh2
Dec 2 20:11:02 tminserver sshd[17697]: Failed password for invalid user admin from 5.188.10.156 port 50191 ssh2
Dec 2 20:11:06 tminserver sshd[17697]: Failed password for invalid user admin from 5.188.10.156 port 50191 ssh2
Dec 2 20:11:09 tminserver sshd[17697]: Failed password for invalid user admin from 5.188.10.156 port 50191 ssh2
Dec 2 20:11:11 tminserver sshd[17697]: Failed password for invalid user admin from 5.188.10.156 port 50191 ssh2
ユーザ名のカラム抜き出して集計。
$ sudo grep 'Failed password' /var/log/auth.log | grep 'Dec' | grep 'invalid' | cut -d ' ' -f 12 | sort -n | uniq -c | sort -nr
489 admin
53 user
44 ubnt
36 test
36 pi
32 support
26 service
26 ftp
26
24 ftpuser
23 guest
20 1234
14 user1
13 super
13 adm
13 111111
12 operator
12 default
11 sysadmin
10 webmaster
10 tomcat
10 scan
10 postgres
10 manager
10 git
10 fax
10 apache
10 a
10 22
9 www
9 report
9 nagios
9 matsumoto
9 auction
8 0
7 usuario
7 mother
7 monitor
7 123321
6 api
6 administrator
6 123
5 testuser
4 plcmspip
4 client
4 anonymous
4 PlcmSpIp
3 master
3 cisco
3 Management
2 telecomadmin
2 sysadm
2 supervisor
2 raspberry
2 osmc
2 agent
2 Operator
1 zabbix
1 webadmin
1 vyatta
1 vt100
1 volition
1 vcr
1 username
1 ubuntu
1 ubadmin
1 ts3
1 telecom
1 telco
1 tech
1 target
1 system
1 svn
1 svin
1 superman
1 student
1 storwatch
1 steve
1 steam
1 shop
1 setup
1 security
1 sales
1 router
1 rcust
1 rapport
1 radware
1 public
1 print2000
1 poll
1 pizza
1 patrol
1 oracle
1 nt
1 naadmin
1 mtcl
1 mtch
1 mike
1 media
1 mark
1 mailman
1 library
1 jenkins
1 installer
1 init
1 info
1 hscroot
1 helpdesk
1 halt
1 ftptest
1 enrique
1 engineer
1 echo
1 e250
1 dvs
1 draytek
1 disttech
1 demo
1 david
1 daniel
1 bob
1 bill
1 am
1 adfexc
1 adam
1 acc
1 aaa
1 VTech
1 VNC
1 User
1 USERID
1 Sweex
1 SYSDBA
1 SYSADM
1 RSBCMON
1 Polycom
1 PSEAdmin
1 PRODDTA
1 NAU
1 Manager
1 MANAGER
1 HELLO
1 D-Link
1 Cisco
1 Administrator
1 Admin
1 ADMN
1 ;ccrusr
1 3comcso
1 266344
1 1502
1 12345
1 1111
1 0000
adminが頭一つ抜けてて、あとはuserとかありそうなユーザ名orプロセス名だったり。
ここまでの傾向から対策。
rootログイン禁止するだけで9割方防げる。
ユーザ名adminは次にやばい。（俺のサーバでは使ってない）
どうせport22への総当りなので、sshdを動かすport変更すればこれまたほとんど無くなる。
ここまでやっても0にはならないと思われるので、セキュリティ重視しなきゃな環境ならば、
パスワード認証やめて鍵認証とかにすれば、ユーザ名とポートがバレててもパスワード破られることがない。
■対策1 rootログインの禁止
簡単。効果はそこそこ。上記ログでダントツだったrootのログインが不可なので。
デメリットは自分もrootログインできなくなることくらいだが、そもそもいきなりrootで入って作業するとかリテラシーどうなの？ってかんじなので。
これで困る人は自分のやり方を考え直したほうがいいです。
/etc/ssh/sshd_configの設定でrootログインを禁止する。
$ sudo emacs /etc/ssh/sshd_config
PermitRootLogin yes →PermitRootLogin no
保存したらsshd再起動
$ sudo systemctl restart sshd
これでユーザrootで接続してみてログインできなければおｋ。
■対策2 ポート変更
簡単。効果は高め。これだけで多分普通のサーバならほとんど攻撃がなくなると思われ。
待受ポートがバレたらあれだけど、多分攻撃者は自動攻撃スクリプトかなんかを踏み台PCで実行してることがほとんどなため、
圧倒的に22番ポートへの攻撃が多い。無差別爆撃はまず22番への攻撃でしょう。
/etc/ssh/sshd_configの設定で待受ポートを変更
下の例では20022にしてるけど、ウェルノウンポート以外ならなんでもよい。
ウェルノウンポートでも使ってなくて使う予定もないならいいと思いますが。
$ sudo emacs /etc/ssh/sshd_config
Port 22 →Port 20022
保存したらsshd再起動
$ sudo systemctl restart sshd
これで22番ポートに接続して繋がらず、かつ20022でつながればおｋ。
■対策3 パスワード認証切って公開鍵認証のみにする
難易度普通。少しめんどい。
パスワード認証切るので、パスワード総当たり攻撃は全て防げる。
デメリットは鍵持ってない端末から入れなくなること。
めんどいから今回はやってない。
とはいえVPSの方はこれにしてます。
設定はこんな感じ
■対策4 fail2ban で攻撃回数に達したIPをbanする
結構難しいかも。設定も結構めんどい。
数回攻撃でアクセス自体拒否できるので、効果は大きい。
ないと思うけど一発目でアクセス成功、っていう攻撃には対処不可。
あと自分も間違えたら弾かれるので、自分が使う可能性があるIPは除外IPに入れとくのが良い。
設定した回数失敗したら攻撃とみなして該当IPをiptablesと連動してアクセス制限かける。
このあたりの説明がわかりやすいです。
さくらの VPS で CentOS fail2ban の設定 – TACKY.BIZ
ちなみにfail2banは設定によってsshの不正アクセス以外の監視にも使えるので、
wordpressのログイン画面へのアクセスの監視とか、apacheの.htaccessへのアクセス監視とか、色々応用が効きます。
近いうちにちゃんと試す( ･`ω･´)
■対策5 firewallで海外からのアクセス弾く
攻撃元IPは中国がダントツ。
iptablesとかで日本IP以外のアクセス弾けばほとんど防げると思われ。
ただこれだと日本のIPからの攻撃の場合はどうしようもない。
■まとめ
外部からssh接続できるってだけのサーバでもこれだけの攻撃にさらされるので、
ローカル以外で使うsshサーバは何らかの対策はしときましょう。
（数日間なんの対策もしてませんでしたすみません）
あと怪しいなってときはlastとかwで見たことないとこからのアクセスがないかチェックした方がいいと思われ。
Windows10でPowerShell,コマンドプロンプトからssh
WindowsではTeraterm使ってたんですけど、Linux使ってるときみたいにコマンドプロンプトからssh hogeを叩いてつなぎたい！！
ってことでやってみました。
Windows10 Pro x64 1709 build 17025.1000
接続先はお家サーバのDebian。sshdは設定済み。
導入までの流れ
1.Windows版OpenSSHをDLして適当なフォルダに配置。
2.Path通す
3.PowerShell or コマンドプロンプトからssh hogeしてつなぐ
4.ログインできたらやったね！！
1.なんかWindows版OpenSSHが出たらしい
ということでDL。
https://github.com/PowerShell/Win32-OpenSSH/releases
OpenSSH-Win64.zipをDL。Windowsの環境に合わせたのをDLしましょう。
今回は解凍したものをC\直下に配置。
2.システムの詳細設定から環境変数でPath通す。
新規にて
変数：Path
値：C:\OpenSSH-Win64
と設定してOK。
値は1でOpenSSH-Win64を配置したフォルダにします。
3.PowerShell or コマンドプロンプトからssh hoge
なんかssh ipだけにすると、ユーザ名が「ユーザ名@Windows端末名」になってる模様なので、エラー出ますけど。
ssh ユーザー名@接続先
で打てば大丈夫。
4.繋がったやったね！！
導入後
サーバに繋いだとこ。
一応文字化け等なく問題なく接続できたけど、X転送がうまくいかない。
VcXsrvの方の設定だと思うけれども。
