Subnet FAQ about the use of network
Where should I send questions about the use of the network?
Destination to submit technical questions/requests about the use of the network | supports@imc.tut.ac.jp |
Destination to submit clerical applications about the use of the network |
Please send your questions from an email address of tut.ac.jp or tut.jp domain.
Since answers may contain information that cannot be disclosed to people other than members of TUT, we cannot answer questions from email addresses outside the TUT domain (tut.ac.jp or subdomains of tut.jp). We request you to send emails from an email address of the TUT domain.
Questions about a DNS server
What is an open resolver?
The DNS cache server provides a function to search an IP address corresponding to a host name (name resolution function). Usually, a DNS cache server installed in a domain has only to answer queries from clients that belong to the domain.
An open resolver is a DNS server that accepts name resolution queries from anywhere on the Internet because the DNS cache server is configured incorrectly.
What possible problems are caused by an open resolver?
- It is vulnerable to a DNS cache poisoning attack.
-
It can be used as a base for attacks against external servers (DNS Amp).
How can I confirm that my DNS server is not an open resolver?
Check at the following site.
What is a DNS cache poisoning attack?
A DNS has a function to temporarily memorize information, such as IP addresses and authoritative DNS servers, that are obtained through queries and reuse the information in name resolution to optimize the efficiency. This function is called the DNS cache function and provided in many DNS servers. The cache function plays an important role in reducing the load of a DNS and the network because it significantly reduces the number of queries to a DNS server.
A DNS cache poisoning attack abuses this function and makes a DNS server memorize false data in cache to gain control over a domain name or attempt phishing.
For more detail information, see http://www.ipa.go.jp/security/vuln/DNS_security.html, etc.
What occurs when a DNS cache poisoning attack takes place?
For example, let’s consider you are browsing http://www.tut.ac.jp/ using a browser running on the PC on your desk. Suddenly, the browser (and the OS of the PC) behaves as follows.
- The browser asks for the IP address corresponding to the host name www.tut.ac.jp to the nearest DNS server.
- The nearest DNS server searches for the IP address in the following procedure and replies.
- Search cache of the DNS server. When the IP address of www.tut.ac.jp already exists in the cache, the DNS server replies with the IP address.
- When the IP address does not exist in the cache, the DNS server for asks the IP address of www.tut.ac.jp from the authoritative DNS server (server.tut.ac.jp) of the domain that www.tut.ac.jp belongs to (tut.ac.jp). The DNS server stores the result (133.15.181.85) in cache and replies.
- Using the obtained IP address, the browser starts real communication and downloads the contents of web pages, etc.
When the cache of a DNS is poisoned, the false information that the IP address of www.tut.ac.jp is aaa.bbb.ccc.ddd is written in the cache. Accordingly, although a user tries to access http://www.tut.ac.jp/, the user actually connects to a completely different site.
A known method of abusing this function is to create a phishing site having almost the same appearance as the Yahoo! Auction site and stealing credit card or bank account information of users who believe they are accessing the Yahoo! Auction site.
I heard that the probability of a successful DNS cache poisoning attack is very low, and thus it does not pose a big threat.
This is old information. The Kaminsky’s Attack method, which was discovered in July, 2008, enables such attacks to succeed with a remarkably high success rate compared to traditional methods. It was reported that the cache of a DNS server on which no measures are implemented can be successfully poisoned within 10 minutes. Attacking tools have already been spread.
How can I check if any measures against a DNS cache poisoning attack have been taken?
First, please check at https://www.dns-oarc.net/oarc/services/dnsentropy.
To check any DNS server, execute the following command.
Check items | Command example |
Port numbers used for sending a DNS query are randomized. | dig @<IP address of the DNS server you want to search> +short porttest.dns-oarc.net TXT |
ID used for DNS query is randomized. | dig @<IP address of the DNS server you want to search> +short txidtest.dns-oarc.net TXT |
What measures should I take?
There are two measures.
-
Moving a DNS server to a hosting service for which measures have already been implemented.
- Improving the operating DNS server.
Detailed steps of the latter measure are as follows.
- Apply the latest hot fixes to the DNS server.
-
For where to obtain a hot fix, see http://www.jpcert.or.jp/at/2008/at080014.txt or the website of vendors.
-
- Review the contents of the configuration file.
Example of BIND 9 configurations
For BIND 9, the following configuration policy is recommended.
- Configure the general default behavior to deny queries or recursive queries.
- Allow the server to accept queries only from the master zone of the DNS server.
The following is a detailed configuration example.
// 自分のドメインの属するネットワークを指定して下さい. 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; }; };
Configuration example for Windows Server 2003
- In case of a contents server
- Make sure that recursive queries are disabled.
- In case of a contents server that also works as a cache server
- Since a Windows DNS server can be configured only to accept or deny recursive queries (it has no access permission function like BIND), a cache server and a contents server should separately run on different machines.
- In case of a cache server
- By using a packet filtering function such as a firewall, it should be configured to accept recursive queries only from its own domain.
For details, see http://www.ipa.go.jp/security/vuln/documents/DNS_security.pdf.
Questions about a mail server
What is a backscatter mail attack?
Spam mail distributors or viruses send a massive amount of emails from spoofed source addresses to email addresses automatically generated using dictionaries, etc. A typical example is as follows.
From: 存在しない送信者アドレス <not-existent-sender@example.imc.tut.ac.jp> To: 機械的に生成された受信者アドレス <automatic-generated-recipient@example.imc.tut.ac.jp> Subject: 誰でも儲かる方法 そんな方法はあるわけないのにね.
Mail servers to which no measures against backscatter mail attacks are implemented behave responding to the above-mentioned emails in the following manner.
- When the server receives an email, it writes the email to a disk (a mail spool) on the server.
- Since no recipient address exists, the server fails to deliver the email.
- The server tries to return the email to notify delivery failure to the source address.
In the above behavior, the email to notify delivery failure in the third process is called a backscatter mail.
What problems are caused by a backscatter mail attack?
There are two problems.
The first problem is that a massive amount of backscatter mails waste CPU processing time, disk, and the network bandwidth of the mail server. For example, a mail server in the university sent 20 backscatter mails every minute (about 30,000 backscatter mails per day!).
The second problem is that a mail server to which no measures for backscatter mail attacks are implemented is often incorrectly recognized as a mail server for which no anti-spam measures are taken. In the above example, not-existent-sender@example.imc.tut.ac.jp is used as an example of a non-existing sender address. However, in real spam mails, free mail domains, such as yahoo.co.jp and gmail.com, are frequently used as the sender’s addresses. Thus, yahoo.co.jp and other free mail servers receive a massive amount of backscatter mails from a mail server to which no measures against backscatter mail attack are implemented. Furthermore, backscatter mails are mails having unknown destinations for mail servers like yahoo.co.jp. Thus, for mail servers like yahoo.co.jp, mail servers to which no measures against backscatter mail attacks are implemented appears to be sending a massive amount of mails having unknown destinations, in other words, spam. Accordingly, mail servers like yahoo.co.jp incorrectly recognize correct emails sent from mail servers to which no measures against backscatter mails are implemented as spam.
How can I prevent backscatter mails from being sent?
Measures vary depending on whether it is the primary mail server that receives emails or a secondary mail server that temporarily stores emails while the primary mail server is unavailable.
First, there are two measures for primary mails servers.
-
Use a mail server of a hosting service to which measures are implemented.
- Configure a mail server not to receive emails to non-existing recipient addresses.
The following illustrates the latter measure “Configure a mail server not to receive emails to non-existing recipient addresses.”
Mail servers to which no measures against backscatter mail attacks are implemented behave as follows:
- Starts network connection from the source mail server.
- Receives an email.
- Writes an email to the disk for temporary storage (mail spool).
- Disconnects the network connection from the source mail server.
- Checks the mail recipient address and writes the mail in a destination personal mail box.
- In case no recipient address exists, detects a delivery failure error and sends a backscatter mail.
On the other hand, mail servers that check recipient addresses in the previous stage (servers to which measures against backscatter mail attacks are implemented), instead of writing the email to the disk for temporary storage (mail spool), behave as follows.
- Starts the network connection from the source mail server.
- Receives an email.
- Checks if the recipient address of the email exits.
- When the recipient address exists, writes the mail to the disk for temporary storage (mail spool).
- When no recipient address exists, the mail server notifies the source mail address that the email is denied because of an unknown recipient address to the source mail server.
- Disconnect the network connection from the source mail server.
- Checks the recipient address of the mail and writes the mail in the destination personal mail box.
- Since the address was already checked, the email should cause a delivery failure error.
When Postfix is used as a mail server, the above measures should be taken by default. Just to make sure
postconf smtpd_reject_unlisted_recipient
execute the command and check if it returns “yes.” In case the option “smtpd_reject_unlisted_recipient” does not exist, the Postfix is too old. Please update.
When qmail is used as a mail server, no measures against backscatter mail attacks are taken by default. In addition, qmail cannot be configured to check the existence of a recipient address while connecting the network as above due to the limitation of the program structure. (It is necessary to re-create the qmail itself.) As shown in http://spam.h1r.org/qmail/badlocal.html, configure the mail server not to return a delivery failure email for emails sent to locally non-existing email address. Since little maintenance is made for the qmail, it is necessary to apply several patches to use the qmail easily as a modern mail server. At least, it is not recommended for an administrator beginner to implement qmail depending on only the reputation that qmail is highly secure.
When sendmail is used as a mail server, no measures against backscatter mail attacks are taken by default. Take proper measures.
In case of a secondary mail server, it is necessary to configure the server to periodically copy the list of existing recipient addresses stored on the primary mail server to the secondary mail server in some way and deny emails sent to non-existing recipient addresses. Since the detailed steps depend on the implementation of each site, it can hardly be explained here. For example, a mail server of the hosting service the center operates takes measures to store the list of recipient addresses on the LDAP server so that the primary mail server and secondary mail server can always reference the same list of recipient addresses.
When you do not have sufficient staff and skills to implement measures, it is recommended to use a mail server that the hosting service provides.
Questions about a web server
What is the vulnerability of PHP CGI?
The vulnerability enables the execution of any scripts remotely by specifying an option of PHP as a command argument for CGI PHP. For details, see the explanation in http://blog.tokumaru.org/2012/05/php-cgi-remote-scripting-cve-2012-1823.html.
An attack targeting the vulnerability of CGI PHP took place in the university, causing a system failure that blocked the connection between inside and outside the university for 5 hours.
How can I investigate attacks targeting the vulnerability of PHP CGI?
When this vulnerability is attacked, there should be an access record that contains a special string “php://input” or a URL encoded string of this special string “%70%68%70%3A%2F%2F%69%6E%70%75%74.” You can find if the vulnerability was attacked by searching for the access records and extracting the accesses to which successful status 200 was returned. The investigation target and period are as follows.
- Strings to be searched for
- php://input
%70%68%70%3A%2F%2F%69%6E%70%75%74 ← (URL encoded string of “php://input”)
- Period for investigation
- At least access records from Thursday, October 31, 2013 (if possible, all stored access records)
- Directory and file of access records (logs) (by default)
For RedHat-based OS (CentOS, etc.)
- Directory of access records (logs): /var/log/httpd
- File name of access records (logs): access_log, access_log.1.gz, access_log.2.gz
- For Debian-based OS (Ubuntu, etc.)
- Directory of access records (logs): /var/log/apache2
- File name of access records (logs): access.log, access.log.1, access.log.2.gz
- For Windows OS IIS 6 to 7.5
Directory of access records (logs): C:\inetpub\logs\LogFiles\W3SVC1
- File name of access records (logs): u_exYYYYMMDD.txt (“YYYYMMDD” stands for the date)
Investigate in the following procedure.
RedHat-based OS (CentOS, etc.)
- Move to the directory of the access records (logs).
# cd /var/log/httpd
- Search for access records indicating a successful attack.
# (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 "
- Move to the directory of the access records (logs).
- Debian-based OS (Ubuntu, etc.)
- Move to the directory of the access records (logs).
# cd /var/log/apache2
- Search for access records indicating a successful attack.
# (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 "
- Move to the directory of the access records (logs).
- Windows OS IIS 6 to 7.5
- Start Command Prompt.
- Move to the directory of the access records (logs).
> cd C:\inetpub\logs\LogFiles\W3SVC1
- Search for the access records indicating a successful attack.
> 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 "
My server has been attacked! What should I do?
Follow the description in https://imc.tut.ac.jp/en/security/incident.html and contact the Information and Media Center.
Unplug the network cable. Do not turn off the machine as an investigation is necessary.
Questions about an SSH server
How can I install an SSH server that can be used from outside the university?
Submit an application form for a server installation described in https://imc.tut.ac.jp/en/subnet/form.html.
Recently, the incidence of brute force attacks targeting SSH servers has significantly increased. For example, the server of the Information and Media Center is subject to attacks from 5 to 10 locations a day. (Since an attack from 1 location consists of login attempts with approximately several hundred passwords, attacks occur several thousand times per day.) Thus, take the following measures.
(Essential) Prohibit login with root. Add the following description in /etc/ssh/sshd_config.
PermitRootLogin no
- Prohibit login with a password, or install software to detect brute force attacks and automatically deny login.
To prohibit login with a password, add the following entry in /etc/ssh/sshd_config.
ChallengeResponseAuthentication no PasswordAuthentication no
- Software such as “Denyhosts” and “pam-shield” are effective to detect brute force attacks and automatically deny login.
How can I install DenyHosts?
To install denyhosts to RedHat or CentOS, the easiest way is to obtain the software from the EPEL repository.
- Download the epel-release package from one of the following links.
RedHat 7 64-bit edition: http://download.fedoraproject.org/pub/epel/7/x86_64/repoview/epel-release.html
RedHat 7 32-bit edition: http://download.fedoraproject.org/pub/epel/7/i386/repoview/epel-release.html
RedHat 6 64-bit edition: http://download.fedoraproject.org/pub/epel/6/x86_64/repoview/epel-release.html
RedHat 6 32-bit edition: http://download.fedoraproject.org/pub/epel/6/i386/repoview/epel-release.html
RedHat 5 64-bit edition: http://download.fedoraproject.org/pub/epel/5/x86_64/repoview/epel-release.html
RedHat 5 32-bit edition: http://download.fedoraproject.org/pub/epel/5/i386/repoview/epel-release.html
Execute the following command and install the epel-release package. Replace “XY” with the name of the downloaded epel-release package.
rpm -ivh epel-release-X-Y.noarch.rpm
Execute the following command to install the denyhosts package.
yum install denyhosts
To install the denyhosts to Debian or Ubuntu, execute the following command.
apt-get install denyhosts
Troubleshooting
Measures against virus infection via USB memory
When a virus-infected USB memory is inserted in the computer, the computer may be infected by virus depending on the configuration, and, when a USB memory is inserted in the infected computer, the USB memory is infected by virus through an automatic execution file “autorun.inf” that the computer creates, thereby spreading USB worms. It can download other viruses from the Internet, which infect the computer. Measures against virus infection via USB memory include:
- Do not connect a USB memory from an unknown source, such as a USB memory that someone left or from outside the university.
- Do not insert a USB memory to a computer to which anti-virus measures have not implemented.
- Configure not to automatically run a program when a USB memory is inserted to a computer. (Disable Autorun function).
- If Autorun starts by inserting a USB memory in the computer, keep pressing the Shift key for some time to stop Autorun.
- Before opening a file from a USB memory, run a virus scan of the USB memory.
-
Use a virus scanned/secure USB memory with hardware encryption (provided by IO-DATA, etc.).
For details, see articles on USB memory on the Trend Micro’s website. See the attached “Measures against malicious programs that infect via USB memory, etc.,” by the Policy Division, Minister's secretariat, Ministry of Education, Culture, Sports, Science and Technology. (sankou-USB.pdf)
Does Symantec Endpoint Protection (SEP) have a command to delete viruses in the USB memory manually?
Like a command for deleting normal files, viruses can be deleted by executing the following command.
- del <drive>: \<file name> /p
Does SEP provide measures for viruses that revive after being detected or deleted by a normal system?
- Execute a full scan with the latest definition file.
- If any suspicious files are found, delete them.
- If such files are restored after being deleted, check if there is any applicable information at the following link.
Information on the virus definition update of Symantec Endpoint Protection for Mac VirusDefs
-
Although the frequency of LiveUpdate is manually configured, confirmation of update by LiveUpdate automatically occurs.
- It occurs several time a day in addition to the regular scan configured by the scheduler.
- Download of a relatively large update file (from tens to a hundred and tens MB) starts when the computer is started and regularly.
- Overview window appears after the update. As far as you check on the screen, all products are updated to the latest edition. (See the attached picture.)
- In addition, some types of Mac,an error message “LiveUpdate had an error updating the virus definitions.” appears.
(Answer)
When SEP for Mac is installed as unmanaged software, a LiveUpdate schedule is automatically set to check for updates every hour. Since the option of hide the progress status is disabled for this LiveUpdate schedule, a window showing the result of the LiveUpdate is displayed on a regular schedule. The progress status of the automatically executed LiveUpdate can be hidden by one of following operations: a) Hide the LiveUpdate that is executed on a regular schedule. b) Delete the LiveUpdate schedule. For details of each operation, see below. a) Hide the LiveUpdate that is executed on a regular schedule. To execute the schedule of SEP for a Mac client that was installed as unmanaged software while hiding the schedule, the schedule setting can be changed. Below shows an example of a command to change the schedule to execute a LiveUpdate silently. 1. Start the terminal. 2. Execute the following command: $ sudo symsched -f LiveUpdate "DefaultLiveUpdateSchedule" 1 0 Hourly 0:00 "All Products" -quiet 3. When a password is requested, enter the password for the administrator account. * A value of “0:00” next to “Hourly” in the command example indicates the time needed to execute the LiveUpdate. In this example, the LiveUpdate is configured to be executed on the hour every hour. To execute the command every hour 23 minutes after the hour, replace the minutes value with the required value (in this case, “0:23”) and execute the command. Additionally, a change was made to Mac OS X 10.5 or later releases to reject a blank password on the terminal. The change is due to a change of implementation on the OS side. If no password is set, set the password before the operation. b) Delete the LiveUpdate schedule The LiveUpdate schedule automatically created after the installation of Symantec Endpoint Protection for Macintosh (SEP for Mac) client can be deleted by the following procedure: 1. Start the terminal. 2. Execute the following command. $ sudo symsched -d all 3. When a password is requested, enter the password for administrator account. The above operation deletes the default LiveUpdate schedule that is automatically created by the installation of SEP for Mac. However, when you delete the default schedule, update files including virus pattern files cannot be automatically obtained if no other LiveUpdate schedule exists. Use Symantec Scheduler, create a schedule to update products by LiveUpdate, and configure it to obtain the latest update files.