ネットワーク利用に関するFAQ | 豊橋技術科学大学情報メディア基盤センター

サブネット管理ネットワーク利用に関するFAQ

ネットワーク利用に関する質問の宛先は？

ネットワーク利用に関する技術的な質問・要望の宛先	supports@imc.tut.ac.jp
ネットワーク利用に関する事務的な申込等の宛先	net-registration@imc.tut.ac.jp

質問はtut.ac.jp ドメインまたは tut.jp ドメインのメールアドレスからお願いします

回答に，技科大の構成員以外には教えられない情報が含まれる場合がありますので，技科大ドメイン(tut.ac.jp または tut.jp のサブドメイン)以外のメールアドレスからの問い合わせには答えられません．技科大ドメインのメールアドレスからの送信をお願いします．

DNS サーバに関する質問

オープンリゾルバって何?

DNSキャッシュサーバは，ホスト名に対応するIPアドレスを検索する機能(名前解決機能)を提供します．通常，あるドメインに設置されているDNSキャッシュサーバは，そのドメインに所属しているクライアントからの問い合わせにのみ回答すれば十分です．

この設定が誤っていて，インターネット上のどこからでも名前解決を受け付ける状態になっているDNSサーバをオープンリゾルバと言います．

オープンリゾルバだと何が問題なの?

DNSキャッシュポイズニング攻撃を受けます．
外部のサーバに対する攻撃(DNS Amp)の踏み台として利用されます．

オープンリゾルバではないことを確認するには?

以下のサイトでチェックしてみて下さい．

DNSキャッシュポイズニングって何?

DNSには，問い合わせによって得られたIPアドレスや権威DNSサーバ名などの情報を一時的に記憶し，名前解決の際にそれらを再利用することで処理の効率化を図る，という機能があります．これをDNSのキャッシュ機能といい，多くのDNSサーバに実装されています．キャッシュ機能はDNSサーバへの問い合わせ数を大幅に減少させ，DNSやネットワークの負荷を全体に軽減させるという重要な役割を担っています．

この機能を悪用し，偽のデータをキャッシュに記憶させることでドメイン名の乗っ取りやフィッシングなどを図る攻撃が，DNSキャッシュポイズニングです．

さらに詳しい情報については，http://www.ipa.go.jp/security/vuln/DNS_security.html などを参照してください．

DNSキャッシュポイズニングされると，具体的に何が起こるの?

例として，皆さんが自分自身の机の上にあるパソコン上で動いているブラウザを使って，http://www.tut.ac.jp/ を閲覧しようとした場合を考えます．この時，ブラウザ(及び，そのパソコンのOS)は以下のような振る舞いをします．

www.tut.ac.jp というホスト名に対応する IP アドレスを，最寄りの DNS サーバに問い合わせます．
最寄りの DNS サーバは，以下の手順で IP アドレスを調べて，回答します．
- 自分自身のキャッシュを調べます．キャッシュ中に www.tut.ac.jp の IP アドレスが既に存在していれば，その IP アドレスを回答します．
- キャッシュ中に存在しなかった場合は，www.tut.ac.jp の属しているドメイン(tut.ac.jp)の権威 DNS サーバ(server.tut.ac.jp)に，www.tut.ac.jp の IP アドレスを問い合わせます．その結果(133.15.181.85)をキャッシュに格納して，回答します．
得られた IP アドレスを使って，実際の通信を開始し，ウェブページの内容等をダウンロードします．

DNSキャッシュポイズニングされると，DNSサーバのキャッシュに，www.tut.ac.jp の IP アドレスは aaa.bbb.ccc.ddd である，というような嘘の情報が書き込まれます．したがって，http://www.tut.ac.jp/ にアクセスしているつもりなのに，実際にはまったく別のサイトにアクセスしている，ということが起きます．

Yahoo! オークションとそっくりなフィッシングサイトを用意しておき，Yahoo! オークションにアクセスしているつもりのユーザのクレジット情報や銀行口座情報を盗む，というような悪用方法が知られています．

DNSキャッシュポイズニングは成功確率が低いから，それほど脅威じゃないって聞いたけど?

それは昔の情報です．2008年7月に発見された Kaminsky's Attack という手法を用いると，従来に比較して，飛躍的に高い成功率で攻撃可能です．対策されていない DNS サーバでは，10分以内に攻略可能であるという報告もあります．既に攻撃用のツールも出回っています．

