it will also give the "Btrivos" of the world an incentive to clean up their act, as the more IPs in their netblock have a bad reputation, the worse off ALL IPs in their netblock are. <br><br>Sort of like what hostexploit did by calling out the hosting provider..... Let the hosting providers know that their entire range will be negativelt impacted, with a sliding scale based on number of "bad" hosts and other parameters.... <br>
<br><br><div class="gmail_quote">On Wed, Oct 22, 2008 at 8:19 PM, Martin Holste <span dir="ltr"><<a href="mailto:mcholste@gmail.com">mcholste@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I really like that idea. It won't directly lead to blocking innocent IP's, but will still give the good guys a simple and reliable predictive capability.<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">
On Wed, Oct 22, 2008 at 7:04 PM, David Glosser <span dir="ltr"><<a href="mailto:david.glosser@gmail.com" target="_blank">david.glosser@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Back to the idea of Spam-assassin scoring:<br><br>Once a bad host is identified, then I'm wondering if IP reputation could maybe using a
"halo effect" whereby other IPs by the same provider are given lower
scores. <br>
<br>
Say reputation is from 0-100 (with 100 being bad)<br>
<br>
So if an IP on hosting provider "Btrivo" contains malware, that IP gets a reputation score of 50. <br>
Adjacent IPs are given a reputation score of 30. <br>
All of the
IPs in "Btrivo's" netblock are given a reputation score of 10. <br>
<br>
Two adjacent IP addresses each hosting malware each will get a score of 90 (50+30+10). <br>
<br>If malware goes away, score decreases each day. For each day host is still up, score increases....<div><div></div><div><br><br><br><br><div class="gmail_quote">On Mon, Oct 20, 2008 at 1:48 PM, Matt Jonkman <span dir="ltr"><<a href="mailto:jonkman@jonkmans.com" target="_blank">jonkman@jonkmans.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I agree. I know a lot of installs that use rotating tcpdump files which<br>
allows the analyst to go back and see everything that happened related<br>
to an incident. And as long as you have good disks it's a very feasible<br>
thing to do. If you're running inline you can even do the detection from<br>
these files to avoid packet loss at peak traffic flows.<br>
<br>
Definitely adding this to the list!<br>
<font color="#888888"><br>
Matt<br>
</font><div><div></div><div><br>
Jeremy wrote:<br>
> Thought of another feature I would like to see....<br>
><br>
> [not sure of the number]<br>
> I would like to see a single capture engine have the ability to<br>
> perform the analysis of the data (however that may be), and also this<br>
> same engine should be able to capture session statistics (flow data),<br>
> and full packet captures. What I mean by this is that currently I run<br>
> 3 applications on all of my IDS' to get this data. I use SANCP for<br>
> session data, Tcpdump for full packet capture and snort for IDS<br>
> functionality. I believe it would improve overall system performance<br>
> to only have one application read the packets from the capture library<br>
> such as libpcap instead of several applications having to read this<br>
> data. I know that I ran into a wall with the 32 bit architecture in<br>
> that I could only allocate small amounts of Low memory space to each<br>
> application, as the kernel can only be allocated 1 GB. This 1 GB has<br>
> to be divided up between with these three applications and well all<br>
> other applications. I recently was told you could actually allocate 2<br>
> GB low memory on a 32 bit architecture, but as of today I have not<br>
> figured out how. If you over run the low memory space reserved by the<br>
> kernel you end up with oom kills which can be really frustrating as it<br>
> will kill off applications based off some really odd/cryptic<br>
> algorithm. Anyways getting back to one application performing all<br>
> three tasks, the packet only needs to be copied once and therefore I<br>
> could allocate a substantial amount of the low memory reserved by the<br>
> kernel to this application. Now I know not everyone will want to<br>
> capture flow data, and full packet data on their IDS boxes, but if<br>
> this was a configurable option it may help some of us. I also noticed<br>
> someone else posted about SANCP indexing abilities, this would be nice<br>
> to have in the new engine as well to make correlating Session data<br>
> (flow data) to full packet captures very fast and easy. Having the<br>
> full packet captures on my IDS boxes has really helped in identifying<br>
> false positives and signature tweaking. The session data (flow data)<br>
> has proven to be an outstanding addition to our anomaly detection<br>
> capabilities.<br>
><br>
><br>
> --jeremy<br>
><br>
> On Sat, Oct 18, 2008 at 9:17 PM, th3 m0nq <<a href="mailto:th3m0nq@gmail.com" target="_blank">th3m0nq@gmail.com</a>> wrote:<br>
>> <snip><br>
>> As Robert and Martin eluded in an other<br>
>> thread, any sort of correlation and IP analysis, scoring,<br>
>> severity-bumping, etc, is best done in the analysis or portal engine.<br>
>> </snip><br>
>><br>
>> I agree here, but does next generation mean an advanced version of<br>
>> snort? Does next generation mean an evolution in terms of thinking<br>
>> about IDS/IPS? Do we leave things as they are and say that there<br>
>> exist NIDs, DIDs, HIDs, and they don't form a cohesive immune system<br>
>> for my network? I would like to see an evolution of such technologies<br>
>> be more biological in nature.<br>
>><br>
>> <snip><br>
>> I don't think any existing detection engine of an IDS is the proper place.<br>
>> But perhaps a parallel engine that collects network stream data and does<br>
>> matching on hostile IP's, and then checks (perhaps by packet/session<br>
>> timestamp) if the IDS did produce an alert in a recent time window<br>
>> (since the session-IP-eval-engine will surely lag behind)<br>
>> </snip><br>
>><br>
>> I am with you here as well. Why is the parallel engine not part of<br>
>> the IDS? Why should next generation IDS mean a better snort? Why<br>
>> can't it mean a better way of looking at network security?<br>
>> <a href="http://en.wikipedia.org/wiki/Immune_system#Layered_defense" target="_blank">http://en.wikipedia.org/wiki/Immune_system#Layered_defense</a> What about<br>
>> an all encompassing IDS/IPS _system_?<br>
>><br>
>> I am not saying I have the answers, or something similar to an expert<br>
>> system is the answer. I am saying I think the issue should be looked<br>
>> at as we dump the current way we do things in a temporary holding<br>
>> cell, and think in evolutionary terms. This makes 4 cents ;-).<br>
>><br>
>><br>
>> Adrian<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Sat, Oct 18, 2008 at 5:01 PM, Frank Knobbe <<a href="mailto:frank@knobbe.us" target="_blank">frank@knobbe.us</a>> wrote:<br>
>>> On Sat, 2008-10-18 at 16:28 -0500, th3 m0nq wrote:<br>
>>>> [..] I think there is<br>
>>>> room, at minimum, to have packets that do not necessarily trigger a<br>
>>>> rule "flagged" in some way in an IDS. This could be implemented as a<br>
>>>> plug-in component of the system. This may be way outside of the scope<br>
>>>> of what you guys are looking at, but that's my 2 cents.<br>
>>> Receiving alerts (with session content) on IP's that don't trip existing<br>
>>> signatures, but are present in a hostile-IP list, is a good idea (for<br>
>>> example, to detect new evasion techniques of existing badware).<br>
>>><br>
>>> However, I don't think the sensor is the proper place for that due to<br>
>>> the immense IP-matching workload that would have to occur on a<br>
>>> per-packet or per-session basis (remember, we're talking at least tens<br>
>>> of thousands hostile IP's). As Robert and Martin eluded in an other<br>
>>> thread, any sort of correlation and IP analysis, scoring,<br>
>>> severity-bumping, etc, is best done in the analysis or portal engine.<br>
>>> (We do those things in our shop as well, with back-end scripts and our<br>
>>> portal).<br>
>>><br>
>>> While you can make decisions on the IP "badness value" for analysis, you<br>
>>> would of course miss the content of the IP not receiving an alert. I<br>
>>> don't think any existing detection engine of an IDS is the proper place.<br>
>>> But perhaps a parallel engine that collects network stream data and does<br>
>>> matching on hostile IP's, and then checks (perhaps by packet/session<br>
>>> timestamp) if the IDS did produce an alert in a recent time window<br>
>>> (since the session-IP-eval-engine will surely lag behind). That check<br>
>>> would probably be best done against the IDS/portal database. A simple<br>
>>> bpf filter with hostile 20,000+ IP's to capture content will probably<br>
>>> not cut it :)<br>
>>><br>
>>> -Frank<br>
>>><br>
>>><br>
>>> --<br>
>>> It is said that the Internet is a public utility. As such, it is best<br>
>>> compared to a sewer. A big, fat pipe with a bunch of crap sloshing<br>
>>> against your ports.<br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> Discussion mailing list<br>
>> <a href="mailto:Discussion@openinfosecfoundation.org" target="_blank">Discussion@openinfosecfoundation.org</a><br>
>> <a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
>><br>
> _______________________________________________<br>
> Discussion mailing list<br>
> <a href="mailto:Discussion@openinfosecfoundation.org" target="_blank">Discussion@openinfosecfoundation.org</a><br>
> <a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
<br>
</div></div>--<br>
<div>--------------------------------------------<br>
Matthew Jonkman<br>
Emerging Threats<br>
Phone 765-429-0398<br>
Fax 312-264-0205<br>
<a href="http://www.emergingthreats.net" target="_blank">http://www.emergingthreats.net</a><br>
--------------------------------------------<br>
<br>
PGP: <a href="http://www.jonkmans.com/mattjonkman.asc" target="_blank">http://www.jonkmans.com/mattjonkman.asc</a><br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div>Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org" target="_blank">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Discussion mailing list<br>
<a href="mailto:Discussion@openinfosecfoundation.org" target="_blank">Discussion@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/discussion" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/discussion</a><br>
<br></blockquote></div><br>
</div></div></blockquote></div><br>