Linuxサーバのセキュリティ対策 part1
- 1. 2013/5/13 Kazunori INABA 1 2013.5.10 Garage labsサーバー部8U （改）Linuxサーバのセキュリティ対策 ～僕がいつもやっていること part1 稲葉 一紀@札幌
- 2. 2013/5/13 Kazunori INABA 2 自己紹介 稲葉 一紀 サーバインフラ専門のフリーランスエンジニア 屋号決まっていません。 おもにアプリ開発企業・エンジニア向けに セキュリティ・可用性・性能・拡張性を考慮した ちょっと気の利いた サーバインフラ構成設計・設定・支援や既存システムの性能改善調査・支援 を行います。
- 3. 2013/5/13 Kazunori INABA 3 セキュリティ対策 - 基本方針 僕がサーバの設定を行うときにいつもやっていることを発表しま す。 ・できるだけPaaS, SaaS的な外部サービスや共用レンタル サーバを利用して、自分で設定、運用するサービスを減らす。 - 特にDNSとメールは自前でやらない！ - SSHとHTTP(S)のみ外部公開するのが理想。 - Webアプリケーションサーバ1台の運用保守を専門業者に 任せるといくらかかる？ ・どんな対策をしても、やられるときはやられる！ それでも、できるだけ少ない手間で基本的な設定を行い、 不正アクセスされる確率を減らす。
- 4. 2013/5/13 Kazunori INABA 4 セキュリティ対策 - 項目 ・SSH ・Firewall ・iptables ・TCP Wrapper ・不要なサービスの停止 ・DNS bind ・Apache ・ファイル転送 FTP, SCP/SFTP, WebDAV ・メール Postfix ・アンチウイルス ClamAV ・改ざん検知 Tripwire ・SEO対策 ・その他やってないこと SELinux, IPS, WAF ・技術以外の対策 以降、コマンドやConfigは、CentOSにおける例です。
- 5. 2013/5/13 Kazunori INABA 5 SSH(1) ・最近構築したさくらのVPSサーバで、開通後3週間で3,300回 の不正ログインチャレンジがあった。 - サイトの有名無名に関わらず攻撃は無差別にやってくる。 →→→→サーバを受け取ったらまずはサーバを受け取ったらまずはサーバを受け取ったらまずはサーバを受け取ったらまずはSSHの設定変更を！の設定変更を！の設定変更を！の設定変更を！ - /var/log/secure で自分以外の 'Accepted password for ～' の ログイン成功記録がないことを確認する。 →もしあれば何かを仕込まれているかもしれないので、初期化した ほうがよい。 ・できれば、アクセス元IPアドレスを限定＋公開鍵認証。 - でも、固定IPアドレスを持っていない場合があるし、複数人・ 複数組織のユーザが関わる場合は鍵のやりとりが手間。。。
- 6. 2013/5/13 Kazunori INABA 6 SSH(2) ・ポート番号を22から10022などに変更。 これだけで不正ログインチャレンジがほぼなくなる。 Port 10022 ・rootユーザのログインを禁止。 PermitRootLogin no ・MySQLユーザなど、一般的なサービス用アカウントのログイン を禁止。 DenyUsers mysql ※これらのユーザのログインシェルを /bin/bash ではなく、 /sbin/nologin とすべきかも。やったことないけど。
- 7. 2013/5/13 Kazunori INABA 7 Firewall(1) ・Firewall機器やルータ機器、クラウドサービスのFirewall機能 など、サーバの上位レイヤで制御する。 →不正アクセスによるサーバ負荷を軽減できる。 ・プライベートLANで他契約者のサーバと同じサブネットに属する 場合がある。AWSなど。 →Firewall機能（AWSのSecurity Groups）やiptablesを駆使して、 他契約者のサーバからのアクセスは防ぐ。
- 8. 2013/5/13 Kazunori INABA 8 Firewall(2) ・デフォルトはすべて禁止。必要なポートのみ許可する。 (iptablesも同様） ・サーバへの内向きだけではなく、可能であれば外向きも制御 する。(iptablesも同様） → 外向きは HTTP(TCP/80), HTTPS(TCP/443), DNS(UDP/53, TCP/53), SSH(TCP/22), FTP(TCP/20,21), SMTP(TCP/25), NTP(UDP/123), ICMP 程度で十分のはず。 ・SSH, FTPは可能であればアクセス元IPアドレスを限定する。 (iptablesも同様）
- 9. 2013/5/13 Kazunori INABA 9 iptables(1) ・サーバより上位のFirewall機能と併用する。 →設定ミス、漏れや不具合への対策のため、複数箇所で制限を 行うことが望ましい。 ・アクセス数がさほど多くなければ、ポート制御以外の、 Ping of Death対策やSYN Flood対策、ログ書き出し設定も 行うとよい。 →アクセス数が多い場合はこれらの処理のためCPU負荷が 増大してパフォーマンスが落ちることに注意。 ・設定変更でミスると、今接続している端末も切れてしまう可能性 があることに注意。 →慎重を期すならば、atコマンドで10分後にiptablesをクリアする 設定を入れてから設定変更する、などの工夫を。
- 10. 2013/5/13 Kazunori INABA 10 iptables(2) ・FTPサーバを立てるなら、iptablesのFTPモジュールを読み 込むよう設定する。 → パッシブ用のTCP/1024-65535 のアクセス許可ルールが 不要となる。（はずだけど、vsftpdでパッシブ用ポートの範囲を 指定したら、この範囲を許可しないと通信できなかった。 調査中。） – /etc/sysconfig/iptables-config IPTABLES_MODULES="ip_conntrack_ftp ip_nat_ftp" -- ・/etc/sysconfig/iptables ファイルを直接編集するよりは、シェル スクリプトを作成したほうが管理しやすい。（と思う）
- 11. 2013/5/13 Kazunori INABA 11 iptables(3) ・最近、さくらのVPSサーバに適用したiptables設定スクリプト例 -- #!/bin/sh # set_iptables.sh # last updated on: 2013/05/10 ina128@wine.plala.or.jp # ### 初期化 iptables -F iptables -X ### デフォルトルール、すべて破棄 iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP ### IP偽装パケット（インタフェースへのプライベートIPアドレスからのアクセス）をすべて破棄 iptables -A INPUT -i eth0 -s 127.0.0.1 -j DROP iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP ### ループバックインタフェースはすべて許可 iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT ### セッション確立後のアクセスは許可 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
- 12. 2013/5/13 Kazunori INABA 12 iptables(4) （iptables設定スクリプト続き） ### 内向きアクセスの許可 ## TCP - HTTP, HTTPS, SSH(10022に変更), FTPパッシブ(10021, 10030-10049)を許可 iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT # HTTP iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT # HTTPS iptables -A INPUT -m state --state NEW -p tcp --dport 10022 -j ACCEPT # SSH iptables -A INPUT -m state --state NEW -p tcp --dport 10021 -j ACCEPT # FTP Listen iptables -A INPUT -m state --state NEW -p tcp --dport 10030:10049 -j ACCEPT # FTP ## UDP - なし ## ICMP - pingやpingリクエストの戻りなど一部のみ許可 iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT ### 外向きアクセスの許可 ## TCP - HTTP, HTTPS, DNS, SSH, FTP, SMTP, DNSを許可 iptables -A OUTPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT # HTTP iptables -A OUTPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT # HTTPS iptables -A OUTPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT # DNS iptables -A OUTPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT # SSH iptables -A OUTPUT -m state --state NEW -p tcp --dport 20 -j ACCEPT # FTP Data iptables -A OUTPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT # FTP Control iptables -A OUTPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT # SMTP
- 13. 2013/5/13 Kazunori INABA 13 iptables(5) （iptables設定スクリプト続き） ## UDP - DNS, NTPを許可 iptables -A OUTPUT -p udp --dport 53 -j ACCEPT # DNS iptables -A OUTPUT -p udp --dport 123 -j ACCEPT # DNS ## ICMP - すべてを許可 iptables -A OUTPUT -p icmp -j ACCEPT # EOF --
- 14. 2013/5/13 Kazunori INABA 14 TCP Wrapper ・/etc/hosts.deny, /etc/hosts.allow ・SSH, FTP, SNMPなどのアクセス元IPアドレスが決まっている のであれば、設定するとよい。 ALL: 127.0.0.1 sshd: xxx.xxx.xxx.xxx vsftpd: xxx.xxx.xxx.xxx
- 15. 2013/5/13 Kazunori INABA 15 不要なサービスの停止 ・chkconfigコマンドで自動起動しているサービスを確認して 不要なサービスを停止する。 # chkconfig –list | grep ':on' avahi-daemon, bluetooth, ip6tables, iscsi, NFS(netfs, nfslock, rpsbind, rpcgssd, rpcidmapd rpcsvcgssd）などはデフォルトで 起動していることが多いがたいていは不要。 （参考）http://www.obenri.com/_minset_cent6/daemon_cent6.html # /etc/init.d/<service> stop # chkconfig <service> off
- 16. 2013/5/13 Kazunori INABA 16 DNS bind(1) ・DNSサーバの設定、運用は大変！ - 頻繁に発見されるbindの脆弱性、DNSサーバを利用した攻撃 の多さ、キャッシュにより設定ミスの時限爆弾化、仕様や設定の 複雑さ etc. - DNSサーバのダウンや設定ミスはWebサーバダウンと同じこと。 ・外部サービスの利用がおすすめ。 - キャッシュサーバは、サーバサービスベンダーが用意する DNSサーバを利用。 - 権威（コンテンツ）サーバは、ドメイン管理業者が用意する DNSサーバやAWS Route 53を利用。
- 17. 2013/5/13 Kazunori INABA 17 DNS bind(2) どうしてもDNSサーバの運用が必要なとき、、、 ・キャッシュサーバとしてのアクセス元IPアドレスを限定して、 オープンリゾルバーにならないようにする。 - オープンリゾルバーを利用したDNSリフレクター攻撃 （参考） http://internet.watch.impress.co.jp/docs/interview/20130426_597628.htm l 送信元IPアドレスを攻撃対象のIPアドレスに詐称した問い合わせを オープンリゾルバーに送信 →オープンリゾルバーからの応答が攻撃対象に返る。 ※実生活でいうと、「なりすまし出前注文」のようなもの。
- 18. 2013/5/13 Kazunori INABA 18 DNS bind(3) ・オープンリゾルバーにならないための設定例。 （参考） http://jprs.jp/tech/notice/2013-04-18-fixing-bind-openresolver.html – named.conf ... acl "TRUSTSRC" { // TRUSTSRCというacl作成の設定を追加します 192.168.0.0/24; localhost; }; options { ... //query-source port 53; // 外部への問い合わせ元のポート番号をランダム化します recursion yes; // リゾルバーとして動作します allow-query { TRUSTSRC; }; // TRUSTSRCからのみクエリを許可します allow-recursion { TRUSTSRC; }; // TRUSTSRCからのみリゾルバーとして動作します allow-query-cache { TRUSTSRC; }; // TRUSTSRCからのみキャッシュの内容を返します ... };
- 19. 2013/5/13 Kazunori INABA 19 つづく Part2以降に続く... ・Apache ・ファイル転送 FTP, SCP/SFTP, WebDAV ・メール Postfix ・アンチウイルス ClamAV ・改ざん検知 Tripwire ・SEO対策 ・その他やってないこと SELinux, IPS, WAF ・技術以外の対策