DNSキャッシュポイズニング対策が行なわれていることを確認するには?

とりあえず https://www.dns-oarc.net/oarc/services/dnsentropy で調べてみて下さい．

任意のDNSサーバを調べるには，以下のコマンドを実行して下さい．

確認項目	コマンド例
DNS問い合わせに使用するポート番号がランダム化されていること	dig @調べたいDNSサーバのIPアドレス +short porttest.dns-oarc.net TXT
DNS問い合わせに使用するIDがランダム化されていること	dig @調べたいDNSサーバのIPアドレス +short txidtest.dns-oarc.net TXT

どうやって対策したら良いの?

2通りの対策があります．

対策済みのHostingサービスに移行する．
運用中のDNSサーバを改善する．

後者の具体的な方法は以下の通りです．

DNSサーバに最新の修正パッチを適用する．
- パッチの提供箇所については，http://www.jpcert.or.jp/at/2008/at080014.txt や各ベンダーのウェブサイトを参照して下さい．
設定ファイルの内容を見直す．

BIND9の設定例

BIND9の場合，以下のような設定方針を推奨します．

全体のデフォルト挙動としては，問い合わせも再帰検索も拒否するようにしておく．
マスターを担当しているゾーンのみは，問い合わせを許可するようにしておく．

具体例は以下の通りです．

// 自分のドメインの属するネットワークを指定して下さい．
acl mynetworks {
    127.0.0.1;
    133.15.0.0/16; // この例では学内全域を指定していますが，適切に制限して下さい．
};

options {
    <中略>
    // 以下の設定があると，送信側 UDP ポートのランダム化が行われません．
    // 以下の設定が「ない」ことを確認してください．
    //     query-source address * port 53;

    // 自分のドメインのネットワークからの再帰検索のみを許可して下さい．
    allow-recursion { mynetworks; };

    // BIND-9.5.0a5 より新しい BIND9 のデフォルト設定は，「DNS サーバが
    // 接続されているローカルネットワークの再帰のみを許可する」となって
    // います．
    //     allow-recursion { localnets; localhost; };
    // よって，条件を満たす BIND9 を使っている場合は，allow-recursion
    // の設定がなくても，オープンリゾルバにはなっていません．

    // 外部ネットワークからの再帰検索を許可する以下の設定が「ない」こと
    // を確認して下さい．
    //     allow-recursion { any; };
    // ※※※ 注意 ※※※
    // BIND-9.5.0a5 以前の BIND9 では，この設定がデフォルトでした．その
    // ため，古い BIND を使っている場合は，正しく allow-recursion が設
    // 定されていないと，allow-recursion { any; }; という設定があるのと
    // 同じ状態です．
    // ※※※ 注意 ※※※

    // 自分のドメインのネットワークからの問い合わせのみを許可して下さい．
    allow-query { mynetworks; };

    // ゾーン転送は，セカンダリサーバだけ許可する．
    allow-transfer {
        127.0.0.1;
        133.15.254.1; // この例では server1.tut.ac.jp を指定していますが，適切に変更して下さい．
    };
};

// ここでは，example.imc.tut.ac.jp というゾーンのマスターサーバの例を示
// しています．各自のドメインに合わせて適切に変更して下さい．
zone "example.imc.tut.ac.jp" {
    type master;
    <中略>
    // マスターを担当しているゾーンについてだけ明示的に問い合わせを許可する．
    allow-query { any; };
};

Windows Server 2003の設定例

コンテンツサーバの場合
- 再帰問合せ動作が無効になっていることを確認する
キャッシュ兼コンテンツサーバの場合
- Windows DNSサーバは，再帰問合せを受け付けるか／否かしか設定できないため(BIND のようなアクセス制御機能がない)，キャッシュサーバとコンテンツサーバを異なるコンピュータに分離して運用する．
キャッシュサーバの場合
- ファイアウォールなどのパケットフィルタリング機能を用いて，自ドメインからの再帰問合せのみを許可するよう制限する．

詳細については，http://www.ipa.go.jp/security/vuln/documents/DNS_security.pdfを確認してください．

メールサーバに関する質問

後方散乱(backscatter)メールって何?

spam 送信業者やウイルスは，辞書などを用いて機械的に生成したメールアドレスに対して，送信元アドレスを偽装したメールを大量に送信するという挙動をします．典型的な例は，以下の通りです．

