■TCP Wrapperでアクセス制限
※127.0.0.1からのアクセスは許可しておく # vi /etc/hosts.deny
#FTPへのアクセスを拒否 vsftpd: all
# vi /etc/hosts.allow
#アクセスを許可 vsftpd: 127.0.0.1 vsftpd: 203.0.113.0
■設定例 # vi /etc/hosts.deny
#SSHへのアクセスを拒否 sshd: all #不正アクセスを拒否 all: (IPアドレス) all: (IPアドレス)
# vi /etc/hosts.allow
#ローカルからのアクセスを許可 sshd: 127.0.0.1 #自宅からのアクセスを許可 sshd: 203.0.113.0 #会社からのアクセスを許可 sshd: 203.0.113.1
httpdに対しては使えないので注意。環境によってはhttpdに対しても使えるかも? SSH接続をIPアドレスで制限する - Qiita https://qiita.com/wwwaltz/items/db774fda77cb2d6c6922
■.htaccessでアクセス制限
■特定IPからのみアクセスを許可 Order Allow,Deny Deny from all Allow from 203.0.113.1 Allow from 203.0.113.2 ■特定IPからのアクセスを拒否 Order Allow,Deny Allow from all Deny from 203.0.113.1 Deny from 203.0.113.2 ■特定IPからのアクセスを拒否(ロードバランサーを考慮) SetEnvIf X-Forwarded-For "203.0.113.1" deny_ip SetEnvIf X-Forwarded-For "203.0.113.2" deny_ip Order Allow,Deny Allow from all Deny from env=deny_ip ■特定IPからのアクセスを拒否(直接アクセスとロードバランサーの両方を考慮) SetEnvIf X-Forwarded-For "203.0.113.1" deny_ip SetEnvIf X-Forwarded-For "203.0.113.2" deny_ip Order Allow,Deny Allow from all Deny from 203.0.113.1 Deny from 203.0.113.2 Deny from env=deny_ip ■特定範囲IPからのアクセスを拒否 ※「203.0.113.0」と「10.0.0.0 〜 10.255.255.255」からのアクセスを許可 Order Allow,Deny Allow from all Deny from 203.0.113.0 Deny from 10. ■特定ブラウザからのアクセスを拒否 BrowserMatch "Chrome/62.0.3202.94" bad_bot Order Allow,Deny Allow from all Deny from env=bad_bot ■特定ツールからのアクセスを拒否 BrowserMatch "Wget/1.14 (linux-gnu)" bad_bot Order Allow,Deny Allow from all Deny from env=bad_bot ■参考ページ ELB配下のApacheでのアクセス制御 | Developers.IO http://dev.classmethod.jp/cloud/aws/access-limit-behind-elb/ X-Forwarded-Forを使用して、IPアドレスでのアクセス制限 | ゆっくりと歩んでいこう https://ymyk.wordpress.com/2010/02/25/x-forwarded-for%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E3%80%81ip%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E3%81%A7%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E9%99%90/
■ロードバランサーでアクセス制限
EC2+ELBの場合、ロードバランサーでアクセス制限できる AWSのEC2+ELBで、ロードバランサへのアクセス時点で特定IPからのアクセスを弾く - Hina-Mode http://hinashiki.hateblo.jp/entry/2015/02/19/161258 ルール番号の若いものから優先的に判定されるので注意 222.175.107.74 からのアクセスを拒否する場合、一例だが以下のように設定する (他2つは、もともと設定されているもの) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ルール タイプ プロトコル ポート範囲 ソース 許可 / 拒否 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 50 すべてのトラフィック すべて すべて 222.175.107.74/32 拒否 100 すべてのトラフィック すべて すべて 0.0.0.0/0 許可 * すべてのトラフィック すべて すべて 0.0.0.0/0 拒否 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
■TCP Wrapperで Dynamic DNS からのアクセスを許可
# mkdir /etc/hosts.allow.d # vi /etc/crontab
00 * * * * root /usr/bin/host refirio.mydns.jp | awk '{print $4}' > /etc/hosts.allow.d/refirio_ip
# vi /etc/hosts.allow
#アクセスを許可 vsftpd: /etc/hosts.allow.d/refirio_ip
参考 : DynamicDNSを利用し、iptablesとhosts.allowのルールに自宅IPを自動で追加する http://blog.glidenote.com/blog/2011/12/28/dyndns-iptables-hosts.allow/
■iptableでアクセス制限
IPアドレスで制限 -A MY-FIREWALL -m state --state NEW -m tcp -p tcp --dport 21 -s 202.213.216.201 -j ACCEPT -A MY-FIREWALL -m state --state NEW -m tcp -p tcp --dport 60000:60030 -s 202.213.216.201 -j ACCEPT ホスト名で制限 -A MY-FIREWALL -m state --state NEW -m tcp -p tcp --dport 21 -s www.example.com -j ACCEPT -A MY-FIREWALL -m state --state NEW -m tcp -p tcp --dport 60000:60030 -s www.example.com -j ACCEPT
■iptableのログ
参考:iptablesの設定 http://www.nina.jp/server/redhat/iptables/iptables.html 参考:iptablesのログフォーマットと内容について http://tech.sayama-yuki.net/archives/422 # vi /etc/sysconfig/iptables … iptableを設定
#以上のチェックにかからなかったパケットは、ICMPパケット host-prohibited を返して接続を拒否 -A MY-FIREWALL -j REJECT --reject-with icmp-host-prohibited
この直前に以下を追加し、iptableを再起動
#以上のチェックにかからなかったパケットを /var/log/messages に記録。ただし記録は1秒間に1回まで -A MY-FIREWALL -j LOG --log-level info --log-prefix "[IPTABLES REJECT] : " -m limit --limit 1/s
/var/log/messages に以下のようなログが記録されるようになった Mar 21 16:02:05 refirio kernel: [IPTABLES REJECT] : IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:52:54:0d:00:23:01:08:00 SRC=153.121.33.75 DST=153.121.33.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=15869 PROTO=UDP SPT=138 DPT=138 LEN=209 Mar 21 16:03:03 refirio kernel: [IPTABLES REJECT] : IN=eth0 OUT= MAC=01:00:5e:00:00:01:b8:ca:3a:62:cc:e0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 Mar 21 16:03:32 refirio kernel: [IPTABLES REJECT] : IN=eth0 OUT= MAC=52:54:0d:00:23:10:00:24:38:2d:06:00:08:00 SRC=89.248.166.153 DST=153.121.33.84 LEN=40 TOS=0x00 PREC=0x00 TTL=19 ID=26437 PROTO=TCP SPT=3389 DPT=3389 WINDOW=50723 RES=0x00 SYN URGP=50723 「SRC=89.248.166.153」の部分で送信元IPアドレスが判る 「SRC=153.121.33.84」の部分で送信先IPアドレスが判る この場合、オランダからrefirio.netにアクセスがあり、そのアクセスを遮断したと判る 送信元IPアドレスがプライベートIPアドレスの場合、送信元が偽装されている可能性が高い これらは接続は拒否しておくといい プライベートIPアドレスの範囲は以下のとおり 10.0.0.0/8(10.0.0.0 〜 10.255.255.255) 172.16.0.0/12(172.16.0.0 〜 172.31.255.255) 192.168.0.0/16(192.168.0.0 〜 192.168.255.255) 以下の送信元も偽装されている可能性が高い これらも接続は拒否しておくといい 127.0.0.0/8 169.254.0.0/12 192.0.2.0/24 224.0.0.0/4 224.0.0.0/5 「SPT=138」の部分でソースポート番号(送信元のポート番号)が判る 「DPT=138」の部分でデスティネーションポート番号(送信先のポート番号)が判る 同じIPアドレスから色々なポートに対してアクセスがあれば、ポートスキャンの可能性がある 以下のログは基本的なファイヤーウォールのログなので無視していい? May 7 18:21:49 refirio kernel: [IPTABLES REJECT] : IN=eth0 OUT= MAC=01:00:5e:00:00:01:b8:ca:3a:62:cc:e0:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 参考:止まらない SRC 0.0.0.0 DST 224.0.0.1 http://luluya.mydns.jp/d_pukiwiki/index.php?%E3%81%82%E3%81%9F%E3%81%BE%E3%81%AE%E3%81%AA%E3%81%8B%2F2012-04-16#z46ea07d 参考:strange kernel log message appeared http://www.linuxquestions.org/questions/linux-server-73/strange-kernel-log-message-appeared-4175435284/
■firewall-masqを編集する
/etc/sysconfig/iptables を直接設定せず、/etc/ppp/firewall-masq で設定する方法もある # vi /etc/ppp/firewall-masq … firewall-masq を編集 # sh /etc/ppp/firewall-masq … firewall-masq を実行(iptables更新)
■logwatch(ログ監視ツール)導入
参考:[さくらのVPS]サーバー監視がとても捗るlogwatchを入れてみた http://www.happyquality.com/2012/02/02/1924.htm 参考:ログ監視ツール logwatch のインストールと設定 〜 CentOS6 http://easyramble.com/install-setup-logwatch.html 参考:logwatch によるログの収集 http://landisk.kororo.jp/diary/29_logwatch.php # yum install logwatch … インストール # /usr/sbin/logwatch --print … 動作確認 # vi /etc/logwatch/conf/logwatch.conf … 設定ファイルを編集
# Local configuration options go here (defaults are in /usr/share/logwatch/default.conf/logwatch.conf) #解析結果を送信するメールアドレス … メールアドレスを追加(設定しなかった場合、rootのアドレスに送られる) MailTo=refirio@example.com
■Tripwire(ファイル改ざん検知システム)導入
参考:ファイル改竄検知システム導入(Tripwire) http://centossrv.com/tripwire.shtml 上の方法ではEC2にインストールできなかったが、 yum install --enablerepo=epel tripwire とすればインストールできた 参考:AmazonLinuxでTripwireを使ってみる http://rikuga.me/2014/11/10/amazonlinux%E3%81%A7tripwire%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/ …と思ったけど、チェックしようとすると以下のようなエラーが表示された ファイルを頻繁に更新するサイトでは煩わしいだけなので、いったんアンインストール(監視対象を限定できるのなら有用かも?要調査) ### Warning: File system error. ### Filename: /dev/kmem ■代替案 監視対象を限定しないと毎日大量の監視結果が送られてくるので煩わしい が、あまり限定すると改ざん検知の意味が薄れるので難しいところ 以下のコマンドで更新日が10日以内のファイルを表示できるので これを応用して必要なときに改ざんを調査する方がいいかも # find ./ -mtime -11 -ls
■Rootkit Hunter(rootkit検知ツール)導入
※コマンドの改ざんだけでなく、アカウントの状態やアプリケーションのバージョンなども診断してくれる ※chkrootkitよりも判りやすいかもしれないが、設定の最適化をしないと警告がたくさん来る。要勉強 # yum install rkhunter … Rootkit Hunter をインストール # rkhunter --update … rootkit情報のデータベースをアップデート # rkhunter --check … チェックを実行
■chkrootkit(rootkit検知ツール)導入
※Rootkit Hunterの方が判りやすいかも? 参考:rootkit検知ツール導入(chkrootkit) http://centossrv.com/chkrootkit.shtml EC2では以下を参考にインストールできた 参考:Amazon EC2でマルウェアであるルートキットを検出する - chkrootkit / rkhunter - http://dev.classmethod.jp/cloud/amazon-ec2-rootkit/
■fail2ban(侵入防御ツール)導入
# yum install fail2ban # vi /etc/fail2ban/jail.local … 設定ファイルを編集(/etc/fail2ban/jail.conf は直接編集しない)
[ssh-iptables] enabled = true … 設定を有効にする filter = sshd … フィルタ名 action = iptables[name=SSH, port=10022, protocol=tcp] … アクション sendmail-whois[name=SSH, dest=root, sender=fail2ban@refirio.net] logpath = /var/log/sshd.log … 監視するログファイル maxretry = 5 … 最大リトライ回数
※上の設定で「SSHでの接続に5回失敗すれば、接続元をブロックする」となる # service fail2ban start … fail2banを起動 fail2ban を起動中: [ OK ] # chkconfig fail2ban on … fail2banの自動起動を設定 # iptables -L … iptablesの内容を確認 Chain fail2ban-SSH (1 references) … 最後に設定が追加されている target prot opt source destination RETURN all -- anywhere anywhere ※/etc/sysconfig/iptables を編集してiptablesを再起動した場合、 iptablesにあるfail2banの設定内容が消えるので、fail2banを再起動する必要がある? 自動起動に設定しておけば問題ない?
■Clam AntiVirus(アンチウィルスソフト)導入
参考:アンチウイルスソフト導入(Clam AntiVirus) http://centossrv.com/clamav.shtml 参考:ログから”SelfCheck: Database status OK”を消すの巻 http://blog.trippyboy.com/2011/%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3/%E3%83%AD%E3%82%B0%E3%81%8B%E3%82%89selfcheck-database-status-ok%E3%82%92%E6%B6%88%E3%81%99%E3%81%AE%E5%B7%BB/ 参考:Linuxでの効果的なAntivirus の設定と運用 https://oss.sios.com/security/antivirus-security-20161108 デフォルトでは /var/log/messages に対して、10分ごとに「SelfCheck: Database status OK.」というログが書き出されるのを無効に。 (ここには、もっと重要なログが出力されるべき) # vi /etc/freshclam.conf … 設定ファイルを編集
#LogSyslog yes … コメントアウトする
# vi /etc/clamd.conf … 設定ファイルを編集
#LogSyslog yes … コメントアウトする
※Clamはfreshclam.confを読み込んだあとにclamd.confを読む。 freshclam.confで設定されていない内容はclamd.confの内容が反映されると思われる。(要検証) # service clamd restart … Clam AntiVirus を再起動 (EC2 では service clamd.scan restart としないと再起動できない?) ■負荷対策に試したこと ウイルススキャンはCPUやメモリなどの消費が大きいので、Zabbixなどで監視している場合は警告が頻繁に来る 「CentOSで自宅サーバー構築」で紹介されているスクリプトを使っている場合、 以下のようにするとスキャン対象から除外できる(負荷の問題で、この2つは除外しておいた方がいいみたい) が、それでも負荷が高い echo "/proc/" >> clamscan.exclude echo "/sys/" >> clamscan.exclude 以下を clamscan.exclude に設定するといいかも つまり /home/ と /var/www/ のみチェック(EC2の場合)。必要に応じてチェック対象は追加 (シェルスクリプトを編集するよりは、設定ファイルの編集に留めた方が安全) それでもZabbixのアラームが飛ぶサーバがある /bin/ /boot/ /cgroup/ /dev/ /etc/ /lib/ /lib64/ /local/ /lost+found/ /media/ /mnt/ /opt/ /proc/ /root/ /run/ /sbin/ /selinux/ /srv/ /sys/ /tmp/ /usr/ /var/account/ /var/cache/ /var/crash/ /var/cvs/ /var/db/ /var/empty/ /var/games/ /var/kerberos/ /var/lib/ /var/local/ /var/lock/ /var/log/ /var/nis/ /var/opt/ /var/preserve/ /var/run/ /var/spool/ /var/tmp/ /var/yp/ CPU使用率を抑えて実行する方法はあるらしい?要勉強 http://dev.classmethod.jp/cloud/aws/clamav-process-controled-by-cgroup/ 一般ユーザにファイルアップロードを許可していないのなら、 ウイルスチェックは普段停止させておいて、自動起動もOFFにしておく方がいいかも 月に一回など、定期的にウイルスチェックを行うなどで十分かも service clamd.scan stop chkconfig clamd off cd /etc/cron.daily/ rm virusscan
■ウェブサイトへの攻撃を検出する
# cd /var/log/httpd/ … Apacheログがある場所へ移動 # tar zcvf /var/www/logs/httpd_log_201412.tar.gz ./access_log ./access_log-20141207 ./ssl_access_log ./ssl_access_log-20141207 … 各ログのタイムスタンプを確認し、前月の範囲すべてのログをアーカイブする IPA提供のウェブサービスを利用 http://www.ipa.go.jp/security/vuln/iLogScanner/ 以下の設定で検査を行う アクセスログ形式:Apache1.3系/2.0系/2.2系のcommonタイプ 解析対象アクセスログファイル名:解答したアクセスログをまとめて選択 出力先ディレクトリ:任意 詳細解析ボタンを押して… ログフォーマット:無視 開始日:先月の1日 終了日:前月の末日 解析レベル:詳細 解析開始ボタンを押して、ひたすら待つ IPアドレスから身元を調べる http://www.ip-inspector.com/
■メモ
参考:ざっくり概要!Linuxセキュリティに関する基礎知識まとめ https://eng-entrance.com/linux-security-basic