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

Tue Oct 4 17:21:47 UTC 2016

I hate Webiron. They never marked any of my IP abuses as resolved, even
though I responded and revised my exit policy within 24 hours of the
complaint.

On Oct 4, 2016 12:10 PM, "Markus Koch" <niftybunny at googlemail.com> wrote:

> 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/a3c1ac6f/attachment.html>