From: 存在しない送信者アドレス <not-existent-sender@example.imc.tut.ac.jp>
To: 機械的に生成された受信者アドレス <automatic-generated-recipient@example.imc.tut.ac.jp>
Subject: 誰でも儲かる方法

そんな方法はあるわけないのにね．

後方散乱(backscatter)メール対策が行われていないメールサーバは，上記のようなメールに対して，以下の挙動をします．

メールを受け取って，サーバ上のディスク(メールスプール)に書き込む．
受信者アドレスが存在しないので，配達に失敗する．
配達失敗を通知するメールを，送信者アドレスに返送しようとする．

この挙動の中で，3番目の処理として行われる「配達失敗を通知するメール」のことを後方散乱(backscatter)メールと呼びます．

後方散乱(backscatter)メールの何が問題なの?

2つの問題があります．

第1の問題は，後方散乱メールは非常に多いため，メールサーバのCPU処理時間およびディスクやネットワーク帯域幅を浪費するという問題です．例えば，学内のあるメールサーバからは毎分20通(1日に約3万通!)の後方散乱メールが送信されていました．

第2の問題は，後方散乱メール対策を行っていないメールサーバは，spam 送信対策を行っていないメールサーバと誤認されやすいという問題です．上記の例では，存在しない送信者アドレスとして not-existent-sender@example.imc.tut.ac.jp という例を使っていましたが，実際の spam メールでは，yahoo.co.jp や gmail.com などのフリーメールのドメインが，送信者アドレスとしてしばしば使われます．そうすると，yahoo.co.jp などのメールサーバは，後方散乱メール対策を行っていないメールサーバから，非常に大量の後方散乱メールを受け取ることになります．しかも，それらの後方散乱メールは，yahoo.co.jp などのメールサーバにとっては宛先不明のメールです．そのため，yahoo.co.jp などのメールサーバから見ると，後方散乱メール対策を行っていないメールサーバは，大量の宛先不明メールを送信しているメールサーバ，言い換えれば spam を送信しているメールサーバ，であるかのように見えてしまいます．そのため，yahoo.co.jp などのメールサーバは，後方散乱メール対策を行っていないメールサーバから送られてきた正規のメールも spam と誤判定するようになります．

後方散乱(backscatter)メールを送らないようにするには?

実際にメールを受信するプライマリメールサーバと，プライマリメールサーバが停止している時に一時的にメールを保管するセカンダリメールサーバとで対策が異なります．

まず，プライマリメールサーバの場合は，2通りの対策方法があります．

対策されているHostingサービスのメールサーバを利用する．
存在しない受信者アドレス宛のメールを受け取らないよう設定する．

以下では，後者の対策方法「存在しない受信者アドレス宛のメールを受け取らないよう設定する」について説明します．

後方散乱メール対策を行っていないメールサーバは，以下のような挙動をします．

送信元メールサーバからのネットワーク接続を開始する．
メールを受け取る．
メールを一時保管用ディスク(メールスプール)に書き込む．
送信元メールサーバからのネットワーク接続を終了する．
メールの受信者アドレスをチェックして，実際に配達するべき個人用メールボックスに書き込む．
- 受信者アドレスが存在しない場合には，この時点で配達失敗エラーとなって，後方散乱メールを送信してしまう．

上記に対して，一時保管用ディスク(メールスプール)にメールを書き込むよりも前の段階で受信者アドレスをチェックするメールサーバ(後方散乱メール対策を行ったメールサーバ)は，以下のような挙動をします．

送信元メールサーバからのネットワーク接続を開始する．
メールを受け取る．
メールの受信者アドレスが本当に存在するかどうかチェックする．
- 受信者アドレスが存在する場合は，メールを一時保管用ディスク(メールスプール)に書き込む．
- 受信者アドレスが存在しない場合は，宛先不明なので受け取りを拒否するよ，と送信元メールサーバに通知する．
送信元メールサーバからのネットワーク接続を終了する．
メールの受信者アドレスをチェックして，実際に配達するべき個人用メールボックスに書き込む．
- 既にチェック済みなので，配達失敗エラーにはならないはず．

メールサーバとして Postfix を使っている場合は，デフォルトで，上記の対策が行われているはずです．念のために，

postconf smtpd_reject_unlisted_recipient

というコマンドを実行して，yes になっているかどうかを確認してみてください．このオプション smtpd_reject_unlisted_recipient が存在しない場合は，使っている Postfix が古すぎるので，更新してください．

