Views:

Here are common questions about IWSaaS:

IWSaaS supports scanning of FTP file transfers conducted through a Web browser, for example, when the URL of an FTP site is specified in the Web browser's Address field. These transfers are scanned according to the preferences specified for HTTP Scanning, including the Actions and Notifications.

IWSaaS automatically logs all Internet-threat incidents, blocked or filtered URLs, mail deliveries, pattern file and other updates, and reports. Logs can be kept on the IWSaaS server, or posted to the IWSaaS database (for faster reporting, file management considerations, or to aggregate data for a multi-IWSaaS environment).

  • Application Control Log: appd.log.yyyymmdd.0001 (System Log) / appcontrol.log.yyyy.mm.dd.0001 (Reporting Log)
  • Audit Log: audit.trail.log
  • Cleanup Log
  • Database Import Tool Log: log_to_db.log.yyyymmdd.0001
  • FTP Log: ftp.log.yyyymmdd.0001
  • HA Agent Log: ha_agent.yyyy.mm.dd
  • HTTP Log: http.log.yyyymmdd.0001
  • Java Applet Scanning Log: jscan.log.yyyymmdd.0001
  • Mail Delivery Log: mail.log.yyyymmdd.0001
  • Performance Log: perf.log.yyyy.mm.dd Scheduled
  • Update Log: admin.log.yyyymmdd.0001
  • Spyware/Grayware log
  • System Event Log: systemevent.log.yyyy.mm.dd
  • Temporary Control Manager Log: CM.yyyymmdd.0001
  • URL Access Log: access.log.yyyy.mm.dd
  • URL Blocking/URL Filtering: url_blocking.log.yyyy.mm.dd
  • Update Log: update.log.yyyymmdd.0001
  • Virus Log: virus.log.yyyy.mm.dd
  • World Virus Tracking Center Log: logtowvts.log.yyyymmdd.0001

One of the most dangerous types of Internet threats is "phishing". Phishing is a rapidly growing threat wherein malicious hackers (and even organized criminals) send out millions of fraudulent email messages designed to fool users into submitting personal information on a bogus site. The criminals collect information such as credit card and social security numbers, bank accounts, and logon credentials.

New phish and other disease vectors appear often and can be very hard to identify (usually, the only thing bogus in the solicitation is the underlying URL a "friendly" hyperlink leads to. If you or your clients suspect a mail of being phish, we encourage you to submit the message (including the URL) to Trend Micro.

To send a suspicious email or URL to Trend Micro provide the following data:

  • Phish URL - Give the URL of the suspect site. The prefix http:// is assumed if not specified.
  • Phishing categories - Classify the type of threat you will submit: Phishing, Spyware, Virus accomplice, Disease vector, or Others.
  • Senders email address- Enter your email address or the address you want to appear in the message’s From: field. If you leave the Sender's email address field blank, the default email address specified in Notifications will be used.

IWSaaS gives certain policies priority over others. The order of precedence is as follows:

  • Approved
  • Blocked
  • URL filtering
  • WRS
  • Application control
  • Advanced threat (crimeware, malware, grayware)
  • Anti-Malware
  • HTTPS/SSL decryption

 

  • IWSaaS only applies the Application Control, URL Filtering, and Advanced Threat policies to HTTP requests.
  • If a URL is blocked by a policy, any policies that take precedence next will not be applied. If a URL is included in the Approved List, IWSaaS applies no policies to this URL.
  • If the HTTPS Decryption policy is disabled, IWSaaS tunnels all HTTPS traffic without applying the Application Control, URL Filtering, WRS, Advanced Threat, and Anti-Malware policies.
  • If an HTTPS URL is part of the Exception List of the HTTPS Decryption policy, IWSaaS tunnels this URL without applying the Application Control, URL Filtering, WRS, Advanced Threat, and Anti-Malware policies.
  • If the Application Control policy is matched, URL filtering policy would be skipped.
  • IWSaaS caches the WRS score of a URL. If a URL is blocked by the Anti-Malware policy, IWSaaS decrease the cached WRS score of the URL. Therefore, in the future this URL could be blocked by the WRS policy.

Roaming users and the HTTPS decryption policies 

When a roaming user (person accessing IWSaaS from outside of their designated zone) accesses an HTTPS-based website usingIWSaaS for the first time, the traffic is decrypted in order to authenticate the client. After client authentication, IWSaaS retrieves and applies the client’s policy.

  • If the HTTPS domain is in the URL Exception List (Administration > HTTPS/SSL Policies) or global Approved URLs list (Access Policies > Approved/Blocked), IWSaaS will not apply any policies (application control, URL filtering, WRS, Anti-Malware, Advanced Threat) to the client’s traffic.
  • If the HTTPS domain is on the blocked list, it will be blocked as expected.
  • If the HTTPS domain requests the client certificate, IWSaaS would block this request.

To avoid traffic decryption, the roaming user could access an HTTP website and then pass the authentication credentials to IWSaaS for validation.

The service uses IWSaaS IP addresses to connect to your Active Directory server. You can use this information to configure your firewall rules. It authenticates users and synchronizes user/group information using the cloud to connect directly (without an agent) to the on-premise Active Directory.

The IP addresses are available by logging into your IWSaaS web console. Go to Administration > Users & Authentication > Active Directory > Direct Method.

For more information about Static IP addresses, contact Trend Micro Technical Support.