Increased abuse activity on my server
carl at chave.us
Sat Mar 10 23:35:28 UTC 2018
I always thought "port knocking" was a neat method to minimize port
exposure. Never actually used it myself but maybe worth a mention here.
On Sat, Mar 10, 2018 at 5:43 AM, User Hasse <hasse at bara1.se> wrote:
> Hello and thank you very much for your reply.
> Regarding the first part of your answer, I thought my question was
> perfectly clear
> and easy to answer. "Anybody else noticed increased abuse activity on your
> servers ?"
> and that was my sole and only question.
> But your answer was interresting to read. Specially the AWS part, that I
> was not aware of.
> So, thank you very much for your time and effort to help.
> All the best
> Geir Svalland.
> On Fri, Mar 09, 2018 at 07:30:21AM -0500, Rich Kulawiec wrote:
> > On Wed, Mar 07, 2018 at 08:19:44AM +0100, User Hasse wrote:
> > > I belive I see an increased amount of abuse attempt on my server by
> several 100%
> > > in the last couple of months. Anybody else noticed ?
> > This is a question that can't be answered because it's not correctly
> > "abuse" has many facets, and what you see on your server is totally
> > different in character, source, volume, etc., from what everyone else
> > sees. Yes, it's possible to collate many different reports from
> > disparate operations and perhaps -- MAYBE -- arrive at some general
> > conclusions about the overall state of abuse Internet-wide, and that's
> > an interesting intellectual exercise...but it's not much help to you.
> > Moreover, given the high degree of sophistication among some abusers,
> > what you see today may have little or no relationship to what you see
> > tomorrow. So reacting to recent events, while not necessarily bad, may
> > not avail you much in the long term.
> > A better approach is to be pro-active. Not only should you turn off
> > all services that you don't need, but you should block access to them
> > from every part of the world that doesn't have an operational need for
> > For example:
> > Suppose you run an ssh server. And suppose that you only need to allow
> > access to it from the US, Canada, and the UK. Then (a) put in a
> > rule that denies access globally and (b0 add rules to allow access from
> > only those three countries. (See ipdeny.com for the network blocks.)
> > This does *nothing* to stop ssh abuse from the US/CA/UK, but it does
> > *everything* to stop it from the rest of the world. (Yes, I'm aware
> > of proxies and VPNs.)
> > The next step is to look at the ssh abuse coming from cloud operations:
> > for example, AWS is a notorious, chronic, systemic source of abuse and
> > attacks because the people running it are incompetent and negligent.
> > Block it. All of it. Because unless you have an operational need for
> > personnel to ssh in from there, there's no reason not to. Repeat with
> > other cloud operations that behave in a similarly hostile fashion.
> > And then keep track of where further abuse comes from. Keep the logs
> > and look at the statistics over a day/week/month/year. Other entries
> > for firewalls will suggest themselves. Use them.
> > This is a *vastly* better approach than attempting to react on the fly
> > with things like fail2ban. It shuts down the abuse -- at least from
> > the sources you enumerate -- permanently. After all, if someone out
> > there insists on providing you with evidence of their malicious intent
> > all day every day, how much evidence do you need to see before you
> > believe them? And if you believe them, why in hell would you continue
> > to provide them with services?
> > The same approach works with pops and imaps and other services. Firewall
> > out every place that will never need them, then start firewalling out
> > every place that attacks them. If you're careful and diligent about
> > then over time you'll find that it gets easier -- because there's less
> > and less to deal with. Of course it never stops entirely: there are
> > always newly-emerging sources of abuse. But this approach drastically
> > reduces the scale of the problem and makes it tractable. It works
> > in nearly all production environments with a few exceptions -- and
> > you're not one of those.
> > ---rsk
> > _______________________________________________
> > freebsd-questions at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "freebsd-questions-
> unsubscribe at freebsd.org"
More information about the freebsd-questions