メールサーバとして qmail を使っている場合は，デフォルトでは，後方散乱メール対策が行われていません．また，qmail は，プログラムの構造上の制限により，上記のようにネットワーク接続中に受信者アドレスをチェックする設定ができません(qmail 本体を改造する必要があります)． http://spam.h1r.org/qmail/badlocal.html などで紹介されているように，ローカルに存在しないアドレス宛のメールに対して配達失敗メールを返送しないように設定してください．なお，qmail は最近殆どメンテナンスされていませんので，幾つかパッチをあてないと，現代的なメールサーバとしては非常に使いにくいと思います．少なくとも，「qmail はセキュリティが高い」という評判だけを頼りに，サーバ管理初心者が導入することは勧められません．

メールサーバとして sendmail を使っている場合は，デフォルトでは，後方散乱メール対策が行われていません．適切に対策を行ってください．

セカンダリメールサーバの場合は，プライマリメールサーバ上に格納されている実在する受信者アドレスリストを，何らかの形でセカンダリメールサーバ上に定期的にコピーし，実在しない受信者アドレスに対するメールを拒否するような設定が必要になります．具体的な方法については，それぞれのサイトの実装に依存しますので，ここでは解説しきれません．例えば，センターが運用しているHostingサービスのメールサーバでは，受信者アドレスリストをLDAPサーバ上に格納してあり，プライマリメールサーバとセカンダリメールサーバが常に同一の受信者アドレスリストを参照するようにして対策してあります．

対策するための人員と技術が不足している場合は，Hostingサービスのメールサーバを利用することを勧めます．

ウェブサーバに関する質問

CGI版PHPの脆弱性って何?

CGI版のPHPにコマンドライン引数としてPHPのオプションを指定することにより，リモートから任意のスクリプトを実行できる脆弱性です．詳しくは， http://blog.tokumaru.org/2012/05/php-cgi-remote-scripting-cve-2012-1823.html の解説を参照してください．

本学でも，CGI版PHPの脆弱性を狙った攻撃が実際に発生し，学内と学外の通信が約5時間にわたって阻害される障害が起きました．

CGI版PHPの脆弱性を狙った攻撃の調査方法

この攻撃を受けた場合，特定の文字列「php://input」または，この文字列をURLエンコードした文字列「%70%68%70%3A%2F%2F%69%6E%70%75%74」を含むアクセス記録が残っているはずです．このアクセス記録を探して，さらに，その中から成功ステータス 200 を返しているものを抽出することによって，この攻撃を受け，さらに侵入されているか否かが分かります．調査対象と期間は以下の通りです．

検索する文字列
- php://input
- %70%68%70%3A%2F%2F%69%6E%70%75%74 <--- （"php://input" を URL エンコードした文字列）
調査対象の期間
- 少なくとも 2013年10月31日（木）から現在までのアクセス記録（可能であれば保存されているすべてのアクセス記録）
アクセス記録（ログ）のディレクトリとファイル（デフォルト設定の場合）
- RedHat 系（CentOS など）の場合
  - アクセス記録（ログ）のディレクトリ: /var/log/httpd
  - アクセス記録（ログ）のファイル名: access_log, access_log.1.gz, access_log.2.gz
- Debian 系（Ubuntu など）の場合
  - アクセス記録（ログ）のディレクトリ: /var/log/apache2
  - アクセス記録（ログ）のファイル名: access.log, access.log.1, access.log.2.gz
- Windows 系 IIS 6 〜 7.5 の場合
  - アクセス記録（ログ）のディレクトリ: C:\inetpub\logs\LogFiles\W3SVC1
  - アクセス記録（ログ）のファイル名: u_exYYYYMMDD.txt（"YYYYMMDD"は日付）

以下の手順で調査を行なってください．

RedHat 系（CentOS など）

アクセス記録（ログ）のディレクトリに移動する。
```
# cd /var/log/httpd
```

攻撃が成功しているアクセス記録を探す。

# (cat access_log; gzip -dc access_log.1.gz access_log.2.gz) | grep -e "php://input" -e "%70%68%70%3A%2F%2F%69%6E%70%75%74" | grep " 200 "Debian 系（Ubuntu など）

Debian 系（Ubuntu など）

アクセス記録（ログ）のディレクトリに移動する。

# cd /var/log/apache2

　2.攻撃が成功しているアクセス記録を探す。

