OT - Blocking ALL non-user clients - WAS Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-28 Thread Charles Marcus 

On 2013-10-27 1:13 PM, Charles Marcus  wrote:

Based on Noel's suggestion above I currently have:

# submission_clients_banned
linkedin.com REJECT Intro hijacker not welcome here
rapportive.com REJECT Intro hijacker not welcome here


Just added blackberry.net and rim.net, but I'm still very (extremely) 
curious about the most effective way to try (not saying anything can be 
perfect) to eliminate as much as possible the scraping of accounts by 
anything other than actual user devices...


So, I'm interested in ideas on how to block as many of the undesirables 
(social networks, freemailers, etc) as possible - but of course I know 
nothing is going to be 100% effective.


Obviously, blocking SMTP_AUTH is a much smaller part of this (blocking 
IMAP is the most critical, because that door allows access to ALL users 
stored mail, POP less so, because they can only get at mail trickling 
in, and only if they grab it before a POP client deletes it), but the 
methodology will be the same, and whatever I come up with to block 
SMTP_AUTH can be applied to blocking IMAP/POP_AUTH as well...


--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-27 Thread Charles Marcus 

On 2013-10-27 3:58 PM, Noel Jones  wrote:

(disclaimer - no BB users left here, so this is based on past
behavior. They could have changed, but I doubt it.)

Yes, BB would fetch all IMAP messages from the company server, then
push them to the client.

Outbound would originate from BB's SMTP servers, with a BB envelope
address and your company From: header (and bypassing any company
outbound policy in the process).

Doesn't seem like a big difference in outcome -- some third party
has access to all your mail. But they promise they won't misuse it.


Yeah... I only ever saw it grabbing *new* messages and pushing them to 
the client, and there was no way to browse the folder list, or older 
messages, or anything like that, but if their system has your username 
and password, then there is absolutely nothing preventing them from 
doing something devious behind the scenes.


Scary... now that I think about it more, I can't believe I ever actually 
set any of these up.


--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-27 Thread Noel Jones 
On 10/27/2013 10:38 AM, Charles Marcus wrote:
> On 2013-10-25 4:51 PM, Noel Jones  wrote:
>> Blackberry has done pretty much this same thing for years, and not
>> too many people have been bent out of shape about it. Or maybe the
>> different business model of BB convinced folks their email wasn't
>> being mined.  Mostly a moot point now...
> 
> Are you sure about this? I especially don't think this is true for
> outbound? At least, I don't recall seeing an option for this (SMTP)
> in the ones I set up, but it was a long time ago, so maybe I'm wrong
> and just never considered the implications...
> 
> It seemed to be more in the nature of setting up getmail or
> fetchmail, and it was for inbound only, and just to deliver the
> message to the client.

(disclaimer - no BB users left here, so this is based on past
behavior. They could have changed, but I doubt it.)

Yes, BB would fetch all IMAP messages from the company server, then
push them to the client.

Outbound would originate from BB's SMTP servers, with a BB envelope
address and your company From: header (and bypassing any company
outbound policy in the process).

Doesn't seem like a big difference in outcome -- some third party
has access to all your mail. But they promise they won't misuse it.



  -- Noel Jones

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-27 Thread Charles Marcus 

On 2013-10-27 1:13 PM, Charles Marcus  wrote:

Ok, first attempt isn't working properly...


Sorry - started that email before I fixed the 'bad address pattern' error...

Current hashed version seems to be working...

--

Best regards,

