Web Proxy concepts for SmarterMail - Malicious Content prevention
Problem reported by Douglas Foster - Today at 6:45 AM
Submitted
This topic is based on unhappy experience with a single Web Proxy product connecting to multiple third-party applications other than SmarterMail.  I am hoping that someone else can contribute a happy experience with a successful product, so that all of use can apply that success to protecting SmarterMail.

Owasp.org has a publicly-available database with at least 10,000 tests that might indicate malicious action against a website.   My tested product was based around that database.    Tests were grouped into 11 categories that could be enabled or disabled at the group level.   For example, if your application does not use a SQL database, one click could disable all of the SQL-related tests.   Individual tests could also be enabled or disabled by their rule ID.   Some tests had immediate impact, while other tests contributed to a risk score.  Other rules were based on total risk score for a set of related tests.  Disabling a total-score test would have the effect of disabling all tests that contributed to that score.

For an internally-developed application, the assumption is that the Web Proxy configuration is designed along with the application.   For a turn-key third party application, configuring the Web Proxy became an exercise in futility.

Before deployment in monitor-only mode, various rules would fire.   Since I knew my testing sequence was non-malicious, I knew all of those rules needed to be disabled.   Some total score rules would also fire.  If I chose to disable one of those rules, the web proxy interface would warn me that doing so was strongly discouraged (since it disabled whatever complex of rules were supposed to contribute to that score.)   The big downside was that I never knew if I had tested the application with sufficient rigor to be certain that all false positives had been detected and corrected.

After deployment in monitor-only mode, more rules would fire.   At this point, I hoped that application usage was only by legitimate users, but had no way of knowing for sure.    Continuing to disable every rule that fired made the entire process lose credibility.

After activating enforcement mode, users would experience unexpected problems, causing enforcement to be disabled.

After a few rounds of this process, and others to be covered in the next topic, I gave up on content filtering.   As I said, all of these tests were performed on products other than SmarterMail.   I need to use a web proxy with SmarterMail to control entry points, but I don't know if I can do any better than that. 
John Quest Replied
Taking a couple steps back, and making it very clear that this is being posted as a company, not any sort of hosting provider, all of our servers and service are behind a H/A pair of firewalls that have a full featured security suite including GAV, IDS, Content filtering (although that is really for internal to external control) and a big one, DPI-SSL. That DPI-SSL is a true proxy function for certificate protected websites that we host (in our DMZ)

Now, going back about 20 years when I was a hosting provider (small time) all of my servers and hosted websites including hosted email (at that time Imail) were again behind a firewall. The difference back then was DPI-SSL is in its infancy. 

My point is this, with my 25+ years experience in Network Administration, it is my firm belief that NOTHING should be available to the internet unless it is behind a properly configured and maintained firewall.

Now, to be clear, would that have made any difference in what people experienced over the past couple of weeks with SmarterMail? I do not know. I(we) were in no way affected for one simple reason: Our email server/system is not publicly available (except of course for SMTP) by our internal policy. 

Reply to Thread

Enter the verification text