Increased abuse activity on my server

[Carl Chave]

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
> asked.
> >
> > "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
> them.
> >
> > 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
> firewall
> > 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
> this,
> > 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"
>