| Fred Stluka on 31 Aug 2018 15:19:24 -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... |
Rich, Yeah, I've seen lots of systematic attacks like that. Distributed, slow brute-force attacks. Any yes, sometimes they come from a single subnet. But often they don't. Botnets can be very widely distributed, across ISPs, countries, etc. If you lock down fail2ban tightly enough, it can block them all. It's odd that you have so much trouble with 104.248.0.0/16 specifically. I have a log of every IP address that I've ever looked into in the past 3.5 years. It includes all the ones that ever tried to play fast and loose to get around fail2ban, by doing things like attacking less frequently, retrying just after the fail2ban ban typically expires, etc. I just grepped it for "104.248" and found no matches at all. This tells me that every single attack from there has been blocked immediately by fail2ban. Not bad for a "half-ass measure", I'd say. I suspect this is at least partly because I configure fail2ban to block more aggressively and for longer than its default settings. After 2 failed attempts in a day, I block for a week. But, I didn't always do that. I haven't checked my logs from earlier decades, but even during this recent 3.5 year period, there were times when I used less aggressive settings on some servers, and found myself doing manual blocks more often. Still, fail2ban seems to have always blocked all attacks from 104.248.0.0/16 before I even noticed them. Do you suggest that I turn fail2ban off completely, and rely on a static set of firewall rules to block all attackers? Keep a list of all IP addresses of all servers, desktops, laptops and phones of all of my legitimate users. Keep that list current over time, and manually maintain my static firewall to trust those IP addresses completely? Sounds like a lot of work. And what if one of those devices gets infected with malware that tries to break into my server from one of those trusted IP addresses? Why not let fail2ban catch it? Why would I ever turn fail2ban off? It's a very valuable tool in my toolkit. --Fred ------------------------------------------------------------------------ Fred Stluka -- Bristle Software, Inc. -- http://bristle.com #DontBeATrump -- Make America Honorable Again! ------------------------------------------------------------------------ On 8/29/18 8:01 AM, Rich Kulawiec wrote:
On Tue, Aug 28, 2018 at 02:53:02PM -0400, Rich Freeman wrote:2. Maybe at some point an openssh zero day comes out, and it takes more than a few connection attempts to exploit it. Fail2ban could save your bacon. While I also don't advocate for blocking all of China/etc, I do have to admit that this could help protect you from zero days that require a single attempt to work [snip]To be clear, I'm suggesting that the best approach (unless you have an operational requirement to do otherwise) is to drop *all* traffic that you can from China (and Korea, and from other countries and networks elsewhere), not merely ssh. If you don't need it, then all possible outcomes of allowing it are bad for you and potentially good for attackers -- who, by the way, can do far more than just exploit 0-days. They can perform reconaissance, slow/distributed brute-force attacks, redirection attacks, etc. Of course, attackers with highly distributed resources may be able to find ways around it. But (a) that's not a valid reason for making their lives easier (b) depending on their methodology and resources, they may not (c) greatly reducing the volume of incoming attacks makes it much easier to see the remaining ones (d) and to take action on them. (Do not underestimate the value of (c) and (d).) This seems an apropos time to share the wisest thing I've ever read on the NANOG mailing list. Unsurprisingly, it comes from one of the most experienced people on the 'net: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie Let me give you a timely example of what I mean in the first paragraph above. This is a tiny snippet of a much larger log, and I've edited it to conceal some of the information. ssh root valid invalid address --- --- --- --- --- 8 1 0 7 104.248.A.B 8 1 0 7 104.248.C.D 8 1 0 7 104.248.E.F 8 1 0 7 104.248.G.H That happened within a 24-hour period. Four distinct addresses within the same /16 (which belongs to Digital Ocean) made exactly 8 attempts against ssh, exactly 1 each against root and exactly 7 each against invalid user names. Some pointed questions (rhetorical "you" throughout): 1. Do you think this is a coincidence? 2. Do you think this was a blind brute-force attack? 3. Do you think this system was the only target? 4. Do you think that this indicates a security problem inside that /16? 5. Do you think that this is the first time I've observed a problem like this emanating from one of the Digital Ocean's allocations? 6. Do you think, given that I can see (part of) the attack arriving at my operation, that they can see it leaving theirs? Hint: netflows 7. Do you think this will happen again? 8. Given the answers to 1-7, should I respond to this by deploying a half-ass measure like fail2ban that will let this happen over and over and over again, or should I just cut to the chase and permanently firewall the entire /16? (...just like the other other 24 Digital Ocean allocations that I've already firewalled) 9. On reading this, what do you think *you* should do? Should you sit on your hands and wait for your turn to be attacked from the festering sewer that is Digital Ocean, or maybe, should you drop 104.248.0.0/16 into your firewall configuration and refuse all ssh connections from it? ---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