[Discussion] What are we making? -- CLIENT Side
David Glosser
david.glosser at gmail.com
Sun Oct 19 22:24:44 UTC 2008
no argument from me ;)
just want to make the and granny and granny's IAP's happy...
Also, would like to note it would be great if web hosting services
(and website owners) are alerted when their site is hosting a bot,
contains sql injection code, etc. I'm wondering about a rule set or
something tailored to this reverse direction, from their OWN internal
networks outbound. Maybe an IDS set tuned for the ISPs and web hosters
of the world?
Like what somebody said earlier (sorry, I don't remember who) said,
you can't and shouldn't assume that all threats come from the
outside....
On Sun, Oct 19, 2008 at 3:30 PM, Martin Holste <mcholste at gmail.com> wrote:
> Right, but I envision the XML to be the source that scripts would parse into
> whatever is needed, like router config, dns blocklists, host files, search
> engine blacklists, etc. The key would be to create a standard capable of
> being specific enough to feed the lowest common demoninator.
>
> --Martin
>
> On Sun, Oct 19, 2008 at 1:15 PM, David Glosser <david.glosser at gmail.com>
> wrote:
>>
>> Getting the information out could be in multiple formats - static
>> stuff like XML, null routes, dns blocklists, even the dreaded
>> host-file...
>>
>> More dynamic stuff could be BGP, DNS (or partner with opendns), etc.
>>
>>
>>
>>
>>
>> On Sun, Oct 19, 2008 at 2:06 PM, Martin Holste <mcholste at gmail.com> wrote:
>> > Yes, exactly, well put. What about chartering a CVE-inspired protocol
>> > for
>> > our blacklists? I think someone mentioned there was an IETF draft or
>> > something for that that didn't get off the ground. A specification
>> > could be
>> > as simple as a DTD for XML blacklists like:
>> >
>> > <blacklist>
>> > <ip ID=1>
>> > <date_added />
>> > <list_id />
>> > <date_added />
>> > <date_of_first_offense />
>> > <address>x.x.x.x</address>
>> > <added_by />
>> > <reason />
>> > <confidence />
>> > <date_last_blocked />
>> > </ip>
>> > </blacklist>
>> >
>> > Or whatever--you get the idea. I think that the really cool part would
>> > be
>> > if the "reason" tag referred to an actual event uploaded in a
>> > snortsam-like
>> > way to a community event database.
>> >
>> > Providing a standard blacklist definition would make it much easier for
>> > orgs
>> > to write their own filters for what blacklist items they want to block
>> > on,
>> > which would lead to higher adoption rates. To further accelerate
>> > adoption,
>> > the community could even parse other publicly available lists at the
>> > start
>> > and republish them in the new standard until those sources natively
>> > publish
>> > in the standard.
>> >
>> > --Martin
>> >
>> > On Sun, Oct 19, 2008 at 12:50 PM, David Glosser
>> > <david.glosser at gmail.com>
>> > wrote:
>> >>
>> >> How about if a subset of the data (IP blacklists, domain blacklists,
>> >> etc) is made available to the googles of the world, Granny's isps,
>> >> browser-plug-in writers of the world, and desktop-based software. Then
>> >> granny can be protected on the desktop, her ISP, etc.
>> >>
>> >>
>> >>
>> >>
>> >> On Sun, Oct 19, 2008 at 1:18 PM, Martin Holste <mcholste at gmail.com>
>> >> wrote:
>> >> > I vehemently agree with Matt about the necessity of staying out of
>> >> > the
>> >> > client-side arena. I think that if we're going to actually produce
>> >> > anything
>> >> > of value, we need to narrow the scope to start with. My vote is that
>> >> > we
>> >> > consider notifying Granny that there's something bad on her PC out of
>> >> > scope
>> >> > until we figure out how to notify Granny's ISP's network security
>> >> > admin
>> >> > that
>> >> > there's something bad. If we can figure out how to reliably find
>> >> > successful
>> >> > compromises and get that information output as actionable
>> >> > intelligence
>> >> > to
>> >> > the netsec community, the rest will come in time.
>> >> >
>> >> > For instance, if we can get to the point where we're %99.99 sure that
>> >> > a
>> >> > given URL is bad, then we could work on setting up an alliance with a
>> >> > place
>> >> > like Google, which already has an infrastructure for end-user
>> >> > notification
>> >> > of bad sites (as in, the "this site may harm your computer" displayed
>> >> > under
>> >> > links to sql injected pages). I'm sure Neils Provos would be
>> >> > interested
>> >> > in
>> >> > hints from this group. I would say that blackhat SEO is 80% of the
>> >> > malware
>> >> > infection vector right now, so that would be huge.
>> >> >
>> >> > Someday even farther in the future, we could use a platform like
>> >> > OSSEC
>> >> > HIDS
>> >> > to deliver our blacklists, or a browser plugin, but that is a carrot
>> >> > on
>> >> > a
>> >> > stick for another day.
>> >> >
>> >> > The point is that we need to start by doing one thing and doing it
>> >> > well:
>> >> > provide the most accurate method of network-based detection and
>> >> > prevention
>> >> > of compromises to date by leveraging the collective wisdom of the
>> >> > community.
>> >> >
>> >> > On Sun, Oct 19, 2008 at 11:48 AM, Matt Jonkman <jonkman at jonkmans.com>
>> >> > wrote:
>> >> >>
>> >> >> Martin Holste wrote:
>> >> >> > I'm guessing that the intent is to be the "detection" component of
>> >> >> > the
>> >> >> > Trusted Internet Connection (TIC)
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > (http://taosecurity.blogspot.com/2007/12/feds-plan-to-reduce-then-monitor.html),
>> >> >> > in which the mandate is to protect all federal assets, especially
>> >> >> > the
>> >> >> > federal desktop environment.
>> >> >>
>> >> >> Certainly a sound approach to tackle such a problem. Glad I don't
>> >> >> have
>> >> >> to solve that one, it's huge among gov't agencies. Especially in the
>> >> >> US,
>> >> >> but surely similar everywhere.
>> >> >>
>> >> >>
>> >> >> Even if DHS has different goals, I think
>> >> >> > that this group could do a great service by providing the TIC's
>> >> >> > protection geared toward the client-side, and I think for most
>> >> >> > sectors,
>> >> >> > that's where the most imminent threats lie. Again, I'm certainly
>> >> >> > not
>> >> >> > saying that defending servers is out of scope, just that IDS has
>> >> >> > historically been about defending servers as the primary goal,
>> >> >> > with
>> >> >> > clients secondary, and I think that needs to be reversed now.
>> >> >>
>> >> >> I agree. At emerging threats we've been lately heavy into
>> >> >> post-infection
>> >> >> signatures in our research. There are many vulnerabilities out there
>> >> >> in
>> >> >> client apps, but I'd venture to say that a very high percentage of
>> >> >> the
>> >> >> infections out there aren't the result of a remotely exploitable
>> >> >> vulnerability. Most come from users clicking on email attachments,
>> >> >> installing fake software/codecs, and visiting websites with hostile
>> >> >> code.
>> >> >>
>> >> >> We've tried many times to write effective signatures to detect
>> >> >> hostile
>> >> >> html/java/gifs, etc. It's just not feasible as is. Code is too
>> >> >> flexible
>> >> >> for signature-based approaches. You can say the same thing a hundred
>> >> >> ways, especially in html.
>> >> >>
>> >> >> So how can we go after client side?
>> >> >>
>> >> >> I really REALLY am not excited about trying to make a windows
>> >> >> client.
>> >> >> Not only does that open up a huge responsibility in support and the
>> >> >> inevitable bluescreens, but I have had a difficult time over the
>> >> >> years
>> >> >> believing that any process on ANY os (especially windows) could be
>> >> >> trusted and independant enough to watch itself. Take into account
>> >> >> how
>> >> >> easy it is for trojans and rootkits to shut down antivirus, or blind
>> >> >> it.
>> >> >> And these are products with hundreds of the most skilled coders
>> >> >> around
>> >> >> working on them.
>> >> >>
>> >> >> I know we're sharp as a community, but I don't think that's a battle
>> >> >> we
>> >> >> want to get in to. So how can we do it at the network layer?
>> >> >>
>> >> >> Sandboxing?
>> >> >>
>> >> >> Virtual emulators?
>> >> >>
>> >> >> Or do we continue the thinking that for any infection to be of any
>> >> >> use
>> >> >> to anyone it has to generate traffic? It has to call home, send
>> >> >> spam,
>> >> >> report stolen information, something. So we concentrate on detecting
>> >> >> and
>> >> >> stopping the post infection?
>> >> >>
>> >> >> What does everyone think about that?
>> >> >>
>> >> >> Matt
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > --Martin
>> >> >> >
>> >> >> > On Sat, Oct 18, 2008 at 9:31 PM, Andre Ludwig
>> >> >> > <aludwig at packetspy.com
>> >> >> > <mailto:aludwig at packetspy.com>> wrote:
>> >> >> >
>> >> >> > I doubt the intent of the DHS is to simply do good, they are
>> >> >> > most
>> >> >> > likely
>> >> >> > much more focused on producing technology that allows them to
>> >> >> > detect/mitigate/prevent attacks against critical components.
>> >> >> > This
>> >> >> > of
>> >> >> > course means detecting attacks that fly below the threshold of
>> >> >> > detection
>> >> >> > for todays technology. If it comes to "doing good" or
>> >> >> > detecting
>> >> >> > state
>> >> >> > sponsored attacks against critical components (think custom
>> >> >> > attacks
>> >> >> > against unknown vulns), i'm going to go out on a limb and say
>> >> >> > they
>> >> >> > would
>> >> >> > rather protect the critical component vs the enduser.
>> >> >> >
>> >> >> > What you are discussing still has value and merit but im not
>> >> >> > so
>> >> >> > sure
>> >> >> > it
>> >> >> > is what should be focused on, but of course I am not the
>> >> >> > person
>> >> >> > to
>> >> >> > decide such things.
>> >> >> >
>> >> >> > Andre
>> >> >> >
>> >> >> >
>> >> >> > Rob, grandpa of Ryan, Trevor, Devon & Hannah wrote:
>> >> >> > > Question: what are we making? Oh, yeah, I read the blurb:
>> >> >> > "The
>> >> >> > OISF has been
>> >> >> > > chartered and funded to build a next-generation intrusion
>> >> >> > detection and prevention
>> >> >> > > engine. This project will consider every new and existing
>> >> >> > technology, concept and
>> >> >> > > idea to build a completely open source licensed engine."
>> >> >> > >
>> >> >> > > OK, we're making an IDS. But I think we need to be more
>> >> >> > specific.
>> >> >> > In particular,
>> >> >> > > we need to answer the question of "who."
>> >> >> > >
>> >> >> > > Since the DHS has provided money, I suspect there would be
>> >> >> > an
>> >> >> > automatic
>> >> >> > > assumption that this is a heavy-duty device intended for use
>> >> >> > to
>> >> >> > protect major
>> >> >> > > servers and nodes in the critical information
>> >> >> > infrastructure.
>> >> >> > (Whatever that
>> >> >> > > means.) This kind of thing is built by professionals, for
>> >> >> > professionals. Trained
>> >> >> > > people.
>> >> >> > >
>> >> >> > > However, given the current computing environment, I think it
>> >> >> > would
>> >> >> > be relatively
>> >> >> > > easy to make a case that such a device is not going to do
>> >> >> > all
>> >> >> > that
>> >> >> > much good. That
>> >> >> > > a more accessible device, intended for "Grannyx" users,
>> >> >> > would
>> >> >> > actually do more to
>> >> >> > > protect the infrastructure. After all, it isn't major nodes
>> >> >> > on
>> >> >> > the net that make up
>> >> >> > > botnets, it's the little guys. Protect them, and you reduce
>> >> >> > the
>> >> >> > threat. This is the
>> >> >> > > "low hanging fruit" for the blackhats, so protecting that
>> >> >> > crop
>> >> >> > is
>> >> >> > going to give us
>> >> >> > > the greatest benefit for the commitment of resources.
>> >> >> > >
>> >> >> > > This makes a difference. Not, perhaps, in terms of
>> >> >> > questions
>> >> >> > about multithreading
>> >> >> > > analysis streams using graphics co-processors. But
>> >> >> > certainly
>> >> >> > in
>> >> >> > most other areas.
>> >> >> > >
>> >> >> > > We've talked about extensibility. If we create a standard
>> >> >> > template or format for
>> >> >> > > signatures, the "who" makes a difference. Professionals
>> >> >> > need a
>> >> >> > warning and a
>> >> >> > > packet. Grannyx users need a warning, no packet, a clear
>> >> >> > explanation of what and
>> >> >> > > how important, and a recommended course of action. Makes a
>> >> >> > difference to the
>> >> >> > > template.
>> >> >> > >
>> >> >> > > In terms of my recommendation of a paran-o-meter, it makes a
>> >> >> > difference.
>> >> >> > > Actually, I see huge debates over initial settings: do we
>> >> >> > keep
>> >> >> > it
>> >> >> > low to keep from
>> >> >> > > crying wolf, or keep it high to keep people as safe as
>> >> >> > possible.
>> >> >> > But one thing that
>> >> >> > > should be done is make the paranoia settings
>> >> >> > not-quite-obvious
>> >> >> > up
>> >> >> > front, so that
>> >> >> > > somebody needs to know a little about the implications
>> >> >> > before
>> >> >> > they
>> >> >> > start fiddling
>> >> >> > > with settings.
>> >> >> > >
>> >> >> > > Heck, if it's a professional device, we don't need to worry
>> >> >> > about
>> >> >> > the interface at
>> >> >> > > all. If it's for Granny, we definitely do.
>> >> >> > >
>> >> >> > > It also makes a difference in terms of the technology to be
>> >> >> > included. If it is for
>> >> >> > > professionals, we can throw in everything. If for Granny,
>> >> >> > we
>> >> >> > need
>> >> >> > to make a
>> >> >> > > careful choice about maximum protection for minimum
>> >> >> > performance
>> >> >> > drain.
>> >> >> > >
>> >> >> > > ====================== (quote inserted randomly by Pegasus
>> >> >> > Mailer)
>> >> >> > > rslade at vcn.bc.ca <mailto:rslade at vcn.bc.ca>
>> >> >> > slade at victoria.tc.ca <mailto:slade at victoria.tc.ca>
>> >> >> > rslade at computercrime.org <mailto:rslade at computercrime.org>
>> >> >> > > I'm getting so absent-minded that sometimes in the
>> >> >> > middle
>> >> >> > of
>> >> >> > > victoria.tc.ca/techrev/rms.htm
>> >> >> > <http://victoria.tc.ca/techrev/rms.htm>
>> >> >> > blogs.securiteam.com/index.php/archives/author/p1/
>> >> >> > <http://blogs.securiteam.com/index.php/archives/author/p1/>
>> >> >> > > _______________________________________________
>> >> >> > > Discussion mailing list
>> >> >> > > Discussion at openinfosecfoundation.org
>> >> >> > <mailto:Discussion at openinfosecfoundation.org>
>> >> >> > >
>> >> >> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >> >> > >
>> >> >> > >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Discussion mailing list
>> >> >> > Discussion at openinfosecfoundation.org
>> >> >> > <mailto:Discussion at openinfosecfoundation.org>
>> >> >> >
>> >> >> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ------------------------------------------------------------------------
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Discussion mailing list
>> >> >> > Discussion at openinfosecfoundation.org
>> >> >> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >> >>
>> >> >> --
>> >> >> --------------------------------------------
>> >> >> Matthew Jonkman
>> >> >> Emerging Threats
>> >> >> Phone 765-429-0398
>> >> >> Fax 312-264-0205
>> >> >> http://www.emergingthreats.net
>> >> >> --------------------------------------------
>> >> >>
>> >> >> PGP: http://www.jonkmans.com/mattjonkman.asc
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Discussion mailing list
>> >> > Discussion at openinfosecfoundation.org
>> >> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >> >
>> >> >
>> >
>> >
>
>
More information about the Discussion
mailing list