*/Charles/***

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-27 Thread Charles Marcus 

Ok, first attempt isn't working properly...

On 2013-10-25 3:21 PM, Noel Jones  wrote:

# banned_clients
linkedin.com  REJECT  mail from LinkedIn not welcome here


I have (changed cidr to hash for obvious - after I got the 'bad address 
pattern' error on first try with the cidr map - reasons):


main.cf
...
submission_client_restrictions =
  check_client_access ${hash}/submission_clients_banned,
  permit_sasl_authenticated,
  reject

master.cf
...
submission inet  n   -   n   -   -   smtpd
...
  -o smtpd_client_restrictions=$submission_client_restrictions
...

And now I'm working on the contents of submission_clients_banned

Based on Noel's suggestion above I currently have:

# submission_clients_banned
linkedin.com REJECT Intro hijacker not welcome here
rapportive.com REJECT Intro hijacker not welcome here

But this also got me wondering if I should be doing this by IP addresses 
instead - or even in addition to?


And then I started wondering if I should add all of the social networks 
and even large freemailers (like google/gmail/ etc)...


This could start getting ugly... 

--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-27 Thread Charles Marcus 

On 2013-10-25 4:51 PM, Noel Jones  wrote:

Blackberry has done pretty much this same thing for years, and not
too many people have been bent out of shape about it. Or maybe the
different business model of BB convinced folks their email wasn't
being mined.  Mostly a moot point now...


Are you sure about this? I especially don't think this is true for 
outbound? At least, I don't recall seeing an option for this (SMTP) in 
the ones I set up, but it was a long time ago, so maybe I'm wrong and 
just never considered the implications...


It seemed to be more in the nature of setting up getmail or fetchmail, 
and it was for inbound only, and just to deliver the message to the client.


Of course, in thinking about this now, they obviously could do whatever 
they wanted with the message between downloading it from our server and 
delivering it to the Blackberry... ouch...


--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Harald Koch 
On 25 October 2013 16:34, Charles Marcus  wrote:

>  Not according to this (from the second paragraph of the linked article):
>
> "Once you install the Intro app, all of your emails, both sent and
> received, are transmitted via LinkedIn’s servers. LinkedIn is forcing all
> your IMAP and SMTP data through their own servers and then analyzing and
> scraping your emails for data pertaining to…whatever they feel like."
>
>
My bad - I was foolishly reading LinkedIn's technical article, not the
original. What can I say - it's Friday...

-- 
Harald

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Noel Jones 
On 10/25/2013 3:34 PM, Charles Marcus wrote:
> On 2013-10-25 4:28 PM, Harald Koch  wrote:
>> On 25 October 2013 14:42, Charles
>> Marcus > > wrote:
>>
>> Whether it is iOS specific or not (apparently it is, at least
>> for the time being, iOS specific), it also applies to the smtp
>> connection to my *postfix* server, so I disagree that it is OT.
>>
>> Apparently it is not a hoax, so the question remains, for
>> those of us who do not have the enterprise tools to lock down
>> iPhones and iPads, what is the best/most reliable way to
>> simply block LinkedIn from being able to successfully connect
>> to the SMTP server?
>>
>>
>> According to the technical description, they're modifying your
>> inbound email as you fetch it from your IMAP server, not your
>> outbound email.
> 
> Not according to this (from the second paragraph of the linked article):
> 
> "Once you install the Intro app, all of your emails, both sent and
> received, are transmitted via LinkedIn’s servers. LinkedIn is
> forcing all your IMAP and SMTP data through their own servers and
> then analyzing and scraping your emails for data pertaining
> to…whatever they feel like."
> 
> BOTH IMAP and SMTP...
> 
> Maybe the article is wrong?
> 
> -- 
> 
> Best regards,
> 
> */Charles/*


The article appears to be correct.  They proxy your phone's IMAP for
incoming mail, and your phone's SMTP for outgoing mail.

The block in postfix prevents users from sending mail via the
linkedin proxy.

Blocking the IMAP proxy would need to be done in your IMAP software.

I suspect blocking the IMAP proxy would be sufficient to discourage
folks from using this; blocking only in postfix might not be as
noticeable (most folks seem to use mobile devices far more for
reading than sending). Of course, if your local policy determines
third-party proxying is unwanted, blocking both is best.

Blackberry has done pretty much this same thing for years, and not
too many people have been bent out of shape about it. Or maybe the
different business model of BB convinced folks their email wasn't
being mined.  Mostly a moot point now...



  -- Noel Jones

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Charles Marcus 

On 2013-10-25 4:28 PM, Harald Koch  wrote:
On 25 October 2013 14:42, Charles Marcus > wrote:


Whether it is iOS specific or not (apparently it is, at least for
the time being, iOS specific), it also applies to the smtp
connection to my *postfix* server, so I disagree that it is OT.

Apparently it is not a hoax, so the question remains, for those of
us who do not have the enterprise tools to lock down iPhones and
iPads, what is the best/most reliable way to simply block LinkedIn
from being able to successfully connect to the SMTP server?


According to the technical description, they're modifying your inbound 
email as you fetch it from your IMAP server, not your outbound email.


Not according to this (from the second paragraph of the linked article):

"Once you install the Intro app, all of your emails, both sent and 
received, are transmitted via LinkedIn's servers. LinkedIn is forcing 
all your IMAP and SMTP data through their own servers and then analyzing 
and scraping your emails for data pertaining to...whatever they feel like."


BOTH IMAP and SMTP...

Maybe the article is wrong?

--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Charles Marcus 

On 2013-10-25 4:17 PM, Viktor Dukhovni  wrote:

You've been on this list long enough to know that verbatim restriction
definitions don't belong in master.cf:

 master.cf:
submission inet n ... smtpd
-o smtpd_client_restrictions=$submission_client_restrictions

 main.cf:
submission_client_restrictions =
check_client_access ${cidr}/submission_clients.cidr,
permit_sasl_authenticated,
permit_mynetworks
reject


You're right of course... thanks for being so gentle with clue stick..


or in the relay_restrictions, ie:

[ smtpd_relay_restrictions = ]
check_client_access ${cidr}/blocked_clients.cidr,
permit_sasl_authenticated, permit_mynetworks,
reject_unauth_destination

This would block all mail from the clients in question, not just
submission.  Also you don't even want Linked machines that hijack
submission on port 25 sending mail that is not relay mail (inbound
to your organization).  So you really need to not use port 25 for
submission.


I don't (use port 25 for submission)... and am not sure what I was 
thinking there. Guess maybe I should lay off the afternoon coffee... ;)


Anyway, thanks as always for the most excellent support on this list.

--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Harald Koch 
On 25 October 2013 14:42, Charles Marcus  wrote:

> Whether it is iOS specific or not (apparently it is, at least for the time
> being, iOS specific), it also applies to the smtp connection to my
> *postfix* server, so I disagree that it is OT.
>
> Apparently it is not a hoax, so the question remains, for those of us who
> do not have the enterprise tools to lock down iPhones and iPads, what is
> the best/most reliable way to simply block LinkedIn from being able to
> successfully connect to the SMTP server?


According to the technical description, they're modifying your inbound
email as you fetch it from your IMAP server, not your outbound email.

Still disturbing, but arguably completely off-topic for postfix...

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Viktor Dukhovni 
On Fri, Oct 25, 2013 at 04:07:11PM -0400, Charles Marcus wrote:

> But should this check go directly on the submission service, ie:
> 
> submission inet  n   -   n   -   -   smtpd
> -o syslog_name=postfix-587 -o smtpd_tls_security_level=encrypt
> -o smtpd_tls_auth_only=yes
> -o 
> smtpd_client_restrictions=check_client_access,${cidr}/blocked_clients.cidr,permit_sasl_authenticated,reject
> 
> (Is that right? Use a comma instead of a space between
> check_client_access and the map?)

You've been on this list long enough to know that verbatim restriction
definitions don't belong in master.cf:

master.cf:
submission inet n ... smtpd
-o smtpd_client_restrictions=$submission_client_restrictions

main.cf:
submission_client_restrictions = 
check_client_access ${cidr}/submission_clients.cidr,
permit_sasl_authenticated,
permit_mynetworks
reject

> or in the relay_restrictions, ie:
> 
> [ smtpd_relay_restrictions = ]
>   check_client_access ${cidr}/blocked_clients.cidr,
>   permit_sasl_authenticated, permit_mynetworks,
>   reject_unauth_destination

This would block all mail from the clients in question, not just
submission.  Also you don't even want Linked machines that hijack
submission on port 25 sending mail that is not relay mail (inbound
to your organization).  So you really need to not use port 25 for
submission.

-- 
Viktor.

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Charles Marcus 

On 2013-10-25 3:41 PM, Viktor Dukhovni  wrote:

On Fri, Oct 25, 2013 at 02:21:11PM -0500, Noel Jones wrote:


1. block all *.linkedin.com clients BEFORE any
permit_sasl_authenticated statement.  This will also have the effect
of blocking all incoming linkedin mail. That may be a little too
strict for some folks, or maybe just fine with others.

If submission is on port 587, then one can block linked in there,
without blocking mail from linked-in.


Thanks Victor, I knew there had to be a way to do it only for submissions...

But should this check go directly on the submission service, ie:

submission inet  n   -   n   -   -   smtpd
-o syslog_name=postfix-587 -o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o 
smtpd_client_restrictions=check_client_access,${cidr}/blocked_clients.cidr,permit_sasl_authenticated,reject


(Is that right? Use a comma instead of a space between 
check_client_access and the map?)


or in the relay_restrictions, ie:

check_client_access ${cidr}/blocked_clients.cidr, 
permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination


Now the only question is, do their connections actually use 
*.linkedin.com hosts, or some other hosts... like maybe *.rapportive.com 
(supposedly this new service is based on the Rapportive service LinkedIn 
acquired last year.


Maybe I'll just block both for now to be sure...

Thanks again,

--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Manuel Bieling 
On 2013.10.25 14:21:11 -0500, Noel Jones wrote:
> > Apparently it is not a hoax, so the question remains, for those of
> > us who do not have the enterprise tools to lock down iPhones and
> > iPads, what is the best/most reliable way to simply block LinkedIn
> > from being able to successfully connect to the SMTP server?

[...]

> Basically two choices...
> 
> 1. block all *.linkedin.com clients BEFORE any
> permit_sasl_authenticated statement.  This will also have the effect
> of blocking all incoming linkedin mail. That may be a little too
> strict for some folks, or maybe just fine with others.
> 
> Something like:
> smtpd_client_restrictions =
>   check_client_access hash:/etc/postfix/banned_clients
> 
> # banned_clients
> linkedin.com  REJECT  mail from LinkedIn not welcome here

[...]

> (well, I suppose firewall their IP range is a third choice...  That
> suffers from the problem of reliably finding their IP range.)

4. Something like:
smtpd_client_restrictions =
check_client_access cidr:/etc/postfix/banned_clients

#!/bin/sh

for as in AS55163 AS40793 AS20366 \
AS20049 AS197613 AS197612 AS14413 AS132466
do
  whois -h whois.radb.net -- "-i origin ${as}" \
| grep ^route \
| awk '{print $2 "\t\tREJECT Deprecated"}' \
>> /etc/postfix/banned_clients
done

http://bgp.he.net/

-- 
Best regards,
Manuel

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Viktor Dukhovni 
On Fri, Oct 25, 2013 at 02:21:11PM -0500, Noel Jones wrote:

> 1. block all *.linkedin.com clients BEFORE any
> permit_sasl_authenticated statement.  This will also have the effect
> of blocking all incoming linkedin mail. That may be a little too
> strict for some folks, or maybe just fine with others.

If submission is on port 587, then one can block linked in there,
without blocking mail from linked-in.

-- 
Viktor.

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Bron Gondwana 
On Sat, Oct 26, 2013, at 06:21 AM, Noel Jones wrote:
> 1. block all *.linkedin.com clients BEFORE any
> permit_sasl_authenticated statement.  This will also have the effect
> of blocking all incoming linkedin mail. That may be a little too
> strict for some folks, or maybe just fine with others.
> 
> 2.  Use a policy service such as postfwd to reject connections if
> {SASL authentication and the client == linkedin}.  This will prevent
> anyone from sending mail via linkedin, but will still allow the
> usual unauthenticated incoming mail.
> 
> 
> (well, I suppose firewall their IP range is a third choice...  That
> suffers from the problem of reliably finding their IP range.)

Has anyone confirmed that their proxy IPs reverse resolve to *.linkedin.com?

Of course, we'll still wind up playing whack-a-mole if they decide to change 
them.  IP ranges are slightly harder to change, but still not impossible if 
they want to play that game.

Bron.

-- 
  Bron Gondwana
  br...@fastmail.fm

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Noel Jones 
On 10/25/2013 1:42 PM, Charles Marcus wrote:
> On 2013-10-25 1:29 PM, Titanus Eramius  wrote:
>> Well, if the app is not installed, it might solve the problem. Other
>> than that, I think this is a bit off-topic for Postfix, since it only
>> applys to Apples hand-held devices.
> 
> Whether it is iOS specific or not (apparently it is, at least for
> the time being, iOS specific), it also applies to the smtp
> connection to my *postfix* server, so I disagree that it is OT.
> 
> Apparently it is not a hoax, so the question remains, for those of
> us who do not have the enterprise tools to lock down iPhones and
> iPads, what is the best/most reliable way to simply block LinkedIn
> from being able to successfully connect to the SMTP server?
> 
> -- 
> 
> Best regards,
> 
> */Charles/*


I think the question of how to stop authenticated connections from
unwanted clients is reasonably on-topic.  The question of how to
block linkedin from scraping your IMAP server is best answered on
your imap software forum.


Basically two choices...

1. block all *.linkedin.com clients BEFORE any
permit_sasl_authenticated statement.  This will also have the effect
of blocking all incoming linkedin mail. That may be a little too
strict for some folks, or maybe just fine with others.

Something like:
smtpd_client_restrictions =
  check_client_access hash:/etc/postfix/banned_clients

# banned_clients
linkedin.com  REJECT  mail from LinkedIn not welcome here



2.  Use a policy service such as postfwd to reject connections if
{SASL authentication and the client == linkedin}.  This will prevent
anyone from sending mail via linkedin, but will still allow the
usual unauthenticated incoming mail.


(well, I suppose firewall their IP range is a third choice...  That
suffers from the problem of reliably finding their IP range.)




  -- Noel Jones

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Charles Marcus 

On 2013-10-25 1:29 PM, Titanus Eramius  wrote:

Well, if the app is not installed, it might solve the problem. Other
than that, I think this is a bit off-topic for Postfix, since it only
applys to Apples hand-held devices.


Whether it is iOS specific or not (apparently it is, at least for the 
time being, iOS specific), it also applies to the smtp connection to my 
*postfix* server, so I disagree that it is OT.


Apparently it is not a hoax, so the question remains, for those of us 
who do not have the enterprise tools to lock down iPhones and iPads, 
what is the best/most reliable way to simply block LinkedIn from being 
able to successfully connect to the SMTP server?


--

Best regards,

*/Charles/*

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Simon B 
On 25 Oct 2013 18:54, "Charles Marcus"  wrote:
>
> Hello,
>
> I'm really hoping this is either a hoax or I'm seriously misunderstanding
something...
>
> If it is true, how can they legally do this? And more importantly, how
can SASL_AUTH attempts be blocked? Maybe block all SASL attempts from
LinkedIn networks?

http://engineering.linkedin.com/mobile/linkedin-intro-doing-impossible-ios

And as your link points out it probably makes the user break several laws,
even if they aren't breaking any..

Simon

It's not a hoax.
> Anyway, article here:
>
> http://www.bishopfox.com/blog/2013/10/linkedin-intro/
>
> "LinkedIn released a new product today called Intro.  They call it
> ?doing the impossible?, but some might call it ?hijacking email?.
> Why do we say this?  Consider the following:
>
> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of
> your emails go through LinkedIn?s servers. You read that right. Once
> you install the Intro app, all of your emails, both sent and received,
> are transmitted via LinkedIn?s servers. LinkedIn is forcing all your
> IMAP and SMTP data through their own servers and then analyzing and
> scraping your emails for data pertaining to?whatever they feel like."
>
> --
>
> Best regards,
>
> Charles

Re: Blocking LinkedIn 'Intro' mail hijacking?

2013-10-25 Thread Titanus Eramius 
Fri, 25 Oct 2013 12:53:08 -0400 skrev Charles Marcus
:

> "Once you install the Intro app"

Well, if the app is not installed, it might solve the problem. Other
than that, I think this is a bit off-topic for Postfix, since it only
applys to Apples hand-held devices.

Cheers, Titanus