[Emerging-Sigs] Spyware DNS rules
Jack Pepper
pepperjack at afferentsecurity.com
Wed Feb 20 07:44:22 EST 2008
Quoting David Glosser <david.glosser at gmail.com>:
> I'm researching the kind of license for the domains.txt file. I'm leaning
> towards "free for noncommercial use", whatever license that type that is.
> Any help would be appreciated....
I am not very knowledgable here. I know that BSD is free for
anything, including commercial use. Any help from the list?
> Also, I'm wondering if it is an issue if the rules get reordered in some
> way. I'm commented out several hundred domains and thinking about reordering
> them to make things easire to read. Do you have some sort of numbering
> scheme, checksum or unique ID in case the rules get reordered or moved
> around?
Yeah, that was one of the things that annoyed me about the version 1
and 2 rule generators. In this program I am associating a sid with a
domain and preserving that association forever. If a domain is
dropped, the sid is still allocated and just sits idle.
I included a provision for reclaiming unused sids by rolling the
version number up. It is now at rev=3, but someday we will want to
reclaim sids and go for rev 4,
>
> Finally, is there a way to identify the client machine in some way as
> opposed to a DNS lookup?
> I would be much more interested in knowing what client is contacting a
> domain as opposed to my dns server...
The source address in the rule is the workstation that asked for the
domain. The reason for the "!DNS_SERVERS" in the source column is
that DNS servers replicate, pass queries among themselves, etc which
generates hundreds of bogus hits.
MAIL servers ask for bogus DNS names all the time also, especially
when checking SPF records and stuff like that. So I should probably
change the source field to be "[!SMTP_SERVERS,!DNS_SERVERS]". Maybe
that's rev4 right there, eh?
But aside from DNS and SMTP servers, the source field will be the
workstation that asked for the domain.
>
>
> On Feb 19, 2008 11:32 PM, Jack Pepper <pepperjack at afferentsecurity.com>
> wrote:
>
>> Since I was the original author of the program that generated the
>> spyware-dns rules on BT, I think this is a good time to rewrite it.
>> There were several things I never liked about the old spyware-dns
>> ruleset.
>>
>> I have put the ruleset on my personal site at:
>> http://www.autoshun.org/downloads/bhdns.rules
>>
>> These rules are automatically generated once per day from the domains
>> list at the Blackhole DNS project ( http://www.malwaredomains.com ).
>>
>> Matt: We have a bit of a problem with the SID allocation. The sid
>> allocation sets aside 10000 sids for bhdns rules, but there are 17000+
>> domains in the bhdns list.
>>
>> I have started counting from 2410001 which takes us up through
>> sid=2427300. How do you want to handle this? I can regenerate the
>> list to fit whatever range you think is good. Let me know.
>>
>> David: I did not put a license statement on the ruleset. I was going
>> to release under the BSD license, but I wasn't sure what kind of
>> license you intended for the domains.txt file (since that is the
>> source file for all the content). The spyware dns ruleset feels like
>> a derivative work to me, so are you OK with putting the BSD license on
>> the ruleset?
>>
>>
>> jp
>> --
>>
>> Framework? I don't need no steenking framework!
>>
>> ----------------------------------------------------------------
>> @fferent Security Labs: Isolate/Insulate/Innovate
>> http://www.afferentsecurity.com
>>
>> _______________________________________________
>> Emerging-sigs mailing list
>> Emerging-sigs at emergingthreats.net
>> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>>
>
--
Framework? I don't need no steenking framework!
----------------------------------------------------------------
@fferent Security Labs: Isolate/Insulate/Innovate
http://www.afferentsecurity.com
More information about the Emerging-sigs
mailing list