David Hooton of Platform Networks has been converting the proprietary SpamAssassin message content filtering rules of MailSecurity.net.au into SURBLs. The data's being organized into separate SURBLs, for example pharma, phishing, and other spams. In order to give something back to the SURBL/SA community and the Internet in general, he is proposing to make the phishing data freely available for potential inclusion by Bill Stearns in ws.surbl.org.
Access to the other lists would be sold commercially, but the phishing data would be a potentially useful spam/fraud/crime fighting tool to make available to everyone, while hopefully creating some recognition for their other lists. A preliminary web page describing the phishing list is at:
http://www.mailsecurity.net.au/phish/
Dave describes the status of the phishing list as public in that: "We're going to release our phishing attack list publicly and it will remain that way for the duration of it's life. The only attachment to my business will be that we use it as well & that it will be maintained by my staff." The site will get a phishing spam form added for public submissions before it goes live. Their phishing data sources include spamtraps and feeds from other organizations.
Dave asked me to bring up this idea for some discussion and feedback, and he's on these lists so feel free to reply here.
How do people feel about adding this data to a public SURBL? Does this kind of division of free and commercial uses seem ok? Would any of the SURBL public name servers have any issues with an arrangement like this?
Jeff C.
Hi!
http://www.mailsecurity.net.au/phish/
Dave describes the status of the phishing list as public in that: "We're going to release our phishing attack list publicly and it will remain that way for the duration of it's life. The only attachment to my business will be that we use it as well & that it will be maintained by my staff." The site will get a phishing spam form added for public submissions before it goes live. Their phishing data sources include spamtraps and feeds from other organizations.
Dave asked me to bring up this idea for some discussion and feedback, and he's on these lists so feel free to reply here.
How do people feel about adding this data to a public SURBL? Does this kind of division of free and commercial uses seem ok? Would any of the SURBL public name servers have any issues with an arrangement like this?
How large will the list be, and can we, before proceeding with adding new lists, work on the combined list?
Sounds ok to me to get the list going, but first i want to complete the previous steps.
Thanks, Raymond.
-----Original Message----- From: discuss-bounces@lists.surbl.org [mailto:discuss- bounces@lists.surbl.org] On Behalf Of Raymond Dijkxhoorn Sent: Tuesday, 4 May 2004 5:50 PM To: Jeff Chan; SURBL Discussion list Subject: Re: [SURBL-Discuss] Proposal to add some anti-phishing data to SURBL
How large will the list be, and can we, before proceeding with adding new lists, work on the combined list?
Hi Raymond,
The list by nature will not be large. Most phishing attacks seem to use IP's of compromised machines or domain names which are shut down quite quickly. Our expiry policy is designed to keep it this way & to avoid FP's due to old records.
We're also hoping to develop a system for ISP's/netblock owners to close incidents once the attack has been mopped up.
Sounds ok to me to get the list going, but first i want to complete the previous steps.
I think the intention was for our data to be integrated directly into William's prior to arriving at nameservers, however Jeff is more likely to be able to confirm this :)
Cheers!
Dave
======================================================================== Pain free spam & virus protection by: www.mailsecurity.net.au Forward undetected SPAM to: spam@mailsecurity.net.au ========================================================================
Hi!
How large will the list be, and can we, before proceeding with adding new lists, work on the combined list?
The list by nature will not be large. Most phishing attacks seem to use IP's of compromised machines or domain names which are shut down quite quickly. Our expiry policy is designed to keep it this way & to avoid FP's due to old records.
We're also hoping to develop a system for ISP's/netblock owners to close incidents once the attack has been mopped up.
If thats the case, and thats also what i notice on my end, isnt it a better way of using a list like DSBL for those ?
Or is blocking with URI effective on these kind of spams also ? Abviously it is, but just checking :)
Sounds ok to me to get the list going, but first i want to complete the previous steps.
I think the intention was for our data to be integrated directly into William's prior to arriving at nameservers, however Jeff is more likely to be able to confirm this :)
That would be perfect, saves the trouble of making a seperate list.
Would only be nice for example to give a specific code back, so people see what the hit triggered... But thats possible, we only need to reserve a code in that case.
Bye, Raymond.
On Tuesday, May 4, 2004, 2:03:11 AM, Raymond Dijkxhoorn wrote:
I think the intention was for our data to be integrated directly into William's prior to arriving at nameservers, however Jeff is more likely to be able to confirm this :)
That would be perfect, saves the trouble of making a seperate list.
Would only be nice for example to give a specific code back, so people see what the hit triggered... But thats possible, we only need to reserve a code in that case.
It's pretty certain we will want to do a combined list of at least ws and sc. As an alternative to Bill merging a phishing list into ws, we could add it to a combined list and *not* have it as a small, separate list. (In other words it would obly be available in a combined list.) If we do the latter we could probably give it a unique result value.
Either way is possible (i.e. merge into ws, or merge into a combined list.):
1. Merge into ws: probably no specific code for phishing 2. Merge into combined list: could have a separate code 2a. (With no separate list for phishing if it's small.)
Jeff C.
-----Original Message----- From: discuss-bounces@lists.surbl.org [mailto:discuss- bounces@lists.surbl.org] On Behalf Of Jeff Chan Sent: Tuesday, 4 May 2004 7:16 PM To: SURBL Discussion list Subject: Re: [SURBL-Discuss] Proposal to add some anti-phishing data to SURBL
It's pretty certain we will want to do a combined list of at least ws and sc. As an alternative to Bill merging a phishing list into ws, we could add it to a combined list and *not* have it as a small, separate list. (In other words it would obly be available in a combined list.) If we do the latter we could probably give it a unique result value.
Either way is possible (i.e. merge into ws, or merge into a combined list.):
- Merge into ws: probably no specific code for phishing
- Merge into combined list: could have a separate code
2a. (With no separate list for phishing if it's small.)
I personally think 2 is the preferred option as it provides domain & netblock owners with a possible means of becoming unlisted. Further helping us remove false positives and mopped up incidents as soon as we can.
As far as creating additional SURBL's go, I think the less lists kept overall the better, it's much kinder on bandwidth & end users system performance.
Cheers,
Dave
======================================================================== Pain free spam & virus protection by: www.mailsecurity.net.au Forward undetected SPAM to: spam@mailsecurity.net.au ========================================================================
On Tuesday, May 4, 2004, 2:48:17 AM, David Hooton wrote:
Jeff Chan wrote:
- Merge into ws: probably no specific code for phishing
- Merge into combined list: could have a separate code
2a. (With no separate list for phishing if it's small.)
I personally think 2 is the preferred option as it provides domain & netblock owners with a possible means of becoming unlisted. Further helping us remove false positives and mopped up incidents as soon as we can.
As soon as the domains come off your list, they will come out of the SURBL. IOW the SURBL is built dynamically from your domain list.
That said, processing things here automatically may be a bit quicker than going through Bill's more manual procedure. Maybe I should assume we will do the merging here.
Also I'm somewhat concerned about "netblocks" going to SURBLs for a couple reasons:
1. SURBLs are largely domain name based. They're meant to block domains (or IP addresses) appearing in URIs. They're not meant to block resolved domains, sender domains or mail sender IP addresses. Remember that there's no name resolution being done on the client side. A domain in a URI will ***not*** be resolved into an IP address. If the URI has an IP address like: http://1.1.1.1/ then 1.1.1.1 is what should be checked against the SURBL. In other words SURBLs are used to check whatever happens to appear in the URI, where that's most often an unresolved domain name.
2. Address blocks imply more than one address, i.e. networks. SURBLs so far have not included any networks, only the occasional web hosting IP address mentioned above. It is possible to list blocks in various limited ways, and that may be useful for SURBLs to do in a few cases, but we have not done so because it doesn't fit the model above as well as it does for purely number-based regular LHS RBLs.
3. Address blocks also imply a range of addresses, where SURBLs generally have listed a few individual addresses that spammers are foolish enough to use in their spam URIs. Those are a very small minority of cases. Our approach is more specific, perhaps a little too specific to deal with a few cases, but that's how it was built.
As far as creating additional SURBL's go, I think the less lists kept overall the better, it's much kinder on bandwidth & end users system performance.
Can you give us an idea of how many records might go onto the list? I realize all the data feeds may not be up and running yet, but a general idea could be useful.
Jeff C.
-----Original Message----- From: discuss-bounces@lists.surbl.org [mailto:discuss- bounces@lists.surbl.org] On Behalf Of Jeff Chan Sent: Tuesday, 4 May 2004 8:17 PM To: SURBL Discuss Subject: Re: [SURBL-Discuss] Proposal to add some anti-phishing data to SURBL
On Tuesday, May 4, 2004, 2:48:17 AM, David Hooton wrote:
Jeff Chan wrote:
- Merge into ws: probably no specific code for phishing
- Merge into combined list: could have a separate code
2a. (With no separate list for phishing if it's small.)
I personally think 2 is the preferred option as it provides domain & netblock owners with a possible means of becoming unlisted. Further
helping
us remove false positives and mopped up incidents as soon as we can.
As soon as the domains come off your list, they will come out of the SURBL. IOW the SURBL is built dynamically from your domain list.
The concept being a custom reponse (txt record) would facilitate the person whose mail is altered knows why - ie. phishing not Spam.
That said, processing things here automatically may be a bit quicker than going through Bill's more manual procedure. Maybe I should assume we will do the merging here.
Also I'm somewhat concerned about "netblocks" going to SURBLs for a couple reasons:
- SURBLs are largely domain name based. They're meant to block
domains (or IP addresses) appearing in URIs. They're not meant to block resolved domains, sender domains or mail sender IP addresses. Remember that there's no name resolution being done on the client side. A domain in a URI will ***not*** be resolved into an IP address. If the URI has an IP address like: http://1.1.1.1/ then 1.1.1.1 is what should be checked against the SURBL. In other words SURBLs are used to check whatever happens to appear in the URI, where that's most often an unresolved domain name.
I understand this, and as the listing policy states we are only planning on listing individual IP addresses and domains that are included in phishing attacks.
No pre-emptive blocking will be conducted on IP ranges.
I think where the confusion has come in is that I have referred to allowing "Netblock Owners" ie. people who own the IP space to request removal of their individual IP addresses from the SURBL once the IP has been mopped up.
- Address blocks imply more than one address, i.e. networks.
SURBLs so far have not included any networks, only the occasional web hosting IP address mentioned above. It is possible to list blocks in various limited ways, and that may be useful for SURBLs to do in a few cases, but we have not done so because it doesn't fit the model above as well as it does for purely number-based regular LHS RBLs.
Phishing attacks rarely if ever use netblocks, so don't be too worried! If this policy was to ever be reviewed it would be done within this forum, and as with this thread, opportunities for community input will be offered.
- Address blocks also imply a range of addresses, where SURBLs
generally have listed a few individual addresses that spammers are foolish enough to use in their spam URIs. Those are a very small minority of cases. Our approach is more specific, perhaps a little too specific to deal with a few cases, but that's how it was built.
There is a much higher incidence of IP based urls in phishing attacks than in general spam, due in part to the majority of attacks being built on stolen bandwidth and on hacked/trojaned servers.
This is and probably always will be the modus operandi for these "PhisherMen".
As far as creating additional SURBL's go, I think the less lists kept overall the better, it's much kinder on bandwidth & end users system performance.
Can you give us an idea of how many records might go onto the list? I realize all the data feeds may not be up and running yet, but a general idea could be useful.
This is a pretty hard question. From the rough figures I've done I can't see it hitting much more than 1500 records at any one time. This is mainly due to the fact that we're planning on running an expiry process as outlined on the policy page & because we hope to provide a means of notification & removal for ISP's and machine owners.
I have not seen the same IP address used more than once and have only seen individual domains used for around a week or two in phishes. I think the self expiring model is probably a wise approach due to this.
Regards,
David Hooton Senior Partner Platform Networks www.platformnetworks.net
======================================================================== Pain free spam & virus protection by: www.mailsecurity.net.au Forward undetected SPAM to: spam@mailsecurity.net.au ========================================================================
On Tuesday, May 4, 2004, 3:49:06 AM, David Hooton wrote:
On Tuesday, May 4, 2004, 2:48:17 AM, David Hooton wrote:
Jeff Chan wrote:
- Merge into ws: probably no specific code for phishing
- Merge into combined list: could have a separate code
2a. (With no separate list for phishing if it's small.)
I personally think 2 is the preferred option as it provides domain & netblock owners with a possible means of becoming unlisted. Further
helping
us remove false positives and mopped up incidents as soon as we can.
The concept being a custom reponse (txt record) would facilitate the person whose mail is altered knows why - ie. phishing not Spam.
Aha, you were more concerned about a specific reason (i.e. phishing) being presented. I misunderstood. That would probably be better if I did the combining.
That said, processing things here automatically may be a bit quicker than going through Bill's more manual procedure. Maybe I should assume we will do the merging here.
Also I'm somewhat concerned about "netblocks" going to SURBLs
I understand this, and as the listing policy states we are only planning on listing individual IP addresses and domains that are included in phishing attacks.
No pre-emptive blocking will be conducted on IP ranges.
Sounds good.
I think where the confusion has come in is that I have referred to allowing "Netblock Owners" ie. people who own the IP space to request removal of their individual IP addresses from the SURBL once the IP has been mopped up.
Got it. I read that as discussing input data for the list as opposed to describing resulting actions taken to get off the list.
There is a much higher incidence of IP based urls in phishing attacks than in general spam, due in part to the majority of attacks being built on stolen bandwidth and on hacked/trojaned servers.
Thanks for the added background. Multiple, individual IP-based URIs scattered around the Internet would work fine as a SURBL.
I can't see it hitting much more than 1500 records at any one time. This is mainly due to the fact that we're planning on running an expiry process as outlined on the policy page & because we hope to provide a means of notification & removal for ISP's and machine owners.
OK good to know.
I have not seen the same IP address used more than once and have only seen individual domains used for around a week or two in phishes. I think the self expiring model is probably a wise approach due to this.
Yes, that sounds very appropriate to the data.
Jeff C.
On Tuesday, May 4, 2004, 1:57:29 AM, David Hooton wrote:
I think the intention was for our data to be integrated directly into William's prior to arriving at nameservers, however Jeff is more likely to be able to confirm this :)
It partially depends on the amount of data. We probably don't want to start up another list of under 1000 records. If there are say a few hundred they may make more sense added to ws.surbl.org, as it looks like may happen with some others.
Jeff C.
Good morning, David, Jeff,
On Mon, 3 May 2004, Jeff Chan wrote:
David Hooton of Platform Networks has been converting the proprietary SpamAssassin message content filtering rules of MailSecurity.net.au into SURBLs. The data's being organized into separate SURBLs, for example pharma, phishing, and other spams. In order to give something back to the SURBL/SA community and the Internet in general, he is proposing to make the phishing data freely available for potential inclusion by Bill Stearns in ws.surbl.org.
I'll gladly integrate your entries into sa-blacklist, David - thanks for taking the time to work on those. Cheers, - Bill
--------------------------------------------------------------------------- Q: Is it possible to set up masquerading timeouts that TCP connection never expires even if there are no any packets traveling? A: Sure. # ipchains -M -S 13564800 0 0 That'll last you up until January 1, 2000, and after the rioting will start and you won't have to worry about masquerading any more. 8-) -- Paul Rusty Russell Paul.Russell@rustcorp.com.au -------------------------------------------------------------------------- William Stearns (wstearns@pobox.com). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org --------------------------------------------------------------------------
On Tuesday, May 4, 2004, 6:29:10 AM, William Stearns wrote:
On Mon, 3 May 2004, Jeff Chan wrote:
David Hooton of Platform Networks has been converting the proprietary SpamAssassin message content filtering rules of MailSecurity.net.au into SURBLs. The data's being organized into separate SURBLs, for example pharma, phishing, and other spams. In order to give something back to the SURBL/SA community and the Internet in general, he is proposing to make the phishing data freely available for potential inclusion by Bill Stearns in ws.surbl.org.
I'll gladly integrate your entries into sa-blacklist, David -thanks for taking the time to work on those.
Thanks Bill. Whatever way they get added into a SURBL would be great! At present you may actually be better prepared to handle adding them in than I.
Jeff C.
-
David Hooton -
Jeff Chan -
Raymond Dijkxhoorn -
William Stearns