Linuxサーバのセキュリティ対策 part1

10,535 views

Published on

Published in: Technology

Linuxサーバのセキュリティ対策 part1

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

×