RSA Anti-phishing

On 06 Apr 2006, at 08:52 , Bob Peterson wrote:
> Take a squint at this article. At the end it mentions how some
> prominent browsers will incorporate data from this service.
>
> http://news.com.com/Fighting+fraud+by+baiting+phishers/
> 2100-1029_3-6056317.html?tag=nefd.top
>
> At first reading this blocking list looks like a great idea, and I
> want to see it incorporated in all Mac browsers, Safari and OmniWeb
> being my first picks. But I wonder what the misfeatures might be.
> For instance, how long does an IP address need to be blocked, and
> how long will it be blocked? If the criminal gives it up after a
> day, is the address recycled to some innocent business that is now
> blocked by major web browsers?

If it works at all like RBLs then yes.

And, if you stop and think about it, this is a good thing because it
punished not only the spammer/phisher scum, but also the company that
sold it space on the net.

Yes, it may be inconvenient for some clueless businesses who get a
bad IP address, but the first thing a business should do before
signing a contract for hosting is check out the company they are
signing with, and check out the IP space they will be clustered in.

It's just like renting office space. If you rent in a gang-infested
neighborhood you can't be surprised when your building gets defaced
with graffiti tags and some of your customers won't go to your location.



--
"There's nothin' wrong with bein' a son of a bitch." -- Gaspode the
Wonder Dog

>And, if you stop and think about it, this is a good thing because it
>punished not only the spammer/phisher scum, but also the company that
>sold it space on the net.

Most of the cases of phish-sites that I have assisted in
investigating have not been 'sold" space, they've cracked it. Given
the number of trivially compromised computers are out there, both
client-side (Windows on broadband), and server-side (Windows, PHP
weaknesses on *NIX, code/command injection weaknesses in various *SQL
systems, etc) there is no need for the "bad guys" to SPEND money to
set up a phishing site.


--

Chuck Goolsbee V.P. Technical Operations
_________________________________________________________________
digital.forest Phone: +1-877-720-0483, x2001
where Internet solutions grow Int'l: +1-206-838-1630
*** celebrating eleven years of service 7/12/1994 - 7/12/2005 ***
12101 Tukwila International Blvd Fax: +1-206-838-3749
Suite 410 http://www.forest.net
Seattle, WA 98168 email: cgforest.net

At 07:52 04/06/2006 -0700, Bob Peterson wrote:
>If the criminal gives it up after a day, is the address recycled to some
>innocent business that is now blocked by major web browsers?

A much bigger problem is that many IP addresses are shared. For example,
the IP address of my web site is the same as the IP address for all web
sites hosted by the same hosting company. Web sites can do this because the
browser not only connects to an IP address but also provides the server
with the path name of the page it wants -- which includes the domain name,
allowing the server to host multiple domains on one IP address.

This could lead to a great deal of collateral damage. And collateral damage
is one of the main things which has limited SpamCop and brought them the
disdain of a great many mail admins. The Cyota scheme has less potential
for false reports and joe-jobbing because outside reports are not accepted
and apparent violations are checked manually and only the web site address
(not the email source) is penalized, but once an IP address is listed, the
potential for collateral damage might be just as large as with SpamCop.

One of the principles behind SpamCop is that by blocking an entire IP
address when just one user spams, that they will force mail admins to keep
their users honest. It doesn't work. The mail admins who care, do so
anyway. The mail admins who don't care, don't do so anyway. I can't see
this scheme working any differently. It may prevent some users from being
defrauded, and that's a Good Thing, but the cost in collateral damage may
be very high. Furthermore, while there are some controls which make it
difficult for spammers to get a foothold (fastmail.fm, for example, is
nearly immune to hosting spammers), I can't conceive of similar controls
that would stop a fraudulent web site from being established. Basically,
then, the scheme punishes IP addresses for being attacked, even when the
admins fight the attack with best practices.

The dilution scheme is more interesting, but I suspect that the phishers
will find a way around it. First they will automate the checking of their
"results". This will result in a flood of inquiries, which banks and others
working with Cyota will be able to recognize, and they will temporarily
block the traffic from that IP address with respect to account logon
attempts. So then the phishers will farm the filtering inquiries out to
their botnets. Then what? Then we're back in the position of needing to
shut down the botnets, which has been difficult. That's another thread.

Edward
Art works by Melynda Reid: http://paleo.org

Bob Peterson asked,
>how long does an IP address need to be blocked, and how long will it
>be blocked? If the criminal gives it up after a day, is the address
>recycled to some innocent business that is now blocked by major web
>browsers?

If it was a dynamic DSL connection, the answer is "yes". Every time
a DSL customer disconnects and re-makes the connection, they get a
different IP address.

Lewis Butler added:
>this is a good thing because it punished not only the
>spammer/phisher scum, but also the company that sold it space on the
>net.

That may be true for companies whose principal business is Web
hosting. But what about somebody like SBC, which is effectively a
monopoly DSL provider in many states? I'm not waving any flag for
SBC, mind you; I'm writing on behalf of the thousands of their
customers who have no good alternate source of broadband connectivity.

