Re: [fw-wiz] Securing email by inhibiting urls



On Thu, 11 Aug 2011, Chris wrote:

3. We have Brightmail, Juniper IDS, ISS IDS and Symantec Antivirus
protecting all mail servers.


The mail server isn't the target, the desktop is- that's where your
protection needs to be.

We don't have issues with executables etc in mail as attachments. We mostly
see encrypted .zip or Ms Excel/Word attachments in emails made to look like
they are coming from someone friendly. The well trained employee with a
short memory or bad recall clicks the attachment or url linked to a file and
game is over. These are zero day payloads that are not detected by anyone.

Which is it? Attachments, or links? Those are two different issues.
Seems to me like not letting encrypted attachments through would be a
good start. It also seems that not letting most MIME types through the
HTTP proxy would be a good second step. Exceptions on a by-domain basis
tend to take about a week to get cleared up if you do it during
end-of-month cycles.

We have spent lots of money getting them reverse engineered and the security
firms are impressed. We can block all attachments but that doesn't stop a
user clicking a link to a hacked ford.com page that delivers payload (making
this up but its not far from true). With business constraints etc, our best
option now is to strip/modify urls/links in emails but our current systems
don't have that feature.


The other option is to simply control what's run at the client. I've got
a customer with complete software restriction policies on that's had so
few malcode outbreaks in the last five years that I can think of three
that I had to respond to. Everything in %windir% is either a path or a
hash rule, as is everything in %programdir%. Nothing else is allowed to
run. DLL monitoring isn't on, as the performance hit isn't worth the few
times a decade a DLL injection may happen. The best thing is that things
that do get executed can't plant a Trojan, so most "infections" end up as
a zero sum game. Once you've got the bulk of the Windows and
vendor-specific rules in, maintenance is less than an addition a month.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
paul@xxxxxxxxxxxx which may have no basis whatsoever in fact."
Moderator: Firewall-Wizards mailing list
Art: http://www.PaulDRobertson.net/

_______________________________________________
firewall-wizards mailing list
firewall-wizards@xxxxxxxxxxxxxxxxxxxxx
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards



Relevant Pages

  • Re: Picture Insertion
    ... I'm still puzzled by the insertion process. ... photo that could be inserted. ... This is Comcast's statement on size of attachments. ... That's because any message you send goes through both our mail servers ...
    (microsoft.public.mac.office.entourage)
  • Re: Spam returned mail?
    ... Sounds as though a PC infected with a virus has your email address in the address book, and is spewing out either spam or virus infected emails claiming to come from you. ... Receiving mail servers should _not_ bounce these back to the "sender", as in these cases the sender's email address is almost always forged. ... As for the attachments, they could contain a copy of the original email, or they could be viruses. ...
    (microsoft.public.windows.inetexplorer.ie6.outlookexpress)
  • Re: best practice for latency in maildelivery
    ... having local mail servers. ... Limit the size of mail attachments and force them to use file shares ... Just be aware of the 2GB limit on OST file sizes. ...
    (microsoft.public.inetserver.iis.smtp_nntp)
  • RE: Send Link by email option
    ... Many mail servers (and mail clients) delete certain attachments to prevent client infection. ... > Don't just live life. ...
    (microsoft.public.windowsxp.general)