undefined | Better HN

0 pointsurda4y ago0 comments

> Absolutely pointless

My logs and firewall greatly disagree. Please avoid comments on HN like this where it boxes solutions into a "my way or the highway" result, when it has been demonstrated to you here it's not "Absolutely pointless". Security is the layering of multiple solutions and defenses to protect your assets, there is no magic bullet or single solution.

0 comments

6 comments · 2 top-level

awsthro009454y ago· 2 in thread

"My logs and firewall are less cluttered" is not at all the correct metric to measure the security of your box.

IP address spoofing is a thing. Blocking CIDR ranges might protect you from low-effort, drive-by botnets that constantly scan the entire internet (which all should be completely mitigated by using certificate based auth anyway), but blocking based on IP address is absolutely not an effective control against a determined hacker.

You must consider your threat model. For your personal instance that you host hobby things on, you probably won't be targeted via IP spoofing. For any type of company, you should not be relying on CIDR blocking as part of your security layers. CIDR blocking is only effective at reducing the clutter of your logs, which is a convenience, not a security control. The real security control is using proper auth methods, which are so easy to do at this point that it's ridiculous for even a hobbyist to not do them.

nyolfen4y ago

my understanding is that spoofing only works for sessionless protocols or situations -- eg a single udp packet or a series of packets that do not rely on any kind of response, since the response (like a tcp ack, or a dh handshake) is routed to the spoofed address. this would not apply to ssh. what contexts are you thinking of?

ianhawes4y ago

Yeah, the parent comment is not accurate. IP spoofing is only possible if you control the entire L4 stack.

2 more replies

yjftsjthsd-h4y ago· 2 in thread

So I know this is all probabilistic and there's probably some benefit, but are there really a meaningful number of attackers who could attack a server which only allows public key authentication and who will be slowed by country-granularity IP blocking? If you're counting blocked attempts in logs, you're counting attempts that were never going to succeed.

(Note: This works only if 1. Your IP blocks are very coarse, and 2. You disallow password authentication)

jffry4y ago

This isn't about deflecting a targeted attack, it's about reducing the amount of noise in your logs so that it becomes easier to detect a targeted attack.

For the same reason, assuming you must expose SSHD to the world, it makes sense not to expose it on port 22.

If you set up a machine on AWS EC2 and give it a public IP address, you can watch in near-realtime as the "admin/admin" login attempts come in (last time I tried this on a whim it took less than a minute).

fivea4y ago

> If you're counting blocked attempts in logs, you're counting attempts that were never going to succeed.

By your own logic, if the problematic traffic shares the same geographic origin and you only happen to spot failed attempts, blocking all traffic from the same geographic origin would also block potentially successful attempts.

And I agree with the OP: there's an awful lot of malicious traffic sharing a common geographical origin. If you ever felt curious, just launch a cheap VM and setup a web server to listen to traffic and log any connection attempt. You don't even need to host a site. In no time you'll start to see your VM being hit by all sorts of web scrapers and security vulnerability scanners.

j / k navigate · click thread line to collapse