Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Your Excludsing a trusted Web domain from Scans document is incorrect

Created: 20 Feb 2013 | 7 comments

SEP RU2. Policies, Exceptions policies.

The document at http://www.symantec.com/business/support/index?page=content&id=HOWTO80926#v39871582
states that:  You must specify an HTTP or HTTPS URL or an IP address when you specify a trusted Web domain exception.
Actually, you can't specify HTTP or HTTPS. All you can enter is the string AFTER the HTTP or HTTPS part, so you can't tell it to exclude HTTPS://www.mydomain.com  for example but NOT exclude HTTP://www.mydomain.com  It sees them as exactly the same because you are excluding a domain name only, not a URL, not a path, and not a secure domain vs. non-secure. So if you trust the secure portion of a domain, but not the unsecured part, tough luck.  You exclude domain name only, all or none.
I feel this needs clarification - or even to allow the ability to choose which PART or side of a domain.
>>In the Add Trusted Web Domain Exception dialog box, enter the HTTP or HTTPS Web site............<<
And just how do you specify if it's HTTP or HTTPS? And what if you want to exclude one but not the other? You can't, it's impossible.

What about the Edit button for the other exclusions, file, etc.? be careful as once in there, it's NOT editable, you have to delete it and start again if you make a mistake in choosing WHAT to exclude from. *Editing is not possible.*

And finally, see my other post regarding our inability to exclude a web domain and allow any files from that web domain to be downloaded without blocking or scanning. It don't work. In fact, SEP states, after it blocks the file, that the domain is unknown. So every time the site updates their plugin file, SEP blocks it.
SEP also doesn't allow us to exlude the file from scanning unless we give a very specific FILE NAME and PATH. That's also impossible since file names change, and the path is a user's web cache area - which has multiple folders with changing names. The exclusion here won't allow any wildcards or variables.
VERY inflexable. Very unconfigurable. But in our case, it doesn't even work.

Comments 7 CommentsJump to latest comment

Rafeeq's picture

when you decide to exclude it does not matter if its http or https coz at the end it willl resolve to IP

SebastianZ's picture

According to the oficial documentation HTTPS and FTP would be not supported in Trusted Web domain Exceptions:

Excluding a trusted Web domain from scans
http://www.symantec.com/docs/HOWTO55211

How to exclude specific Web domains from the Download Insight verification in SEP 12.1?
http://www.symantec.com/docs/TECH162264

ShadowsPapa's picture

But your official documentation states that it DOES by virtue of THIS statement:

 You must specify an HTTP or HTTPS URL or an IP address when you specify a trusted Web domain exception.
This implies support for HTTPS. IT also implies "OR" meaning you can specify which it is.
I am guessing that the writers of these tech docs don't have U.S. English as a primary language and thus a lot is lost in translation. some things simply don't translate well "all your bases are belong to us"  laugh

I understand about resolving to IP address - it's how the "browser finds things", however, what about hosts like GoDaddy which allows anyone and their uncles hacker son to host on their servers, - some of which host hundreds of "sites" or domains on a single server all resolving to the same IP address.

Their servers are the most blocked in our firewall simply because they have no rules regarding keeping sites clean -  sites hosted there are very often malware sites, or have been hit by drive-by because GoDaddy doesn't keep things secured very well......... so if I want to trust a single domain, HTTPS, on one of their servers.................. (actually we won't trust anything on those servers, it's just an example)

Interesting - the offical documents state there's no support for HTTPS and yet they state to 'enter an HTTP or HTTPS' domain. Rather confusing, isn't it? I think so as it implies support.

The document I posted the link to clearly states to enter the HTTP or HTTPS url, but HTTPS is not supported nor can you enter or specify it, and SEP still blocks downloads from sites in the exclusion in any case.

The documents need to state:
"Enter the URL or IP address for the DOMAIN you wish to exclude" and not "Specify an HTTP or HTTPS URL.
It should read: "Enter the URL or IP address of the domain you wish to exclude. Symantec does not support HTTPS or FTP exclusions at this time"
Isn't that a lot more clear and a lot more accurate or correct than "Enter the HTTP or HTTPS url" when HTTPS isn't supported?