# (cat access.log access.log.1; gzip -dc access.log.2.gz) | grep -e "php://input" -e "%70%68%70%3A%2F%2F%69%6E%70%75%74" | grep " 200 "

Windows 系 IIS 6 〜 7.5

「コマンドプロンプト」を起動する。
アクセス記録（ログ）のディレクトリに移動する。

> cd C:\inetpub\logs\LogFiles\W3SVC1

　3.攻撃が成功しているアクセス記録を探す。

> find "php://input" u_ex*.log | find " 200 "
> find "%70%68%70%3A%2F%2F%69%6E%70%75%74" u_ex*.log | find " 200 "

攻撃を受けてた! どうしたら良いですか?

https://imc.tut.ac.jp/security/incident.html の記述にしたがって，情報メディア基盤センターに連絡してください。

ネットワークケーブルは抜いてください．調査を行う必要がありますので，電源はオフにしないでください．

SSHサーバに関する質問

学外から利用できるSSHサーバを設置するには?

https://imc.tut.ac.jp/subnet/form.html に記載されているサーバ設置申請を提出してください．

最近は，SSHサーバを対象とするパスワード総当たり攻撃が非常に増えてきています．例えば，情報メディア基盤センターのサーバにも，1日に5〜10個所からの攻撃(1個所からの攻撃はおおよそ数百回のパスワードによるログイン試行からなるので，数千回/日程度の攻撃)があります．そのため，以下の対策を行ってください．

(必須)rootでのログインを禁止してください．/etc/ssh/sshd_config に以下の記述を加えてください．
```
PermitRootLogin no
```
パスワードによるログインを禁止するか，または，パスワード総当たり攻撃を検知・自動的にログインを拒否する対策ソフトウェアを導入してください．パスワードによるログインを禁止する場合は，/etc/ssh/sshd_config に以下の記述を加えてください．

ChallengeResponseAuthentication no
PasswordAuthentication no

　3.パスワード総当たり攻撃を検知・自動的にログインを拒否する対策ソフトウェアとしては，denyhosts または pam-shield が有効です

DenyHosts をインストールする方法は?

RedHat または CentOS に denyhosts をインストールするには，EPEL レポジトリから入手する方法がもっとも簡単です．

以下のいずれかから epel-release パッケージをダウンロードしてください．
- RedHat7 64bit版の場合: http://download.fedoraproject.org/pub/epel/7/x86_64/repoview/epel-release.html
- RedHat7 32bit版の場合: http://download.fedoraproject.org/pub/epel/7/i386/repoview/epel-release.html
- RedHat6 64bit版の場合: http://download.fedoraproject.org/pub/epel/6/x86_64/repoview/epel-release.html
- RedHat6 32bit版の場合: http://download.fedoraproject.org/pub/epel/6/i386/repoview/epel-release.html
- RedHat5 64bit版の場合: http://download.fedoraproject.org/pub/epel/5/x86_64/repoview/epel-release.html
- RedHat5 32bit版の場合: http://download.fedoraproject.org/pub/epel/5/i386/repoview/epel-release.html
以下のコマンドを実行して，epel-release パッケージをインストールしてください．X,Y の部分は，ダウンロードした epel-release パッケージの名前に合わせて置き換えてください．

rpm -ivh epel-release-X-Y.noarch.rpm

　3.以下のコマンドを実行し，denyhosts をインストールしてください．

yum install denyhosts

　Debian または Ubuntu に denyhosts をインストールする場合は，以下のコマンドを実行してください．

apt-get install denyhosts

トラブル対策

USBメモリを介したウィルス感染対策

ウィルスに感染したUSBメモリを挿した時に設定によってはウィルスがコンピュータに感染し、感染したコンピュータにUSBメモリが接続されると自動実行ファイル｢autorun.inf｣を作成してUSBメモリが感染することで、USBワームが広がっています。Web上の別のウィルスをダウンロードして感染させる場合があります。感染を予防するためには、

落し物や外部のものなど出所不明のUSBメモリを接続しない
ウィルス対策のしていないコンピュータにはUSBメモリを挿さない
コンピュータにUSBメモリを挿したときに自動再生しない設定にする（自動再生機能の無効化）
コンピュータにUSBメモリを挿したときに自動再生が始まったら、シフトキーを押し続けて自動再生を止める
USBメモリからファイルを開く前にUSBメモリのウィルス検索を行う
ウィルススキャン／ハードウェア自動暗号化機能搭載セキュリティUSBメモリを利用する(IODATAなど)