Some time ago, I had trouble sending email because a relay point
outside SBC kept bouncing them as spam based on the originating IP
address. Once I found the cause, it was easy to fix - just break and
re-make my DSL connection, then re-send the affected messages. But
finding it took me some digging, and many users might not have been
able to do that or to interpret what they found.

Granted that my viewpoint applies to spamming rather than to
phishing, I still think that this is a half-baked "solution" which
will cause more trouble than it prevents.

Carl

On 07 Apr 2006, at 21:51 , Carl S Zimmerman wrote:
> Some time ago, I had trouble sending email because a relay point
> outside SBC kept bouncing them as spam based on the originating IP
> address. Once I found the cause, it was easy to fix - just break and
> re-make my DSL connection, then re-send the affected messages. But
> finding it took me some digging, and many users might not have been
> able to do that or to interpret what they found.

If you are sending email from your home connection MY mailserver will
bounce your message. If you are on a dynamic connection you should
be sending mail through your ISP's mailservers or some other real
mailserver that knows you (like via SMTP AUTH or something). I don't
accept email from dynamic IP ranges and neither do many others.

> Granted that my viewpoint applies to spamming rather than to
> phishing, I still think that this is a half-baked "solution" which
> will cause more trouble than it prevents.

It may cause some pains for people who want to treat their home
dynamic ISP connections as if they were static FQDNs with proper
rDNS. But that is a good thing.

Not all IPs are equal. If an IP address is not easily verifiable and
traceable to a specific person, then it is not as trustworthy as one
that is. And yes, domains that are registered with "private"
settings with registrars are also trusted less than what I consider
'real' domains.

For example, I have greylisting enabled on my system. If I notice
problem domains that are not resending the messages, I check whois.
If there is contact info, I will send the contact an email letting
them know that their mailserver is not rechecking email, and will
probably whitelist them from the greylist if the email doesn't bounce
(and certainly if I get any sort of non-automated reply). If there
is only fake (so-called "private") contact info, they have no chance
of getting off the greylist.

--
"Give a man a fire and he's warm for a day, but set fire to him and
he's warm for the rest of his life."

On Apr 8, Lewis Butler wrote:

>On 07 Apr 2006, at 21:51 , Carl S Zimmerman wrote:
>> Some time ago, I had trouble sending email because a relay point
>> outside SBC kept bouncing them as spam based on the originating IP
>> address. Once I found the cause, it was easy to fix - just break and
>> re-make my DSL connection, then re-send the affected messages. But
>> finding it took me some digging, and many users might not have been
>> able to do that or to interpret what they found.
>
>If you are sending email from your home connection MY mailserver will
>bounce your message. If you are on a dynamic connection you should
>be sending mail through your ISP's mailservers or some other real
>mailserver that knows you (like via SMTP AUTH or something). I don't
>accept email from dynamic IP ranges and neither do many others.

I have always sent email through my ISP's SMTP server, which
presumably has a fixed IP address and thus would be unaffected by
your dynamic IP filter. Nevertheless, the oldest "Received" header
within each outgoing message carries the dynamic IP address from
which I logged on to the POP server, and it is that which was
apparently blacklisted somewhere. (It also carries the private IP
address within my home network, which should be of no interest to
anyone else.)

If you want to distrust everyone who has an address swbell.net,
pacbell,net, nvbell.net, prodigy.net, or a dial-up connection to
any other ISP, that's your choice. But I think it will cause a lot
of unnecessary trouble for potential correspondents, without
significant benefit to you.

On 10 Apr 2006, at 14:37 , Carl S Zimmerman wrote:
> I have always sent email through my ISP's SMTP server, which
> presumably has a fixed IP address and thus would be unaffected by
> your dynamic IP filter. Nevertheless, the oldest "Received" header
> within each outgoing message carries the dynamic IP address from
> which I logged on to the POP server, and it is that which was
> apparently blacklisted somewhere. (It also carries the private IP
> address within my home network, which should be of no interest to
> anyone else.)

Oh, I misunderstood then. No, that is moronic. The only IP address
any mailserver should look at for accepting/denying the connection is
the one of the server connecting to it.

Now, your spam filters... maybe, but since the only receive header
you can trust is your own, it seems a bit silly.


--
If it wasn't for the pirates, I bet Star Wars: Ep III would have made
$50 million its first DAY!

On Apr 11, 2006, at 10:54 PM, Google Kreme wrote:

> No, that is moronic. The only IP address
> any mailserver should look at for accepting/denying the connection is
> the one of the server connecting to it.
>
> Now, your spam filters... maybe, but since the only receive header
> you can trust is your own, it seems a bit silly.

"Should" and "do" are different things.

  At one point in our mail system, messages get back into the MTA on
IP 127.0.0.2. We found two mail server systems fairly quickly which
didn't like seeing that address in the Received: headers, so we
changed the headers to report the machine's real IP.

The first server on which this turned up was a US Navy server which
forwards crew email to ships at sea. I can understand their desire
not to forward spam; I can understand the crew members' families'
desire not to have their email rejected. So we made it work,
thinking it unlikely that we could change the Navy. (We earlier had
concluded that we wouldn't be able to change an invalid host name
used for the Naval Hospital Bremerton web site.)

   --John