Re: Protecting from phishing

[John LaPrad <jrl () SVSU EDU>]

Thanks for the responses. We just had another student last night fall for this. The web site they went to was not at 
all like ours. But, it was a well done, generic 'support' site. The user was asked to 'login' using their email 
credentials. We have been telling folks to not give out their IDs and PWs, but now we have to educate them on being 
able to recognize a fake web site. Its a lot harder.
With this fast-flux stuff, I think that a comprehensive up-to-date blacklist not obtainable. So I was trying to think 
of a sort of 'white-list' mechanism that might work.
I have realized now that setting up authorized IPs or locations and prompting for an additional step if they login from 
a new site is complicated for email, because of smtp, imap, and mobile users.
I think that our users could be required to login via the webmail client at least once from any location to 'validate' 
that location. Then they could use these other services, but cookies are only good in the browser, and ISPs can change 
the users IP addresses. So that may not be practical.

The days of a 'trusted' Internet are long gone. Its too bad we have to waste so much time on this stuff.

I have looked for an RBL for BGP before. There used to be one called MAPS I believe, but it seems it was bought out by 
Tend and then dumped. In any case that would only work for users on campus. We are a commuter campus so most of our 
users would go unprotected, unless the ISPs also subscribed to this sort of thing, which might not be a bad idea, 
except that you have the whole 'who manages the RBL thing' and how to get off it. And if its black-holing IP addresses, 
its quite serious if there are false positives.


John LaPrad
CISSP, CNE, CCNA, CCDA
Manager of Network Services
Saginaw Valley State University
Phone: 989-964-7134
Fax: 989-964-7446

----- Original Message -----
From: "Leo Song" <song () UOGUELPH CA>
To: SECURITY () LISTSERV EDUCAUSE EDU
Sent: Tuesday, October 20, 2009 8:33:41 AM GMT -05:00 US/Canada Eastern
Subject: Re: [SECURITY] Protecting from phishing

I am skeptical about this approach, but surely I would follow this
thread to see how it goes, the Internet is built based on the trust, but
adversely we often become victims of such trust, I am hoping something
could be done at network routing part, maybe BGP could have another
field called "reputation", as of today, besides of user education
program, the "best" approach would be having a firm procedure to react
phisher's actions.

Leo

-----Original Message-----
From: Flynn, Gerald <flynngn () JMU EDU>
Reply-to: The EDUCAUSE Security Constituent Group Listserv
<SECURITY () LISTSERV EDUCAUSE EDU>
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Protecting from phishing
Date: Mon, 19 Oct 2009 15:08:47 -0400

> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John LaPrad
> Sent: Monday, October 19, 2009 2:13 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: [SECURITY] Protecting from phishing
>
> We have had multiple users, faculty and students fall for phishing
> exploits in the past few months. We have an education program, we block
> spam (some still slips through), we wrote custom filters to make sure
> no one replies to phishing emails (they started embedding links to
> websites instead) and these phishing attempts are still working
> occasionally.
> I was wondering if it would be reasonable to front the email servers
> with a system, like some banks do, where the system remembers your IP
> and whenever you connect from a new IP, you have to take some
> additional step before getting in.
> I think that this would stop the phishers.
> Is anyone doing something like this, or heard of it?
> Maybe I am missing something, and this simply would not work?
> I appreciate any feedback.

That might work if the phishers were connecting only to your web
interface with compromised accounts to send the messages.

This is referred to in some circles as an aspect of
risk based authentication or adaptive access control. It
is in many commercial identity management products now.

We're not currently using it but I'm very interested in it.
Factors other than IP addresses can be used. For example,
browser cookies. Or geographic location or ISP rather than
exact IP address match. Or time of day.

Most systems require answers to challenge questions if the
system sees something that policy says needs extra
authentication. Those challenge questions pose the usual
challenges to usability and support.

And all such systems I'm aware of are web based which means
it won't help with phishing messages sent through IMAP, POP,
or SMTP sessions.

For SMTP, greylisting comes close to providing what you describe
but its easily bypassed. The banks have an advantage in that
they are dealing with a known user base and they are interacting
with people. Mail servers, by definition, have to accept
connections from anyone eventually and they are interacting
with machines. Kind of hard to send a challenge question
to an interim SMTP server. :) Well, I guess you could send a
special non-delivery message back to the end user who would
be required to login somewhere and answer some challenge
questions but the delay in user notification would be
unacceptable. SMTP is a store and forward protocol, not an
end to end protocol.

Likewise, IMAP and POP sessions would be difficult without
modifications in the clients. Might be able to do something
with IMAP messaging though. Unlike the SMTP sessions, at least
you have a human being at the other end to interact with.


Gary Flynn
Security Engineer
James Madison University