などの対策があります。詳しくはトレンドマイクロなどでUSBメモリの項を参考にしてください。また、文部科学省大臣官房政策課情報化推進室の｢USBメモリ等を経由して感染する不正プログラム対策について｣を添付します sankou-USB.pdf。

シマンテックSEPにUSBメモリ内のウィルスを手動削除するコマンドがありますか？

方法としては、普通のファイルの削除コマンドと同様で、以下のコマンドで削除できます。

del ドライブ：￥ファイル名　/p

SEPに通常システムで検知・削除すると復活するようなウイルスの場合の対処方法がありますか？

最新の定義ファイルの状態で完全スキャンを実行します。
疑わしいファイルがある場合には、削除します。
削除後、復活した場合には、下記のリンクで該当の情報があるかを確認します。
- 英語のサイト
  
  http://www.symantec.com/business/security_response/index.jsp

Mac用ウイルス対策ソフト(Symantec Endpoint Protection for Mac VirusDefs)の更新について

LiveUpdateの更新頻度を手動で設定しているのにも関わらず，LiveUpdateによる更新確認が自動的に発生する．
- スケジューラで設定してる定時スキャンとは別に毎日数回発生します．
起動時と定期的に比較的大きい(数十～百数十MB)更新ファイルのダウンロードが開始される．
更新後に概略のウインドウが表示されるが，そこで確認する限りは全ての製品が最新版ということになっている． (添付図をご参照ください）
また，一部のMacでは，
- LiveUpdate had an error updating the virus definitions.
というエラーメッセージが表示されます．

（回答）

 SEP for Mac を管理外としてインストールした場合、自動的に 1 時間おきに更新を確認するための LiveUpdate スケジュールが設定されます。この LiveUpdate のスケジュールでは、進行状況を非表示にするオプションが無効となっているため、定期的に LiveUpdate の実行結果を示すウィンドウが表示されます。

自動的に実行される LiveUpdate の実行状況を表示させたくない場合には、次のいずれかの方法を利用できます。

a) 定期的に実行される LiveUpdate を非表示にする
b) LiveUpdate スケジュールを削除する

それぞれの手順の詳細につきましては、以下の内容をご参照ください。


a) 定期的に実行される LiveUpdate を非表示にする
管理外としてインストールした SEP for Mac クライアントのスケジュール設定を非表示の表示で実行させるために、スケジュールの設定を変更する方法があります。
スケジュールの設定をサイレントに実行させるように設定を変更するコマンドの例は、以下の通りです。

1. ターミナルを起動する。
2. 以下のコマンドを実行する。

$ sudo symsched -f LiveUpdate "DefaultLiveUpdateSchedule" 1 0 Hourly 0:00　"All Products" -quiet

3. パスワードの入力を求められたら、管理者アカウントのパスワードを入力する。

※ コマンドの例の Hourly 次の 0:00 は、LiveUpdate が実行される時刻を示します。この例では毎時 00 分に LiveUpdate が実行される設定となりますが、毎時 23分に実行させたい場合は 0:23 というように、分 の部分を任意の分に置き換えてコマンドを実行してください。

なお、Mac OS X 10.5 以降の OS では、ブランク (空白) のパスワードがターミナルで受け付けられないように仕様が変更されております。
この変更は OS 側の実装の変更によるものとなりますが、もしパスワードを未設定の場合には、あらかじめアカウントにパスワードを設定したうえでの作業を実施いただきますようお願い申し上げます。


b) LiveUpdate スケジュールを削除する。
Symantec Endpoint Protection for Macintosh (SEP for Mac) クライアントのインストール後、自動的に作成される LiveUpdate スケジュールにつきましては、以下の方法で削除することができます。

1. ターミナルを起動する。
2. 以下のコマンドを実行する。

$ sudo symsched -d all

3. パスワードの入力を求められたら、管理者アカウントのパスワードを入力する。

上記の操作で、SEP for Mac のインストールによって自動的に作成されたデフォルトの LiveUpdate のスケジュールが削除されます。
ただし、この方法を使用した場合、他に LiveUpdate のスケジュールが存在しない場合には、自動的にウイルス定義ファイルなどの更新ファイルを取得できなくなります。
必要に応じて、Symantec Scheduler を使用して LiveUpdate による製品の更新スケジュールの作成を行い、最新の更新ファイルを取得できるように設定を行ってくだ
さい。