From owner-freebsd-questions@freebsd.org Fri Mar 9 12:48:29 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96D25F4B663 for ; Fri, 9 Mar 2018 12:48:29 +0000 (UTC) (envelope-from rsk@gsp.org) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "taos.firemountain.net", Issuer "taos.firemountain.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2638B7570B for ; Fri, 9 Mar 2018 12:48:28 +0000 (UTC) (envelope-from rsk@gsp.org) Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.15.1/8.14.9) with SMTP id w29CUMTL014034 for ; Fri, 9 Mar 2018 07:30:22 -0500 (EST) Date: Fri, 9 Mar 2018 07:30:21 -0500 From: Rich Kulawiec To: freebsd-questions@freebsd.org Subject: Re: Increased abuse activity on my server Message-ID: <20180309123021.GA9355@gsp.org> References: <20180307071944.GA30971@ymer.bara1.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180307071944.GA30971@ymer.bara1.se> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 12:48:29 -0000 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