refirio.org

※httpに対しては使えないので注意。httpの場合は .htaccess で制限する ※127.0.0.1からのアクセスは許可しておく ■設定例 少なくともCentOS系では、httpdに対しては使えないので注意 環境によってはhttpdに対しても使えることがあるみたい SSH接続をIPアドレスで制限する - Qiita https://qiita.com/wwwaltz/items/db774fda77cb2d6c6922 ※.htaccessとは、Webサーバーの基本的な動作をディレクトリ単位で制御するためのファイル Apacheで利用できるが、nginxでは対応していないので注意 ※複数を設定するとき、設定順に注意 例えば「Order Deny,Allow」とした場合は「Deny → Allow」の順に設定する必要がある。混在させると正しく動作しない ※行の途中に「#」を書いてコメントを設けると、Apacheのバージョンによってはエラーになる 行頭から「#」を書いてコメントを設けるのが無難 ■特定IPからのみアクセスを許可 ■特定IPからのアクセスを拒否 ■特定IPからのアクセスを拒否（ロードバランサーを考慮） Nginx と Apache の、Basic認証 と IP制限 の様々な設定方法まとめ (ELBの有無も考慮) #nginx - Qiita https://qiita.com/hirai-11/items/c76b6890a65866905663 ■特定IPからのアクセスを拒否（直接アクセスとロードバランサーの両方を考慮） ■特定範囲IPからのアクセスを拒否 ※「203.0.113.0」と「10.0.0.0 〜 10.255.255.255」からのアクセスを許可 ■特定範囲IPからのアクセスを拒否（mod_rewriteでの指定） ※未検証 上にあるように「10.」のような書き方は有効か、なども確認したい apacheのRewriteCondをサブネットマスクで許可する - helen's blog https://helen.hatenablog.com/entry/2017/03/01/173847 IPアドレスとサブネットマスクとRewriteCond - knowledge::short https://www.km92.net/knowledge_short/2018/180222_000238.html .htaccessで特定のIPアドレス以外をメンテナンスページへ302リダイレクトさせてみた | www.ni4.jp https://www.ni4.jp/2018/02/17-220835.html ■特定ブラウザからのアクセスを拒否 ■特定ツールからのアクセスを拒否 ■その他参考ページ 【基本】.htaccessとは？何ができるの？書き方は？ | カゴヤのサーバー研究室 https://www.kagoya.jp/howto/it-glossary/web/htaccess/ .htaccess の書き方 | murashun.jp https://murashun.jp/article/programming/htaccess/htaccess-writing.html 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%E... nginxでは .htaccess に対応していない nginxに.htaccessを移行する。 - Qiita https://qiita.com/rdonster/items/a49b1861003645e7054b Nginxなはずのエックスサーバーで.htaccessが有効な理由 ｜ アフィ＋さぽ！ https://affi-sapo.com/1264/ htaccessを使わない方が良いとApacheとNginxの公式が言っている - suzu6の技術ブログ https://www.suzu6.net/posts/240-htaccess-apache-vs-nginx/ 【基本】.htaccessとは？何ができるの？書き方は？ | カゴヤのサーバー研究室 https://www.kagoya.jp/howto/it-glossary/web/htaccess/ ■Apache ユーザ名「test」、パスワード「1234」で制限をかける例 Basic認証設定ツール | refirio.org http://refirio.org/view/368 htpasswdファイル生成(作成) http://www.luft.co.jp/cgi/htpasswd.php .htaccessファイルの利用が許可されていない場合、あらかじめ許可しておく必要がある 以下は /home/test 内で.htaccessの利用を許可する例（「AllowOverride All」を指定すると許可される） 設定したら、Apacheの設定ファイルを再読み込みする ■Apache 2.4（特定のディレクトリ配下のみ） ※未検証 ディレクトリが存在する場合、そのディレクトリ直下に .htaccess を作成してBasic認証を設定すればいい 実際にはディレクトリが存在しない場合（URLルーティングを使用している場合など）、以下のように指定することで対応できる この場合、「/basic/secret」内にのみBasic認証をかけている 特定のURLだけBasic認証を掛けない #Apache - Qiita https://qiita.com/SHIN_DEVELOP/items/1cb7845fbfcd4bba3d69 ■Apache 2.4（特定のディレクトリは除外） ※「.htaccess でアクセス制限」も参考に ■Apache 2.4（特定のユーザーエージェントは除外） ※「.htaccess でアクセス制限」も参考に Apache 2.4 アクセス制御 - eastforest https://www.eastforest.jp/vps/4943 ■Apache 2.4（特定のIPアドレスは除外） ※「.htaccess でアクセス制限」も参考に Apache 2.4 アクセス制御 - eastforest https://www.eastforest.jp/vps/4943 MYN - 2016/05/30 14:21 / Apache 2.4.10 Satisfy Any http://myn.meganecco.org/1464585660.html 【.htaccess】特定のIPを除外してベーシック認証をかける方法 | web関連 | 勉強ブログ「二色人日記。」 https://twotone.me/web/3312/ ■Apache 2.2（特定のディレクトリ配下のみ） ディレクトリが存在する場合、そのディレクトリ直下に .htaccess を作成してBasic認証を設定すればいい 実際にはディレクトリが存在しない場合（URLルーティングを使用している場合など）、以下のように指定することで対応できる この場合、「/basic/secret」内にのみBasic認証をかけている 【Wordpress】特定URLにマッチするときにベーシック認証をするよ！ - やったこと https://absg.hatenablog.com/entry/2020/02/18/211922 ■Apache 2.2（特定のディレクトリは除外） ※「.htaccess でアクセス制限」も参考に Basic認証配下のディレクトリに、以下を記述した.htaccessを置くと、そのディレクトリをBasic認証対象外にできる .htaccessで特定のファイルやディレクトリのみBASIC認証を解除する | ザ サイベース https://thesaibase.com/server/htaccess-basic-auth ■Apache 2.2（特定のユーザーエージェントは除外） ※「.htaccess でアクセス制限」も参考に 以下のようにすれば、特定のユーザーエージェントからのみBasic認証なしでアクセスできる 以下は「Edg/89.0」もしくは「Selenium」を含むものを許可する例 Apache で特定の User-Agent だけ BASIC 認証をバイパスする方法 - アクトインディ開発者ブログ https://tech.actindi.net/2010/05/14/3482790616 ■Apache 2.2（特定のIPアドレスは除外） ※「.htaccess でアクセス制限」も参考に 以下のようにすれば、特定のIPアドレスからのみBasic認証なしでアクセスできる 以下は「127.0.0.1」と「203.0.113.1」を許可する例 ■nginx .htaccessで設定することはできないので、nginxの設定ファイルを編集して再起動する 例えば nginx.conf で以下のように設定すると、「/secret/」がBasic認証の対象になる .htpasswd の内容はApacheと同じ要領で作成できる 以下で設定ファイルの文法チェックができる 設定できたら以下のコマンドで設定ファイルを再読込する 再読込で大丈夫だが、もし反映されなければ再起動も試す それでも駄目なら、いったん停止してから起動する Nginx で Basic 認証 - Qiita https://qiita.com/kotarella1110/items/be76b17cdbe61ff7b5ca htpasswdファイル生成(作成) http://www.luft.co.jp/cgi/htpasswd.php nginxで設定ファイルチェック - Qiita https://qiita.com/yaotti/items/bd6774888a790c00e6fd Nginxでベーシック認証を行う際の注意点 http://wpnote.link/notes-when-performing-basic-authentication-with-nginx/ 上の手順でPHPページに対してBasic認証を設定すると、対象ページではPHPが実行されなくなる 冗長だが、以下のようにここにもPHPの設定を書く必要があるみたい nginxだとphp scriptファイルにbasci認証がかからないんで すけどー - オレンジの国 http://technical.live-on.net/archives/1414 ただしLaravelなどURLルーティング機能のあるフレームワークを使っている場合、 /index.php がリクエストを受け取って処理を始めるため、上記の方法で個別にBasic認証を制御できないみたい それでも設定すると、フレームワークから /secret/ のURLを呼び出したときに404エラーとなってしまう 対処方法があるかは要調査 以下は可能性がありそう？未検証 NginxでBasic認証(Laravel) | Qrunch（クランチ） https://qrunch.net/@G8AaKC38xzUeSbBe/entries/u9XM60aUWnMgTkts ■nginx（特定のディレクトリは除外） 以下のようにすれば、「.well-known」ディレクトリ内には認証なしでアクセスできる [Nginx] 特定 URL を Basic 認証から除外する方法 | CodeNote https://codenote.net/nginx/4204.html ■nginx（特定のユーザーエージェントは除外） 以下のようにすれば、特定のユーザーエージェントからのみBasic認証なしでアクセスできる 以下は「Chrome-Lighthouse」もしくは「Selenium」を含むものを許可する例 （なお「Chrome-Lighthouse」を許可すると、Basic認証をかけたサイトでもPageSpeed Insightsでの計測ができる） Nginxでbotからのアクセス時にBasic認証を外す #nginx - Qiita https://qiita.com/maruware/items/63574425900010a1b37a ■nginx（特定のIPアドレスは除外） 以下のようにすれば、特定のIPアドレスからのみBasic認証なしでアクセスできる 以下は「203.0.113.1」と「203.0.113.2」を許可する例 nginx 一部のアドレスにbasic認証を掛けない。 - podhmoの日記 http://d.hatena.ne.jp/podhmo/20110311/1299817584 nginxで特定のIPからは公開したいけどそれ以外はBASIC認証にしたいときの設定 - Qiita https://qiita.com/katamuki/items/9a0a5f288d041b421f4c ■AWS ALB+Lambda AWS.txt の「ロードバランサー」の「Basic認証」を参照 ■「AuthName」の値 上記で記載している「AuthName "Input ID and Password."」のような内容は正確では無さそう Apache | Basic認証を使ったアクセス制限を行う https://www.javadrive.jp/apache/allow/index3.html AuthNameの説明は 「認証領域」 「一度認証が通ったあと同じ認証領域の名前が設定されている Basic 認証が必要なページへアクセスしたときに認証が不要となります。」 とある よってここは「Developer」「Admin」「Sales」のような区分を設定すべきだと思われる ここの文字列が認証ダイアログに表示されるブラウザもあるが、少なくともChromeでは表示されない （「認証領域をユーザに告知する」という意味では、表示される方が自然な気はするが） よって何かしらの案内を書く場所でも無いのかもしれない ■.htpasswdの解析 htpasswdファイルに書かれたパスワードは非可逆な暗号化（ハッシュ化）されているため、復号化できない ただし入力したパスワードはBase64してヘッダ内に付与してやりとりされるため、ここからならパスワードを抜き出すことはできる つまりBasic認証の情報は暗号化されずに平文でやりとりされるため、SSL無しでBasic認証を使用するのは好ましくない 以下は具体例 とあるページで認証してからヘッダ情報を確認すると以下が記載されていた Authorization: Basic ZGVtbzplbnRyeQ== この「ZGVtbzplbnRyeQ==」をBase64デコードすると「demo:entry」となる これがBasic認証の認証情報 とあるページで認証してからヘッダ情報を確認すると以下が記載されていた authorization: Basic c3RhZ2luZzpxYXp3c3hlZGM= この「c3RhZ2luZzpxYXp3c3hlZGM=」をBase64デコードすると「staging:qazwsxedc」となる これがBasic認証の認証情報 .htpasswdファイルの解析（デコード）は無理。 | クズリーマンのカス備忘録 https://it-afi.com/apache/post-1054/ AWSで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 拒否 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - AWSを使っている場合、VPC全体にアクセス制限をかけることができる 詳細は AWS.txt の「ネットワークACL」を参照 参考 : DynamicDNSを利用し、iptablesとhosts.allowのルールに自宅IPを自動で追加する http://blog.glidenote.com/blog/2011/12/28/dyndns-iptables-hosts.allow/ IPアドレスで制限 ホスト名で制限 iptablesの設定 http://www.nina.jp/server/redhat/iptables/iptables.html iptablesのログフォーマットと内容について http://tech.sayama-yuki.net/archives/422 /etc/sysconfig/iptables を編集する この直前に以下を追加し、iptableを再起動 /var/log/messages に以下のようなログが記録されるようになった 「SRC=89.248.166.153」の部分で送信元IPアドレスが判る 「DST=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アドレスから色々なポートに対してアクセスがあれば、ポートスキャンの可能性がある 以下のログは基本的なファイヤーウォールのログなので無視していい？ 止まらない 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%2... strange kernel log message appeared http://www.linuxquestions.org/questions/linux-server-73/strange-kernel-log-message-appeared-41754352... AbuseIPDB - IP address abuse reports - Making the Internet safer, one IP at a time https://www.abuseipdb.com/ ■CentOS7のfirewallでの具体例 以下はCentOS7のfirewallで、中国からのアクセスを拒否した際のログ（説明用に若干改変してある） ログ形式はCentOS6のiptableと同じみたい ログの意味は以下のとおり 先頭領域： Apr 21 15:20:47 ... 4月21日15時20分47秒に記録された refirio kernel ... refirioサーバ FINAL_REJECT ... firewallコマンドによるデフォルトのラベル（？） MACレイヤ（L2）： IN=eth0 ... NIC eth0へのアクセス（？） OUT= ... 例えば eth1 とあればNIC eth1からのアクセス（？） MAC=52:54:0d:00:23:10:00:1b:ed:b0:c1:00:08:00 ... refirioサーバのNICのMacアドレス（？） IPレイヤ（L3）： SRC=122.4.199.68 ... ソースIPアドレス / 送信元アドレスは 122.4.199.68 （中国） DST=153.121.33.84 ... デスティネーションIPアドレス / 送信先アドレスは 153.121.33.84 （refirio.net） LEN=40 ... パケットの長さ TOS=0x00 ... IPヘッダ TOSフィールドの値 PREC=0x00 ... IPヘッダ TOSフィールド内、PRECEDENCEの値 TTL=50 ... IPヘッダ TTLの値 ID=60580 ... IPヘッダ IDの値 DF ... IPヘッダ Flag の DFビット(Don’t Fragment)が立っている場合 PROTO=TCP ... プロトコル / TCP TCPレイヤ（L4）： SPT=21667 ... ソースポート番号 / 送信ポート番号は21667 DPT=2222 ... デスティネーションポート番号 / 送信ポート番号は2222 WINDOW=39862 ... TCP Window RES=0x00 ... Reservedの値 ACK RST ... Control Bitsのそれぞれに対応（URG、ACK、PSH、RST、SYN、FIN） URGP=0 ... Urgent Pointerの値 ■Control Bits（制御ビット）について TCP/IPでコネクションを確立する時、終了するときに特定の制御ビットを送受信する 例えば接続確立の際には以下のやりとりが行われる。3ステップによって行われるため、「3ウェイハンドシェイク」と呼ばれる 1. クライアントからSYNパケットを送る 2. サーバからACK+SYNパケットが返される 3. クライアントからACKパケットを送ってコネクションを確立 ポートが空いていなかった場合、2でサーバからACK+RSTが返されて終了する また、接続終了の際には以下のやりとりが行われる 1. クライアントからFIN+ACKパケットを送る 2. サーバからACKパケットが返される 3. その後しばらくしてサーバからもFIN+ACKが送られてくる 4. クライアントからACKパケットを送ってコネクションを終了 制御ビットには以下がある URG ... urgent ACK ... acknowledgement PSH ... push RST ... reset SYN ... synchronize FIN ... finish /etc/sysconfig/iptables を直接設定せず、/etc/ppp/firewall-masq で設定する方法もある 以下によると、/etc/sysconfig/iptables はインターネット接続時に自動で実行されるファイルらしい つまり、インターネットに接続されたらファイヤーウォールが有効になるみたい Linuxルーター構築(rp-pppoe+iptables) - CentOSで自宅サーバー構築 https://centossrv.com/linux-router.shtml ファイル改竄検知システム導入(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%B... …と思ったが、チェックしようとすると以下のようなエラーが表示された ファイルを頻繁に更新するサイトでは煩わしいだけなので、いったんアンインストール（監視対象を限定できるのなら有用かも？要調査） ■代替案 監視対象を限定しないと毎日大量の監視結果が送られてくるので煩わしい が、あまり限定すると改ざん検知の意味が薄れるので難しいところ 以下のコマンドで更新日が10日以内のファイルを表示できるので これを応用して必要なときに改ざんを調査する方がいいかも ※コマンドの改ざんだけでなく、アカウントの状態やアプリケーションのバージョンなども診断してくれる ※chkrootkitよりも判りやすいかもしれないが、設定の最適化をしないと警告がたくさん来る。要勉強 ※Rootkit Hunterの方が判りやすいかも？ rootkit検知ツール導入(chkrootkit) http://centossrv.com/chkrootkit.shtml EC2では以下を参考にインストールできた Amazon EC2でマルウェアであるルートキットを検出する - chkrootkit / rkhunter - http://dev.classmethod.jp/cloud/amazon-ec2-rootkit/ ※上の設定で「SSHでの接続に5回失敗すれば、接続元をブロックする」となる ※/etc/sysconfig/iptables を編集してiptablesを再起動した場合、 iptablesにあるfail2banの設定内容が消えるので、fail2banを再起動する必要がある？ 自動起動に設定しておけば問題ない？ ユーザがWebサーバにファイルをアップロードするようなサービスの場合、 アンチウィルスソフトを導入しておくといい ■検証サーバについて 2020年3月時点で、AWSのEC2を使って検証 t2.micro だとメモリ不足でデーモンを起動できなかった t2.small なら起動できた 他の解説でも「t2.microでは動かなかった」のように書かれている ■前準備 HTTPで疎通確認できるようにしておく http://203.0.113.1/ ■インストール Amazon Linux 2にClamAVをインストールする - Qiita https://qiita.com/aosho235/items/e70ccf3b7464369bebab ログは以下で表示できる 上記の手順で設定した場合、以下からもログを表示できる 上記設定で freshclam は自動更新されるが、この実行タイミングはウイルススキャンの実行タイミングとは別物 あくまでもウイルス定義ファイル更新に関する設定 ■手動スキャン 以下でスキャンを手動実行できる。15秒程度で完了した ■メモリ使用量の検証 スキャンを手動実行すると、実行するたびにウイルス定義ファイル（500〜700MBくらい）を読み込んでからスキャンする デーモンとして起動しておくと ・起動時に1度だけウイルス定義ファイルを読み込んで常駐する（ただし読み込み内容を、デーモンがメモリ上に保持し続ける） ・1日1回アクセスの少ない早朝の時間帯にフルスキャンを行ってくれる となる ウイルス定義ファイルの読み込みには時間がかかるので、毎回読み込むと 「送受信するメールのスキャンに時間がかかり、メールの送受信が遅延する」 となってしまう可能性がある よって迅速なスキャンが必要でメモリが潤沢にあるサーバの場合、デーモンとして起動しておくといい 迅速なスキャンが不要で、メモリが潤沢でなく、1日に数回スキャンすれば十分…のような場合、手動スキャンも検討する 誤検知によって無害なファイルを削除してしまわないように、検出しても自動で削除せずにメールで通知するなどする ClamAVによる定期ウイルススキャンの設定 | 稲葉サーバーデザイン https://inaba-serverdesign.jp/blog/20170913/clamav_scan_virus_install.html nginxとPHPだけを入れた程度のEC2（t2.small）を用意し、 ClamAVをインストールしてデーモンとして実行すると、メモリ2GBのうち1GBくらいが常に使用中になった psコマンドで確認すると、以下のプロセスがあった 以下のコマンドでClamAVを終了させると上記プロセスは無くなり、 使用中のメモリも100MBくらいになった 以下はデーモン起動中のメモリ 以下はデーモン終了後のメモリ 上記の 「デーモン化すると、ウイルス定義ファイルの内容をメモリ上に保持し続けている」 と思われる挙動が確認できた ■手動スキャンとメモリ使用量の考察 なるべくメモリの消費を抑えるスキャンを検証 全体をスキャン 以下のようにしても同じ 全体をスキャンすると、以下のようなエラーが大量に表示される ファイルシステム sysfs・proc などは仮想ファイルが置かれる場所で実態が存在しないため、スキャンするとエラーになる ファイルシステムを跨がないで全体をスキャン。6分ほどでスキャンできたが、長く使っているサーバならもっと時間がかかる 対象を限定してスキャン。大したコンテンツ量では無いので、20秒ほどでスキャンできた 巨大過ぎるファイルはスキャンに失敗するので、2MB以上のファイルはスキャン対象から省く ウイルスが検出された例 運用の際は上記コマンドをスクリプトから実行し、「FOUND」という文字があればメールで通知…とすれば良さそう 誤検知によって無害なファイルを削除してしまわないように、検出しても自動で削除せずにメールで通知するなどする システム全体をスキャンすると時間がかかるので、一般ユーザがコンテンツを配置する可能性のある場所のみスキャンするか （Webサーバなら、「公開ディレクトリのみ」「アップロードファイルの保存場所のみ」など） ClamAVによる定期ウイルススキャンの設定 | 稲葉サーバーデザイン https://inaba-serverdesign.jp/blog/20170913/clamav_scan_virus_install.html IT とかその他もろもろ: ClamAV でウィルススキャン http://fishrimper.blogspot.com/2014/10/clamav.html ■エラー ■メモ Amazon Linux 2にClamAVをインストールする - Qiita https://qiita.com/aosho235/items/e70ccf3b7464369bebab Linuxアンチウイルスソフト ClamAV - Qiita https://qiita.com/bezeklik/items/4696e15c889ffff6bc41 clamscanとclamdscanの使用方法 - tech.farend http://tech.farend.jp/blog/2015/12/28/using-clamav/ アンチウイルスソフト導入(Clam AntiVirus) - CentOSで自宅サーバー構築 https://centossrv.com/clamav.shtml ClamAVによる定期ウイルススキャンの設定 | 稲葉サーバーデザイン https://inaba-serverdesign.jp/blog/20170913/clamav_scan_virus_install.html CentOS 7: ClamAVでウィルススキャンを実行する - Narrow Escape https://www.hiroom2.com/2017/06/06/centos-7-clamav%E3%81%A7%E3%82%A6%E3%82%A3%E3%83%AB%E3%82%B9%E3%8... VirtualBox+CentOS7環境に、ClamAVをdaemonで起動するようにインストールする - Qiita https://qiita.com/mopoki2696/items/dfc19a4a0b51b3bbace6 ClamAVのエラー　LibClamAV Error: mpool_malloc(): Attempt to allocate bytes. | OrangeGardenRoom http://blog.grandaria.com/?p=204 アンチウイルスソフト導入(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%8... Linuxでの効果的なAntivirus の設定と運用 https://oss.sios.com/security/antivirus-security-20161108 デフォルトでは /var/log/messages に対して、10分ごとに「SelfCheck: Database status OK.」というログが書き出されるのを無効に。 （ここには、もっと重要なログが出力されるべき） ※Clamはfreshclam.confを読み込んだあとにclamd.confを読む。 freshclam.confで設定されていない内容はclamd.confの内容が反映されると思われる。（要検証） （EC2 では service clamd.scan restart としないと再起動できない？） ■負荷対策に試したこと ウイルススキャンはCPUやメモリなどの消費が大きいので、Zabbixなどで監視している場合は警告が頻繁に来る 「CentOSで自宅サーバー構築」で紹介されているスクリプトを使っている場合、 以下のようにするとスキャン対象から除外できる（負荷の問題で、この2つは除外しておいた方がいいみたい） が、それでも負荷が高い 以下を clamscan.exclude に設定するといいかも つまり /home/ と /var/www/ のみチェック（EC2の場合）。必要に応じてチェック対象は追加 （シェルスクリプトを編集するよりは、設定ファイルの編集に留めた方が安全） それでもZabbixのアラームが飛ぶサーバがある CPU使用率を抑えて実行する方法はあるらしい？要勉強 http://dev.classmethod.jp/cloud/aws/clamav-process-controled-by-cgroup/ 一般ユーザにファイルアップロードを許可していないのなら、 ウイルスチェックは普段停止させておいて、自動起動もOFFにしておく方がいいかも 月に一回など、定期的にウイルスチェックを行うなどで十分かも IPA提供のウェブサービスを利用 http://www.ipa.go.jp/security/vuln/iLogScanner/ 以下の設定で検査を行う アクセスログ形式：Apache1.3系/2.0系/2.2系のcommonタイプ 解析対象アクセスログファイル名：解答したアクセスログをまとめて選択 出力先ディレクトリ：任意 詳細解析ボタンを押して… ログフォーマット：無視 開始日：先月の1日 終了日：前月の末日 解析レベル：詳細 解析開始ボタンを押して、ひたすら待つ IPアドレスから身元を調べる http://www.ip-inspector.com/ ログを改ざんされても攻撃の解析ができるように、ログは専用のログサーバに転送しておくといい rysslogでログの転送を行うなど（rysslogは未検証） ざっくり概要！Linuxセキュリティに関する基礎知識まとめ https://eng-entrance.com/linux-security-basic