In any case, it doesn't really work anyway, I've got the bluejeans.com domain entered and SEP blocks downloads from there based on reputation (but it also states heuristics were used, which is a contradiction as well since the Insight doesn't use heuristics at all, but strictly trust and reputation)

Just not having good luck at all with exclusions or settings or rules this month - it's ignoring things, and the documentation is of very little help, not written by people who have actually used or touched the product it would seem.  I like the products, but I've never been a fan of the documentation.

sandra.g's picture

I am guessing that the writers of these tech docs don't have U.S. English as a primary language and thus a lot is lost in translation.

Actually, the SEP InfoDev team of writers (which are typically responsible for HOWTO content, which is in turn usually sourced from the product documentation--as this article is) is all US-based. However, sometimes technical inaccuracies slip through the technical review. There are also technical writing constraints by which we are required to write, in order to ensure that translation to other languages goes more smoothly (and accurately).

I can pass along the feedback regarding HTTPS and exclusions.

sandra

Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!

ShadowsPapa's picture

Thanks Sandra - you hit on one reason the documetation is often either lacking, or difficult to understand - you can't restrict something written in English for the fear it won't translate well to another language. In doing so, you must then leave certain things out or not use common phrases and you end up with second-best English documents.

Instead of translating, they should be re-written by someone who's first language is the language you are wishing to target.

I've a bit of experience in translations that don't work well with my son and my daughter-in-law (his Korean wife). My son went to Korea to teach English to Korean children He met his now-wife while there. She taught English at the same university. She sometimes has difficulty translating things from Korean to English because some things simply don't translate well, however, my son can take the same thing and explain it beautifully in English. He doesn't translate per se, but he explains it in his words, starting from scratch.  (We're glad his wife is so nice and good-natured as her attempts to explain things to us in English, or translate her thoughts can lead to some really funny times. )
 
Here's an example of what I'm trying to say - use ANY of the on-line translation tools. Pick an English phrase, translate it, copy the translation and paste it back in and translate it back to English. Many times the meaning will be skewed, or it will make very little sense. 

Hope no one takes this wrong, but to me the methods used sort of remind me of our government - instead of helping to make others succeed and shine, we hold back those who already excel and succeed to make things more even. Instead of improving the documentation so it's complete and very understandable in English, it is held back to make it translate well to other languages. This causes the English version to be lacking. It's often unusable by U.S. customers, in my opinion. I rarely open the books because I've yet to find useful answers in it. Example - I wanted to know if one could use more than one "condition" in a custom IPS signature. There's nothing anywhere in the documents that explains how, and the online help doesn't touch it. It took someone who has done it to explain. I can come up with at least 6 examples without trying - very very basic stuff, but not covered. Instead it's "about  this" and "About that". No examples. The documents should have said "you can use multiple conditions in custom IPS signatures" and given a very basic example. Often the help screens simply restate what we already see. "here you can choose from any of these four options" then it lists the options. What does each option REALLY do, and what are the implications of each? We don't know.
We're not engineers or developers, we're end-users, customers, often tossed into the fire when someone else leaves, or the "company" hands us a product and says "here, make it work".
 

(My history with Symantec and the Symantec products goes back to about 1992 or 1993, NAV 2.0, a friend and I co-wrote some stuff to help manage the products, and some of it was even posted on the Symantec CompuServe area.  )

I see in the second message another problem or issue - can't specifiy a port for FTP - that's not very good. We use SFTP a lot because of our government's SSA (Social Security Administration) requirements. We can't transmit confidential client information over unsecured methods, can't FTP it, can't email it, can't send it via HTTP. It's got to be SFTP. Not even FTPS, or FTP over SSL, but has to be secure shell FTP/SFTP. This is over a different port than the standard. FTP port. There are also times that plain ordinary FTP uses a different port. Here we use the same IIS based FTP server for multiple FTP accounts or purposes. IIS insists each be on a different port.

I'm just trying to be helpful - I still believe in the product and company. Really, I've been using the products and supporting them in various ways for roughly 20 years, must be something there!

 

sandra.g's picture

Actually, it is unclear from the document "How to exclude specific Web domains from the Download Insight verification in SEP 12.1?" (last modified in 2011) that the also applies to 12.1 RU2 (which is from late 2012). It may not apply. The inline Help for the Trusted Web Domain Exception panel for RU2 says the following:

You specify an HTTP or HTTPS URL or an IP address when you specify a trusted Web domain exception. FTP URLs are not supported in the exceptions configuration. You must specify an IP address for an FTP location. You can only specify one domain at a time. You cannot specify a port number.

I'm making inquiries. smiley

sandra

Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!

sandra.g's picture

OK, I have received clarification on the following points:

  • You can enter either an HTTP- or HTTPS-prefixed URL, but the exception will apply to both HTTP and HTTPS versions of the URL. The 'or' means either prefix is acceptable, but as written, I can see how you might interpret that to mean you can exclude one protocol and not the other. I'm working on changes.
  • An FTP IP address is supported. (Waiting to hear whether this includes SFTP.)
  • HTTPS and FTP IP address support were added for 12.1 RU2.

I have updated the tech article referenced above. It may take a little time for the update to publish.

ShadowsPapa, I hear what you're saying, but manual translation/re-writing of all of our documents (for all products) just isn't feasible on so many levels. I've shared the URL of this thread with colleagues, though, in order to share your feedback--it is appreciated.

sandra

Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!