Date: Sat, 10 Mar 2018 11:43:54 +0100 From: User Hasse <hasse@bara1.se> To: Rich Kulawiec <rsk@gsp.org> Cc: freebsd-questions@freebsd.org Subject: Re: Increased abuse activity on my server Message-ID: <20180310104354.GA11201@ymer.bara1.se> In-Reply-To: <20180309123021.GA9355@gsp.org> References: <20180307071944.GA30971@ymer.bara1.se> <20180309123021.GA9355@gsp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello and thank you very much for your reply. Regarding the first part of your answer, I thought my question was perfectl= y 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 wa= s not aware of. So, thank you very much for your time and effort to help. All the best Geir Svalland. =20 ------------------------------------------ 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 sev= eral 100% > > in the last couple of months. Anybody else noticed ? >=20 > This is a question that can't be answered because it's not correctly aske= d. >=20 > "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. >=20 > 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. >=20 > 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 th= em. >=20 > For example: >=20 > 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.) >=20 > 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.) >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > ---rsk > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o= rg" --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEZmmwl+ajAr4eHVHbDLsBtTa490kFAlqjtuJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDY2 NjlCMDk3RTZBMzAyQkUxRTFENTFEQjBDQkIwMUI1MzZCOEY3NDkACgkQDLsBtTa4 90kmTAf/b5ZwvwhbxObLcP/IBJt+7+iqMkHExeY9p6B2S9iG8mtkYfa5r9Fukd4M MgiLLkSnhOqabDv0oAzdegPp9wER4UK4v/4r2BICzanp+lcwJRj/5h0UjHdal7/C 5jak3OGyiU07TUAW6sBPUrW+Zfr/wCJ19JtIJxg81TY5Y0hDCgkhWko5ug1iZiPa h7AIe74q2QuabymbdUmCD/sG3GJ25oPLOaEvn3v89oXHoGIWQLOUzYkw0Fb3wXsu Sl0fMb0i3vrjGwkaskt1OwkW1JDVBlxtYfJA2e1iDY1Ea8DUsEgJ/eq3vUBHHybZ q42uWokPAvP5pLTSNmKLnQZwyVoDBg== =czMn -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180310104354.GA11201>