[tor-relays] Intrusion Prevention System Software - Snort or Suricata

Tue Oct 4 17:49:50 UTC 2016

Hello,

I'm the ISP technician who is negotiating with Paul who started this thread.
I just read this whole discussion and I think that there are few things 
which need to be mentioned.

The threat of blocked subnet is real. It happened once to us and we don't 
want to experience that anymore. Imagine a few hundreds angry customers, who
are bombing your support and writing all over the internet about your awful 
services. The worst thing is, that you can't do anything about it, but wait 
to some authority to confirm your delist request. Then you spend few days/
weeks searching the newly created discusion threads and keep explaining what
happened. That costs a lot of money and energy. The prevention is the best 
solution.

Nowadays IPS can be handled by the owner to filter just what he wants to be 
filtered. It's not a rocket science. We are using IPS for our webhosting and
mailserver segment and I can say it can save work of 2-3 people, who would 
otherwise constantly write to clients to put some hotfix to their system / 
change their password / etc. 

It would be fine, if you start seek for solution how to stop malicious 
activity comming out of the tor exit nodes and stop seeking reasons why not 
to do that.

Freedom is very important to me, but freedom of one ends where the other 
begins.

Petr

"100% agreed.

Just let us kick out the bots ...

Offending/Source IP: 95.85.45.159
- Issue: Source has attempted the following botnet activity:
Semalt Referrer Spam Tor Exit Bot

I am not in for free speech for bots and anything without a pulse.

markus

Hello!

=== You are receiving this e-mail in regard to abuse issues against
our clients coming from the host at IP 95.85.45.159. ===

--- Automated Message - To get a response or report issues with the
reports, please see the contact info below. ---
--- Report details are at the bottom of the e-mail. For web attacks
see the "bot" links for more details about the attack. ----

Webiron is a security service and this e-mail is being sent on behalf
of our customers. We do not control how our clients configure their
protection and as a result do not control how blocks and bans are
generated.

We are committed to providing useful information on abuse issues on
behalf of our clients to help stop issues related to issues that seem
to originate from within your network.

We value your time and effort and appreciate your assistance in
handling these issues!

If you are responsible for abuse issues however the IP being reported
does not belong to you, please open a ticket or email us to let us
know of the error and we'll correct it as soon as possible.

Please note due to the retaliatory nature of attackers and the
abundance of internet abuse havens and fake hosting companies, we do
not give out the exact IP of our clients. If you require further
assistance we will be more than happy to work with you. Just open a
ticket our contact us with the details below.

-- Who We Are --
A little about our service, we are a server protection solution
designed to help hosting companies, their customers, and SoC
departments improve their system security, stability and lower TCO and
support costs.

Please feel free to send us your comments or responses. If you are
inquiring for more information you must disclosed the offending IP.
To contact us via e-mail, use <support at webiron.com>, however if you
require a ticket tracked response you can open one at
https://www.webiron.com/abuse-soc-issues.html

-- Abuse Criteria --
To be considered abusive a bot must either be a clear danger (IE:
exploit attempts, flooding, etc) or match at least two items from the
list athttps://www.webiron.com/supporthome/view-article/33-criteria-for-what
-makes-a-bot-bad.html

-- Removal Requests --
To be removed entirely from future reports reply to this e-mail with
REMOVE (in all caps) in the subject line. Please note this will only
stop the e-mail to the address the e-mail was sent to and public
notices will remain as your abuse address will be listed on our BABL
blacklist.

-- Feed/History Links --
IP Abuse Feed: https://www.webiron.com/abuse_feed/95.85.45.159
IP Detailed Information: https://www.webiron.com/iplookup/95.85.45.159
Your Abuse Report History:
https://www.webiron.com/abuse_feed/abuse@digitalocean.com

--- Blacklist Warning ---
In an ongoing effort to stop chronic abuse we maintain several
blacklists available as flat data or free public DNSRBL.

For more information see: https://www.webiron.com/rbl.html

To check the blacklist status of the offending IP, see:
https://www.webiron.com/iplookup/95.85.45.159

-- NEW --
We have now opened access to our RBL API allowing direct access to the
entire RBL database. For more information please
see:https://www.webiron.com/rbl.html

Thank you for your support,

The WebIron Team

----------------------------------------------------------
*** Note *** - All times are in America/Phoenix (-07:00)
----------------------------------------------------------

Unwanted and or Abusive Web Requests:

Offending/Source IP: 95.85.45.159
- Issue: Source has attempted the following botnet activity:
Semalt Referrer Spam Tor Exit Bot
- Block Type: New Ban
- Time: 2016-10-04 00:33:54-07:00
- Port: 80
- Service: http
- Report ID: ff681d81-5ce4-4329-8890-49642bd24a77
- Bot Fingerprint: d5930168c39511ee975f5943a5f3faac
- Bot Information:
https://www.webiron.com/bot_lookup/d5930168c39511ee975f5943a5f3faac
- Bot Node Feed:
https://www.webiron.com/bot_feed/d5930168c39511ee975f5943a5f3faac
- Abused Range: 45.79.79.0/24
- Requested URI: /
- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36

2016-10-04 18:46 GMT+02:00 Moritz Bartl <moritz at torservers.net>:
> On 10/04/2016 06:23 PM, Tristan wrote:
>> Wouldn't it be interesting if we could set up some kind of central "Tor
>> Abuse Center" where all the complaints go, and all the relay operators
>> can help respond to them. I suppose it would be pretty chaotic though...
>
> We actually discussed this briefly again at the recent Tor developers
> meeting, and it comes up every once in a while. It's an interesting
> thought experiment, and it would not take much to turn ourselves into an
> Abuse Management provider. I've seen this actually exists in the
> commercial space.
>
> One thing that makes it hard is that there's no assurance that someone
> is really only running an exit on a certain IP address; even if the
> Abuse Management Service verified that that IP address was a Tor exit at
> that point in time, it cannot in all honesty state that in fact the exit
> relay process caused a particular network activity or not.
>
> I do think we can operate this "in good faith", and we simply cannot set
> it up in a way that we can make it impossible to misuse.
>
> Still, this will not help in this (and related) cases: I have not yet
> seen proven cases where the reputation of the netblock was endangered,
> but if an ISP is afraid of that, there's no good way to cooperate. An
> IDS is their obvious suggestion, which just shows that they don't
> understand how Tor works. I argue strongly against deploying such
> systems on Tor exits. It will mess up more than it does good, and it
> won't be able to reliably detect *and block* bad behaviour.
>
> --
> Moritz Bartl
> https://www.torservers.net/
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list
tor-relays at lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20161004/7703934d/attachment-0001.html>