[prev in list] [next in list] [prev in thread] [next in thread]
List: snort-users
Subject: Re: [Snort-users] Whitelisting my entire internal network - bad idea. What else can I do?
From: "Scott A. Wozny via Snort-users" <snort-users () lists ! snort ! org>
Date: 2020-03-06 18:13:03
Message-ID: CH2PR02MB68088EE38BBE20607DABED5DA8E30 () CH2PR02MB6808 ! namprd02 ! prod ! outlook ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
Unfortunately, I don't know what mechanism you're using to block IPs (that, \
apparently, you need to manually clear) so I can't suggest a practical solution, just \
a conceptual one. Perhaps someone on the list recognizes the feature you're using by \
description and can suggest how to tune it. I'm just getting back into snort after a \
few years absence so I don't have a good handle on all the available features, yet. \
When I was managing an operational snort install I only did blocking of individual \
packets based upon signatures that were extremely unlikely to not be actual security \
events (of which, http_inspect signatures did NOT qualify) and didn't auto-shun IPs \
(I'm not even sure that was a feature in the versions I used). I ran a lot of \
signatures (including classically noisy ones like icmp net and host unreachable) so I \
could watch my daily reports for changes in the network traffic profile but I was \
REALLY judicious about what caused snort to block a packet, as a result.
As far as turning individual events into useful comments to developers is concerned, \
there is no real shortcut to that other than digging into the packet capture, seeing \
how that packet tripped the rule and then going back to the developer to see what can \
be done about it. In my experience, though, that was MUCH easier said than done. In \
my environment, the developers were renowned for their "not my department" attitude \
and often claimed that all they did was write API calls and if the CMS was doing \
weird stuff there wasn't anything they could do about it. The CMS vendor, of \
course, would point the finger back at the developers or the HTTP servers or just \
claim that if we weren't running on their absolute latest version they couldn't help. \
I eventually gave up and just expected a certain low hum of these events in the \
background at all times.
I guess what I'm saying is rather than whitelisting your entire home network (if that \
would even accomplish what you're looking for) I'd go back to the feature that's \
causing you the operational headache (the auto-shunning of IPs that you need to \
manually intervene in each time it happens) and do a deep dive into that feature's \
configuration to see if http_inspect can be removed from the equation because it's \
such a notoriously chatty signature set for things that often aren't actual security \
issues. But I can't give you a more "click here and check this" level of practical \
advice. With any luck, someone on this list can.
Scott
________________________________
From: Jess Canada <Jess@thinkdatasmart.com>
Sent: March 5, 2020 4:48 PM
To: Scott A. Wozny <sawozny@hotmail.com>; snort-users@lists.snort.org \
<snort-users@lists.snort.org>
Subject: RE: Whitelisting my entire internal network - bad idea. What else can I do?
Thanks for your reply. How do I "not permit http_inspect rule firings to contribute \
to the blocking of IPs?"
I found a section on http_inspect in the interface Prepoc settings, but there was a \
big warning about not changing any of it unless you're an advanced user and really \
know what you're doing, so I'm afraid to mess with it.
I would not be surprised if we do have misconfigured web servers. Unfortunately I \
have no idea how to turn that into a userful comment for our web developer, so I \
think I just have to deal with it.
The screen shot did list times in the past that those IPs had been blocked, but I had \
cleared the block previously in each of those cases. I don't know why that info stays \
around, but when it blocks something it is based just off a recent event.
Thanks,
Jess Canada
jess@thinkdatasmart.com<mailto:jess@thinkdatasmart.com>
From: Scott A. Wozny <sawozny@hotmail.com>
Sent: Tuesday, March 3, 2020 11:11 AM
To: Jess Canada <Jess@thinkdatasmart.com>; snort-users@lists.snort.org
Subject: Re: Whitelisting my entire internal network - bad idea. What else can I do?
IMHO the best way to handle this is to not permit http_inspect rule firings to \
contribute to the blocking of IPs (you didn't indicate whether these user's sessions \
are failing because these rules are blocking individual critical packets it considers \
"bad" causing the whole session to fall over or because the user's IP gets such a bad \
reputation over time that snort decides to block all of it's traffic, going forward).
The http_inspect rules (in my experience) fire almost exclusively because of (badly \
written || misconfigured) (web servers || web pages) and when I was using Snort \
operationally, there was almost never anything I could do about them (so, while not a \
false positive in that they're actually firing based upon the correct bit pattern, \
they're nearly never an actual security event in and of themselves). To me, it \
didn't represent a threat but made a good canary for more subtle protocol fuzzing \
probes so I kept those rules in my daily reports looking for anomalous behaviour / \
bad actors but I never took any automated action based upon them.
So, rather than whitelisting your home network (which, as you said, acts counter to \
your desire to monitor what's going on within your system) maybe focus on turning off \
direct blocking on http_inspect rules in general (rather than individually, as you've \
indicated you've done) or configuring whatever you're doing to auto-block from taking \
http_inspect rule firings into account (if that's what's actually happening here).
A third alternative (if it's possible) is that I noticed in your screen shot that the \
block appears to be justified by events occurring over many months. Is there a way \
to tune that process to "forgive" bad packets after a while instead of holding a \
grudge forever (if that's what's actually happening)? I can't tell from the screen \
shot, but I noticed how old some of those rule firings were and I would never take \
action based upon events from that long ago. I mean, there's "low and slow" but that \
would be kind of ridiculous. 🙂
HTH and best of luck,
Scott
________________________________
From: Snort-users <snort-users-bounces@lists.snort.org<mailto:snort-users-bounces@lists.snort.org>> \
on behalf of Jess Canada \
<Jess@thinkdatasmart.com<mailto:Jess@thinkdatasmart.com>>
Sent: March 2, 2020 7:21 PM
To: snort-users@lists.snort.org<mailto:snort-users@lists.snort.org> \
<snort-users@lists.snort.org<mailto:snort-users@lists.snort.org>>
Subject: [Snort-users] Whitelisting my entire internal network - bad idea. What else \
can I do?
Hi everyone,
We started using Snort on pfSense a few months ago. One problem that has been \
frequent for us is the IPs for our internal VMs getting blocked over false positives. \
We connect via VPN to a 10.0.0.0/8<http://10.0.0.0/8> network with about 15 VMs. \
Often my users will be unable to connect due to the VM they're trying to connect to \
being blocked. I will unblock it as soon as I get a report, but it is especially \
problematic when I am not at the office.
I have been disabling the rules that seem to cause them the most, and for the most \
part this has been successful lately. However, twice last week users were unable to \
connect. In frustration I whitelisted the entire 10.0.0.0/8<http://10.0.0.0/8> \
network. I know this is not ideal, as one of the reasons we wanted to use Snort was \
that it could detect if data was exfiltrating from our VMs, for example, and this \
would prevent that detection. So on the other hand I have the ability to disable the \
rules that cause problems the most, but isn't it possible that those rules may \
occasionally pick up something significant and shouldn't be disabled, either?
What's the best way to handle this? I'm sorry I don't have much experience yet. I've \
attached a file showing the most recent blocked IPs I had to clear. Thanks for your \
help.
-Jess Canada
jess@thinkdatasmart.com<mailto:jess@thinkdatasmart.com>
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} \
</style> </head>
<body dir="ltr">
<div>
<div id="appendonsend" style="font-family: Calibri, Helvetica, sans-serif; font-size: \
12pt; color: rgb(0, 0, 0);"> Unfortunately, I don't know what mechanism you're using \
to block IPs (that, apparently, you need to manually clear) so I can't suggest a \
practical solution, just a conceptual one. Perhaps someone on the list \
recognizes the feature you're using by description and can suggest how to tune \
it. I'm just getting back into snort after a few years absence so I don't have \
a good handle on all the available features, yet. When I was managing an \
operational snort install I only did blocking of individual packets based upon \
signatures that were extremely unlikely to not be actual security events (of which, \
http_inspect signatures did NOT qualify) and didn't auto-shun IPs (I'm not even sure \
that was a feature in the versions I used). I ran a lot of signatures \
(including classically noisy ones like icmp net and host unreachable) so I could \
watch my daily reports for changes in the network traffic profile but I was REALLY \
judicious about what caused snort to block a packet, as a result.</div> <div \
style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, \
0);"> <br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: \
rgb(0, 0, 0);"> As far as turning individual events into useful comments to \
developers is concerned, there is no real shortcut to that other than digging into \
the packet capture, seeing how that packet tripped the rule and then going back to \
the developer to see what can be done about it. In my experience, though, that \
was MUCH easier said than done. In my environment, the developers were renowned \
for their "not my department" attitude and often claimed that all they did \
was write API calls and if the CMS was doing weird stuff there wasn't anything \
they could do about it. The CMS vendor, of course, would point the finger back \
at the developers or the HTTP servers or just claim that if we weren't running on \
their absolute latest version they couldn't help. I eventually gave up and \
just expected a certain low hum of these events in the background at all times.<br> \
</div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: \
rgb(0, 0, 0);"> I guess what I'm saying is rather than whitelisting your entire home \
network (if that would even accomplish what you're looking for) I'd go back to the \
feature that's causing you the operational headache (the auto-shunning of IPs that \
you need to manually intervene in each time it happens) and do a deep dive into that \
feature's configuration to see if http_inspect can be removed from the equation \
because it's such a notoriously chatty signature set for things that often aren't \
actual security issues. But I can't give you a more "click here and check \
this" level of practical advice. With any luck, someone on this list \
can.</div> <div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; \
color: rgb(0, 0, 0);"> <br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: \
rgb(0, 0, 0);"> Scott<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: \
rgb(0, 0, 0);"> <br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> <br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, \
sans-serif" color="#000000"><b>From:</b> Jess Canada \
<Jess@thinkdatasmart.com><br> <b>Sent:</b> March 5, 2020 4:48 PM<br>
<b>To:</b> Scott A. Wozny <sawozny@hotmail.com>; snort-users@lists.snort.org \
<snort-users@lists.snort.org><br> <b>Subject:</b> RE: Whitelisting my entire \
internal network - bad idea. What else can I do?</font> <div> </div>
</div>
<div lang="EN-US">
<div class="x_WordSection1">
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> Thanks for your reply. How do I "<span \
style="font-size:12.0pt; color:black">not permit http_inspect rule firings to \
contribute to the blocking of IPs?"</span></p> <p class="x_MsoNormal" style="margin: \
0in 0in 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;"> \
<span style="font-size:12.0pt; color:black"> </span></p> <p class="x_MsoNormal" \
style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: "Calibri", \
sans-serif;"> <span style="font-size:12.0pt; color:black">I found a section on \
http_inspect in the interface Prepoc settings, but there was a big warning about not \
changing any of it unless you're an advanced user and really know what you're doing, \
so I'm afraid to mess with it. </span></p>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> <p class="x_MsoNormal" style="margin: 0in 0in \
0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;"> <span \
style="font-size:12.0pt; color:black">I would not be surprised if we do have \
misconfigured web servers. Unfortunately I have no idea how to turn that into a \
userful comment for our web developer, so I think I just have to deal with it. \
</span></p> <p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> <p class="x_MsoNormal" style="margin: 0in 0in \
0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;"> <span \
style="font-size:12.0pt; color:black">The screen shot did list times in the past that \
those IPs had been blocked, but I had cleared the block previously in each of those \
cases. I don't know why that info stays around, but when it blocks something it is \
based just off a recent event.</span></p> <p class="x_MsoNormal" style="margin: 0in \
0in 0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;"> <span \
style="font-size:12.0pt; color:black"> </span></p> <p class="x_MsoNormal" \
style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: "Calibri", \
sans-serif;"> <span style="font-size:12.0pt; color:black">Thanks,</span></p>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> <p class="x_MsoNormal" style="margin: 0in 0in \
0.0001pt; font-size: 11pt; font-family: "Calibri", sans-serif;"> <span \
style="font-size:12.0pt; color:black">Jess Canada</span></p> <p class="x_MsoNormal" \
style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: "Calibri", \
sans-serif;"> <span style="font-size:12.0pt; color:black"><a \
href="mailto:jess@thinkdatasmart.com">jess@thinkdatasmart.com</a></span></p> <p \
class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> </p>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> </p>
<div>
<div style="border:none; border-top:solid #E1E1E1 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <b>From:</b> Scott A. Wozny \
<sawozny@hotmail.com> <br> <b>Sent:</b> Tuesday, March 3, 2020 11:11 AM<br>
<b>To:</b> Jess Canada <Jess@thinkdatasmart.com>; \
snort-users@lists.snort.org<br> <b>Subject:</b> Re: Whitelisting my entire internal \
network - bad idea. What else can I do?</p> </div>
</div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> </p>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; color:black">IMHO \
the best way to handle this is to not permit http_inspect rule firings to contribute \
to the blocking of IPs (you didn't indicate whether these user's sessions are failing \
because these rules are blocking individual critical packets it considers \
"bad" causing the whole session to fall over or because the user's IP gets \
such a bad reputation over time that snort decides to block all of it's traffic, \
going forward). </span></p>
</div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; color:black">The \
http_inspect rules (in my experience) fire almost exclusively because of (badly \
written || misconfigured) (web servers || web pages) and when I was using Snort \
operationally, there was almost never anything I could do about them (so, while not \
a false positive in that they're actually firing based upon the correct bit pattern, \
they're nearly never an actual security event in and of themselves). To me, it \
didn't represent a threat but made a good canary for more subtle protocol fuzzing \
probes so I kept those rules in my daily reports looking for anomalous behaviour / \
bad actors but I never took any automated action based upon them.</span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; color:black">So, \
rather than whitelisting your home network (which, as you said, acts counter to your \
desire to monitor what's going on within your system) maybe focus on turning off \
direct blocking on http_inspect rules in general (rather than individually, as \
you've indicated you've done) or configuring whatever you're doing to auto-block from \
taking http_inspect rule firings into account (if that's what's actually happening \
here).</span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; color:black">A \
third alternative (if it's possible) is that I noticed in your screen shot that the \
block appears to be justified by events occurring over many months. Is there a \
way to tune that process to "forgive" bad packets after a while instead of \
holding a grudge forever (if that's what's actually happening)? I can't tell \
from the screen shot, but I noticed how old some of those rule firings were and I \
would never take action based upon events from that long ago. I mean, there's \
"low and slow" but that would be kind of ridiculous. </span><span \
style="font-size:12.0pt; font-family:"Segoe UI Emoji",sans-serif; \
color:black">🙂</span><span style="font-size:12.0pt; color:black"></span></p> \
</div> <div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; color:black">HTH \
and best of luck,</span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> </div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black">Scott</span></p> </div>
<div>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <span style="font-size:12.0pt; \
color:black"> </span></p> </div>
<div class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;text-align:center" align="center"> <hr \
width="98%" size="2" align="center"> </div>
<div id="x_divRplyFwdMsg">
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> <b><span style="color:black">From:</span></b><span \
style="color:black"> Snort-users <<a \
href="mailto:snort-users-bounces@lists.snort.org">snort-users-bounces@lists.snort.org</a>> \
on behalf of Jess Canada <<a \
href="mailto:Jess@thinkdatasmart.com">Jess@thinkdatasmart.com</a>><br> \
<b>Sent:</b> March 2, 2020 7:21 PM<br> <b>To:</b> <a \
href="mailto:snort-users@lists.snort.org">snort-users@lists.snort.org</a> <<a \
href="mailto:snort-users@lists.snort.org">snort-users@lists.snort.org</a>><br> \
<b>Subject:</b> [Snort-users] Whitelisting my entire internal network - bad idea. \
What else can I do?</span> </p>
<div>
<p class="x_MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: \
"Calibri", sans-serif;"> </p>
</div>
</div>
<div>
<div>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> Hi everyone,</p>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> </p>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> We started using Snort on pfSense a \
few months ago. One problem that has been frequent for us is the IPs for our internal \
VMs getting blocked over false positives. We connect via VPN to a <a \
href="http://10.0.0.0/8">10.0.0.0/8</a> network with about 15 VMs. Often my \
users will be unable to connect due to the VM they're trying to connect to being \
blocked. I will unblock it as soon as I get a report, but it is especially \
problematic when I am not at the office. </p>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> </p>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> I have been disabling the rules that \
seem to cause them the most, and for the most part this has been successful lately. \
However, twice last week users were unable to connect. In frustration I whitelisted \
the entire <a href="http://10.0.0.0/8">10.0.0.0/8</a> network. I know this is not \
ideal, as one of the reasons we wanted to use Snort was that it could detect if data \
was exfiltrating from our VMs, for example, and this would prevent that detection. So \
on the other hand I have the ability to disable the rules that cause problems the \
most, but isn't it possible that those rules may occasionally pick up something \
significant and shouldn't be disabled, either?</p> <p class="x_xmsonormal" \
style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: "Calibri", \
sans-serif;"> </p>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> What's the best way to handle this? \
I'm sorry I don't have much experience yet. I've attached a file showing the most \
recent blocked IPs I had to clear. Thanks for your help.</p> <p class="x_xmsonormal" \
style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: "Calibri", \
sans-serif;"> </p>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;">
-Jess Canada</p>
<p class="x_xmsonormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; \
font-family: "Calibri", sans-serif;"> <a \
href="mailto:jess@thinkdatasmart.com">jess@thinkdatasmart.com</a></p> </div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
_______________________________________________
Snort-users mailing list
Snort-users@lists.snort.org
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users
To unsubscribe, send an email to:
snort-users-leave@lists.snort.org
Please visit http://blog.snort.org to stay current on all the latest Snort news!
Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette
--===============6303922049832358046==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic