<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards">
    <title>gmane.comp.security.firewalls.wizards</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9094"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9093"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9092"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9091"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9090"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9089"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9088"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9087"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9086"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9085"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9084"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9083"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9082"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9081"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9080"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9079"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9078"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9077"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9076"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9075"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9094">
    <title>c0c0n 2012 - Call For Papers and Call For Workshops</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9094</link>
    <description>&lt;pre&gt;       ___        ___          ____   ___  _ ____
  ___ / _ \  ___ / _ \ _ __   |___ \ / _ \/ |___ \
 / __| | | |/ __| | | | '_ \    __) | | | | | __) |
| (__| |_| | (__| |_| | | | |  / __/| |_| | |/ __/
 \___|\___/ \___|\___/|_| |_| |_____|\___/|_|_____|
     ###################################################
c0c0n 2012 - Call For Papers and Call For Workshops
###################################################

August 2-4, 2012 - Cochin, India

Buenos días from the God’s Own Country!

We are extremely delighted to announce the Call for Papers and Call
for Workshops for c0c0n 2012 &amp;lt;http://www.is-ra.org/c0c0n/&amp;gt;, a 3-day
Security and Hacking Conference (1 day pre-conference workshop and 2
day conference), full of interesting presentations, talks and of
course filled with fun!

The conference topics are divided into four domains as follows:


We are expecting conference and workshop submissions on the following
topics, but are not limited to:


#####################
CFP Review Committee:
##################&lt;/pre&gt;</description>
    <dc:creator>Yashartha Chaturvedi</dc:creator>
    <dc:date>2012-03-18T14:23:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9093">
    <title>How MSRPC flow is handled? How to delete the flows after successful transfer of data</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9093</link>
    <description>&lt;pre&gt;Hi All,

I am trying to get details about MSRPC and its working. So far I have come
to know that when a Client requests for a particular service, first it
comes to End Point Mapper. Then in response to Map Request, the Port and IP
address are sent to client in Response's Tower id 4 and 5 respectively. Now
I have the port and IP address.  I simply connect to that service. Now
suppose I am firewalling it. Now if I allowed the MSRPC packets, then I
will create an embryonic flow for that connection, and then the firewall
will allow those packets.

Now my problem is how I will detect for how long I need to keep that flow
open? If the communication on that port has finished, then how should I
make sure that now its exited and I need to delete the flow ID? Can anyone
help me how should I go for this or how is this actually implemented??

Thanks and Regards
Rahul Sharma
_______________________________________________
firewall-wizards mailing list
firewall-wizards&amp;lt; at &amp;gt;listserv.icsalabs.com
https://listserv.icsalabs.com/m&lt;/pre&gt;</description>
    <dc:creator>rahul sharma</dc:creator>
    <dc:date>2012-02-17T14:36:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9092">
    <title>Ruxcon 2011 Final Call For Papers</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9092</link>
    <description>&lt;pre&gt;Ruxcon 2011 Final Call For Papers

The Ruxcon team is pleased to announce the final call for papers for the seventh annual Ruxcon conference.

This year the conference will take place over the weekend of 19th and 20th of November at the CQ Function Centre, Melbourne, Australia.

The deadline for submissions is the 15th of October.

* What is Ruxcon?

Ruxcon is the premier technical computer security conference in the Australia-Pacific region. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations.

The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.

Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.

For more information&lt;/pre&gt;</description>
    <dc:creator>cfp&lt; at &gt;ruxcon.org.au</dc:creator>
    <dc:date>2011-08-15T10:53:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9091">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9091</link>
    <description>&lt;pre&gt;

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


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.


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 plan&lt;/pre&gt;</description>
    <dc:creator>Paul D. Robertson</dc:creator>
    <dc:date>2011-08-13T04:07:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9090">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9090</link>
    <description>&lt;pre&gt;
Jean-Denis Gorin writes:


I saw a company that did that, years ago. They had all incoming mail go 
through
mimedefang and all URLs got converted to https:-URL pointing to their proxy
server, which required a login. They also had a whitelist ruleset in the 
rewrite,
so that some URLs didn't get rewritten on a case-by-case basis. Anything 
with
metacharacters or on a blacklist got rewritten to a warning. That was 
the first
layer.

The other thing they did was all attachments got stripped, and decoded and
stored in a queue area on their IMAP server, where it was accessible over
https: and the URLs to the attachment were injected back into the message.
So if you got a jpeg, you got
(jpg annakournikova.jpg is accessible here:
https://popserver.company.com/attachments/mjr/xfaa837-annakournikova.jpg )
instead of the inlined data. As you can imagine that was unpopular with some
people because there were then very good logs of who was accessing what
and when and why. The other thing they did that was extremely cut&lt;/pre&gt;</description>
    <dc:creator>Marcus Ranum</dc:creator>
    <dc:date>2011-08-12T20:52:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9089">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9089</link>
    <description>&lt;pre&gt;Thanks for the response.

 

1.       We block china but that doesnt stop mail being sourced from a
hacked American company

2.       We don't allow any webmail access from our site.  For business
reasons we are not allowed to block mail from anything but "freemail" sites
like gmail, hotmail etc.

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

 

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.
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 bu&lt;/pre&gt;</description>
    <dc:creator>Chris</dc:creator>
    <dc:date>2011-08-12T03:37:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9088">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9088</link>
    <description>&lt;pre&gt;----- Marcus Ranum &amp;lt;mjr&amp;lt; at &amp;gt;ranum.com&amp;gt; a écrit :

There might be a way *evil grin*
1- convert ALL incoming email to text/plain format (all those HTML formated emails from outside are bullshit: SPAM, commercials from vendors, invitations to shiny conferences, etc.)
2- substitute ALL URL with 'that link was removed for security reason [*]', with [*] stating: 'if access to that link is needed, please contact the sender of the message'

If that email was the vessel of an attack, the sender is fake. So no point trying to contact it.
If the sender is contacted, and resent the URL, the same filtering wil apply (it's evil, isn't it :) )

If you don't want the filtering to be as evil as described, you can amend the note like this: 'if access to that link is needed, please contact the sender of the message and'
Option 1: 'request him to send you that link address through another channel'
Option 2: 'request him to send you that link address embedded in a text file attachement'

The other way is to teach your users to NOT &lt;/pre&gt;</description>
    <dc:creator>Jean-Denis Gorin</dc:creator>
    <dc:date>2011-08-12T10:15:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9087">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9087</link>
    <description>&lt;pre&gt;Hi,

I'm using MailMarshal with blended threat module, which also protect against zero day exploit URL's.

Take a look at the PDF : http://www.m86security.com/documents/pdfs/datasheets/email_security/DS_Blended_Threats_Module.pdf

If you want some further information about this solution and how you can use this.. Send me an (direct) message.

Best regards,
Ilias
Send from my Blackberry

-----Original Message-----
From: Raphael Rivera &amp;lt;rafinous&amp;lt; at &amp;gt;yahoo.com&amp;gt;
Date: Thu, 11 Aug 2011 13:40:18 
To: &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com&amp;gt;; &amp;lt;firewall-wizards&amp;lt; at &amp;gt;listserv.icsalabs.com&amp;gt;
Subject: Re: [fw-wiz] Securing email by inhibiting urls

Chris,


Have you all tried barracuda spam firewall? 

Sent from my iPhone

On Aug 1, 2011, at 2:46 PM, "Chris" &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com &amp;lt;mailto:chughes&amp;lt; at &amp;gt;l8c.com&amp;gt; &amp;gt; wrote:





A company I work for has been having great difficulty in securing against email attacks.  So far we have disabled access to webmail, implemented  rules and processes to block freemail services like hotmail etc until the sender registers th&lt;/pre&gt;</description>
    <dc:creator>Ilias - </dc:creator>
    <dc:date>2011-08-11T17:39:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9086">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9086</link>
    <description>&lt;pre&gt;You are focusing on the wrong problem.  If desktops are being infected then
your desktop, anti-spam, and web browsing controls are all weak.
Eliminating "links" in e-mail is going to accomplish nothing.

A commercial web content filter for web browsing will go a long way to
resolving your issues.  Most commercial content filters are continuously
updated throughout the day and much can be filtered out via categories.   We
went from several desktop issues a day to one desktop issue a week after
implementing a commercial web proxy.  We then updated the browser and
implemented a new anti-virus solution.  The desktop environment has now gone
completely stable.  We've hadn't had a serious issue in months freeing up
our time to do other things.

You should also evaluate your desktop hardening and patching processes.

t.s

On Thu, Aug 11, 2011 at 6:37 AM, Chris &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>Timothy Shea</dc:creator>
    <dc:date>2011-08-11T22:20:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9085">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9085</link>
    <description>&lt;pre&gt;Cisco Ironport or McAfee's two offerings:  Email &amp;amp; Web Security Appliance or
Email Gateway.

The McAfee products used to be Secure Computing's Ironmail appliances, but
were bought with the Secure Computing acquisition.

Additionally, you should implement a true URL and content filtering service.
 Even if an email gets through here or there, clicking on the link in it
will do more or less nothing if you have a "good" content-filtering proxy.

At my last job, we implemented McAfee's Email Gateway which filtered out a
very high percentage of junk incoming--you have to turn it on and take a lot
of time configuring/tweaking it.  We also used Trend Micro's InterScan Web
Security product for web content filtering.  The Trend-Micro product is
based on Squid and some other open and non-open source products.  We didn't
want to take the time rolling our own Squid-based solution, and instead paid
for that one.  Ran both for a year+ without any known infections.

I do know that we had all of the popular safeguards turned&lt;/pre&gt;</description>
    <dc:creator>Victor Williams</dc:creator>
    <dc:date>2011-08-11T18:12:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9084">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9084</link>
    <description>&lt;pre&gt;
Stupid users, too much connectivity, good security - you can have
any two.

I'm guessing that when you say "trusted source" what you mean
is "apparently trustworthy source" - not that you actually have a
list somewhere of trusted sources. If you had a list of trusted
sources then you could put in a firewall that did URL filtering
then have 2 group policies: "users who click on bad URLs"
and "users who are careful what they click on" Only allow
"users who click on bad URLs" to go to the trusted destinations
and deny everything else.

But it sounds like you've got an impossible problem: you're
being asked to solve end-user trust with technology and still
maintain a fairly open network. That's not going to happen,
though surely you can thrash painfully about playing network
whac-a-mole.

mjr.

&lt;/pre&gt;</description>
    <dc:creator>Marcus Ranum</dc:creator>
    <dc:date>2011-08-11T22:11:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9083">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9083</link>
    <description>&lt;pre&gt;You need to re-think how you handle mail. Two things:


1.       Take out all Chinese IP addresses at the firewall. Nothing of value comes out of China. 99% of it is toxic. Why let them even have a chance?



2.       Direct webmail over the internet is dangerous at best. You need to set up an SMTP mail proxy on your system that receives, processes, and either accepts or rejects all incoming email. Use Sendmail + MailScanner + SpamAssassin + Clamav. Won't cost you a cent and will take all bad stuff out as you instruct it to do.


3.       Mail that makes it through the proxy should then be directed to the webmail server. It will be safe and clean.

From: firewall-wizards-bounces&amp;lt; at &amp;gt;listserv.cybertrust.com [mailto:firewall-wizards-bounces&amp;lt; at &amp;gt;listserv.cybertrust.com] On Behalf Of Chris
Sent: Monday, August 01, 2011 11:47 AM
To: firewall-wizards&amp;lt; at &amp;gt;listserv.cybertrust.com
Subject: [fw-wiz] Securing email by inhibiting urls

A company I work for has been having great difficulty in securing against email attacks.  So far &lt;/pre&gt;</description>
    <dc:creator>Mark E. Donaldson</dc:creator>
    <dc:date>2011-08-12T00:51:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9082">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9082</link>
    <description>&lt;pre&gt;Chris,

Have you all tried barracuda spam firewall? 

Sent from my iPhone

On Aug 1, 2011, at 2:46 PM, "Chris" &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com&amp;gt; wrote:

_______________________________________________
firewall-wizards mailing list
firewall-wizards&amp;lt; at &amp;gt;listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
&lt;/pre&gt;</description>
    <dc:creator>Raphael Rivera</dc:creator>
    <dc:date>2011-08-11T13:40:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9081">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9081</link>
    <description>&lt;pre&gt;I'll check out Ironport.  We looked at this earlier but there was something about it at the time that caused us to not buy it.  Time to revisit...

Thanks

-----Original Message-----
From: Kaas, David D [mailto:David_D_Kaas&amp;lt; at &amp;gt;RL.gov] 
Sent: Thursday, August 11, 2011 12:06 AM
To: 'chughes&amp;lt; at &amp;gt;l8c.com'; 'Firewall Wizards Security Mailing List'; 'firewall-wizards&amp;lt; at &amp;gt;listserv.cybertrust.com'
Subject: RE: [fw-wiz] Securing email by inhibiting urls

The ironport email appliane can do this.  You can strip HTML or modify URLs.  Outlook tries to be friendy bt atutomativally making www. Any.com clickable.



 -----Original Message-----
From: Chris [mailto:chughes&amp;lt; at &amp;gt;l8c.com]
Sent:Wednesday, August 10, 2011 08:46 PM Pacific Standard Time
To:firewall-wizards&amp;lt; at &amp;gt;listserv.cybertrust.com
Subject:[fw-wiz] Securing email by inhibiting urls

A company I work for has been having great difficulty in securing against email attacks.  So far we have disabled access to webmail, implemented  rules and processes to block freemail services like &lt;/pre&gt;</description>
    <dc:creator>Chris</dc:creator>
    <dc:date>2011-08-11T11:45:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9080">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9080</link>
    <description>&lt;pre&gt;Should have mentioned that this is a MS Exchange environment.  Spam filters are MS based currently MS based but that’s up for grabs if we can replace them with something that provides the same functionality in place now.  Currently using Brightmail and other than disabling/replacing urls in email it is working pretty good.

-----Original Message-----
From: Kurt Buff [mailto:kurt.buff&amp;lt; at &amp;gt;gmail.com] 
Sent: Thursday, August 11, 2011 1:32 AM
To: chughes&amp;lt; at &amp;gt;l8c.com; Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Securing email by inhibiting urls

mimedefang comes to mind.

http://mimedefang.org

On Mon, Aug 1, 2011 at 11:46, Chris &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com&amp;gt; wrote:

_______________________________________________
firewall-wizards mailing list
firewall-wizards&amp;lt; at &amp;gt;listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
&lt;/pre&gt;</description>
    <dc:creator>Chris</dc:creator>
    <dc:date>2011-08-11T11:41:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9079">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9079</link>
    <description>&lt;pre&gt;This wont work.  This site is under constant attack from China and randomly
hacked domains that are used as relays are not on any watch lists.  We are
talking zero day here.  There are no signatures for the payload if a user
clicks these links.  Right now user awareness is our best line of defense
and we all know how reliable that is.

Until I can disable a users ability to click a url in an email that appears
to come from a trusted source, I'm fighting constant infection.  We
regularly spot infections (read WE, not our security systems), that are
resident in our network and have been there days/weeks/months.  We currently
have at least one that we are watching to see what it is trying to do before
shutting it down....

-----Original Message-----
From: Mathew Want [mailto:imortl1&amp;lt; at &amp;gt;gmail.com] 
Sent: Thursday, August 11, 2011 1:19 AM
To: chughes&amp;lt; at &amp;gt;l8c.com; Firewall Wizards Security Mailing List
Subject: Re: [fw-wiz] Securing email by inhibiting urls

Perhaps it may be worth looking at it from the other angle.

If&lt;/pre&gt;</description>
    <dc:creator>Chris</dc:creator>
    <dc:date>2011-08-11T11:37:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9078">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9078</link>
    <description>&lt;pre&gt;Which is why I use a mail gateway for $WORK.

On Thu, Aug 11, 2011 at 04:41, Chris &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com&amp;gt; wrote:
_______________________________________________
firewall-wizards mailing list
firewall-wizards&amp;lt; at &amp;gt;listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
&lt;/pre&gt;</description>
    <dc:creator>Kurt Buff</dc:creator>
    <dc:date>2011-08-11T14:15:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9077">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9077</link>
    <description>&lt;pre&gt;mimedefang comes to mind.

http://mimedefang.org

On Mon, Aug 1, 2011 at 11:46, Chris &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com&amp;gt; wrote:
_______________________________________________
firewall-wizards mailing list
firewall-wizards&amp;lt; at &amp;gt;listserv.icsalabs.com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
&lt;/pre&gt;</description>
    <dc:creator>Kurt Buff</dc:creator>
    <dc:date>2011-08-11T05:31:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9076">
    <title>Re: Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9076</link>
    <description>&lt;pre&gt;Perhaps it may be worth looking at it from the other angle.

If you have URL's being accessed from your environment (from emails or
other sources) these can be channeled via a proxy on the client end.
You could then control the URL categorization and/or blocking via that
method. Many proxy services get updates of known bad domains and block
these automatically (similar to AV updates). This is not directly tied
to the mail system, but should give you an option to still control the
outbound requests to attack URL's.

Just a thought.
--
Regards,
Mathew Want

On 2 August 2011 04:46, Chris &amp;lt;chughes&amp;lt; at &amp;gt;l8c.com&amp;gt; wrote:



&lt;/pre&gt;</description>
    <dc:creator>Mathew Want</dc:creator>
    <dc:date>2011-08-11T05:18:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9075">
    <title>Securing email by inhibiting urls</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9075</link>
    <description>&lt;pre&gt;A company I work for has been having great difficulty in securing against
email attacks.  So far we have disabled access to webmail, implemented
rules and processes to block freemail services like hotmail etc until the
sender registers the address and of course a spam filter (BrightMail).
Attachment filtering is pretty strict as well.

 

The threat that presents the biggest challenge is url links in emails.  The
common method of attack is an email from somedomain.com where they change
one character or otherwise make the address look valid (ie:
joe&amp;lt; at &amp;gt;s0medomain.com or j0e&amp;lt; at &amp;gt;somedomain.com etc).

 

I was looking for a way to spot and block hyperlinks but it looks like the
only option I have is to filter on these and send them to a spam bin.  I'd
rather yank the offending hyperlink and replace it with a message of some
sort.  Unfortunately BrightMail doesn't offer that capability.

 

Any products that do this or ideas on a solution?

 

Thanks

_______________________________________________
firewall-wizards mai&lt;/pre&gt;</description>
    <dc:creator>Chris</dc:creator>
    <dc:date>2011-08-01T18:46:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9074">
    <title>Re: obscure email address formats</title>
    <link>http://permalink.gmane.org/gmane.comp.security.firewalls.wizards/9074</link>
    <description>&lt;pre&gt;
Depends on what you are trying to do...

     first.last&amp;lt; at &amp;gt;fqdn
     address%other.address&amp;lt; at &amp;gt;fqdn

and many other formats are potentially valid, however these should 
really be handled in a mail transfer agent such as Exim (www.exim.org)


Mike
&lt;/pre&gt;</description>
    <dc:creator>Michael J. Tubby B.Sc. MBCS G8TIC</dc:creator>
    <dc:date>2011-07-31T10:07:11</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.wizards">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.wizards</link>
  </textinput>
</rdf:RDF>

