| Ronald Guilmet on 28 Aug 2018 11:29:26 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] Linux tip: Log IP addresses, not hostnames, for use by fail2ban... |
Ron G On 8/28/2018 2:14 PM, Keith C. Perry wrote:
"AWS has been a chronic, systemic source of brute-force attacks (against ssh, for example) and abuse for years. AWS refuses to accept complaints via RFC 2142-mandated role addresses, preferring instead to force victims of its incompetence and negligence to jump through hoops and fill out a form that doesn't actually facilitate accurately reporting the complaint. And when that's done, they ignore the complaints. (This is now so well known that nobody with any clue even bothers filing them any more.)" YES... this need to go on a billboard or at least be shouted from on high. I gave up on this before the obsession with cloud and even though I take a different approach, I fully support network and security professionals that refuse to give in and allow traffic from problem networks, even if that problem network is the "popular" kid. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Keith C. Perry, MS E.E. Managing Member, DAO Technologies LLC (O) +1.215.525.4165 x2033 (M) +1.215.432.5167 www.daotechnologies.com ----- Original Message ----- From: "Rich Kulawiec" <rsk@gsp.org> To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org> Sent: Monday, August 27, 2018 4:41:35 PM Subject: Re: [PLUG] Linux tip: Log IP addresses, not hostnames, for use by fail2ban... On Sat, Aug 25, 2018 at 02:31:34PM -0400, Fred Stluka wrote:I'm just trying to block hackers without losing the ability to know who they are, where they come from, and what tricks they are trying.??As I said, if you're doing research, then fine. A good way to do that is to stand up a hardened server running something like OpenBSD and run dummy servers for things like SMTP, HTTP, etc., log every packet, and go to work. And if you want to invest the massive quantity of time that it'll take to do that: be my guest. But unless you invest heavily in research, you probably won't learn anything that we don't already know... which I can summarize for you as "expect every form of attack against every service you run from hundreds of millions of IP addresses scattered across companies, ISPs, universities, etc. in Chinese IP space. Expect it to go on nonstop for decades. Expect your complaints to be ignored or met with reliation (because you've either sent them to the abusers or to people who will forward them to the abusers)." I'm not knocking the intellectual exercise: I do quite a bit of research in this area myself. But it's not appropriate for a production operation. There, the right approach is to firewall and forget, because we now live in a world of 0-days and the tomorrow could be the day that an attack arrives for which there exists no defense...other than preventing it from reaching its target(s). It's one thing succumb to an attack that came from Dallas. It's quite another to succumb to one when it came from Quito and you had absolutely no operational requirement whatsoever to ever permit a single packet from Ecuador to get anywhere near your servers *and* you could have stopped it cold years before it happened with a few minutes' work. Let me pause to note that I don't like this. Not at all. This isn't the Internet that I hoped for, all those years ago. But this is the Internet we have, and no amount of wishful thinking will change that. The default-permit philosophy that we used for a very long time is no longer viable, and default-deny needs to be the rule.If I block all of China, I lose the ability to learn how best to allow some of China in safely, which I may need to know for a client some day.No. You don't. If you need to allow a network in China in, then you look up the relevant allocation and add that network to an exemption list. It's trivial. Although: should you find yourself in that situation, you really might want to consider standing up a separate server solely to handle traffic from dubious IP space, and isolating it from the rest of your operation. I've done that (although not with China): there's a proxy mail server out there which isn't reachable from most of the Internet but *is* reachable from a few select networks that would otherwise be blocked. It's bandwidth-throttled, it's hardened, it's not able to initiate outbound connections to anything, etc., and its job is to carefully (and slowly) accept the small amount of SMTP traffic that it needs to.Also, I'd guess that these days most hackers have access to botnets that span multiple countries [...]Yes, they do. But (1) hold that thought for a moment and (2) the existence of multinational botnets does not invalidate the per-country blocking approach even a little bit.And if so, what other countries should I block entirely?You should block *any* country that you can, precisely because of the observation you just made. In fact, if you can block the planet (from certain or all services) you should, and then only allow the countries that you must. For example: an awful lot of US-based operations do not need to allow incoming ssh connections from anywhere but the US. Best practice is therefore to block all, then allow US-only modulo things like the DROP list, Digital Ocean, etc. (Yes, I know people travel. Open up a hole for the applicable countries for the applicable duration, then close it. This isn't hard.)BTW, what's your beef with AWS anyhow???AWS has been a chronic, systemic source of brute-force attacks (against ssh, for example) and abuse for years. AWS refuses to accept complaints via RFC 2142-mandated role addresses, preferring instead to force victims of its incompetence and negligence to jump through hoops and fill out a form that doesn't actually facilitate accurately reporting the complaint. And when that's done, they ignore the complaints. (This is now so well known that nobody with any clue even bothers filing them any more.) And one of the things that I like to point out is that sustained outbound abuse and attacks from any operation are a surface indicator of underlying security issues. (Because secure, well-run operations *do not exhibit this behavior on a chronic/systemic basis*.) They don't tell you what those issues are. They don't tell you why they exist. They don't tell you who's exploiting them. But they're an existence proof. ---rsk ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug