←back to thread

67 points xlmnxp | 1 comments | | HN request time: 0.203s | source
Show context
tptacek ◴[] No.45668433[source]
I will never, ever understand this "single-packet authentication" "port knocking" fetish. It has never made sense. Bin it, along with fail2ban, and just set up WireGuard.

Your network authentication should not be a fun game or series of Rube Goldberg contraptions.

replies(7): >>45668640 #>>45668974 #>>45669023 #>>45672079 #>>45672470 #>>45673304 #>>45676649 #
hatradiowigwam ◴[] No.45668974[source]
Fail2ban is not in the same realm as port knocking, and to "bin it" would be foolish security posture at best, and negligent at worst.
replies(2): >>45669348 #>>45669979 #
mdhb ◴[] No.45669348[source]
I’m not super familiar with the intricacies of fail2ban and don’t currently understand why op made that claim but would very much like to know more because he is talking about a topic he is highly regarded for and I respect that. I just don’t have the context.
replies(2): >>45670625 #>>45671161 #
Joel_Mckay ◴[] No.45670625[source]
Port-knocking mainly mitigates slow distributed-brute-force login attacks, and works best when ports are interleaved with several tripwire black-hole and knock-port-close firewall rules.

Use-cases:

1. helps auto-ban hosts doing port-scans or using online vulnerability scanners

2. helps reduce further ingress for a few minutes as the hostile sees the site is "down". Generally, try to waste as much of a problem users time as possible, as it changes the economics of breaking networked systems.

3. the firewall rule-trigger delay means hostiles have a harder time guessing which action triggered a IP ban. If every login attempt costs 3 days, folks would have to be pretty committed to breaking into a simple website.

4. keeps failed login log noise to a minimum, so spotting actual problems is easier

5. Easier to forensically analyze the remote packet stream when doing a packet dump tap, as only the key user traffic is present

6. buys time to patch vulnerable code when zero day exploits hits other hosts exposed services

7. most administrative ssh password-less key traffic should be tunneled over SSL web services, and thus attackers have a greater challenge figuring out if dynamic service-switching is even active

People that say it isn't a "security policy" are somewhat correct, but are also naive when it comes to the reality of dealing with nuisance web traffic.

Fail2ban is slightly different in that it is for setting up tripwires for failed email logins, and known web-vulnerability scanners etc. Then whispering that IP ban period to the firewall (must override the default config.)

Finally, if the IP address for some application login session changes more than 5 times an hour, one should also whisper a ban to the firewalls. These IP ban rules are often automatically shared between groups to reduce forum spam, VoIP attacks, and problem users. Popular cloud-based VPN/proxies/Tor-exit-nodes run out of unique IPs faster than most assume.

Have a nice day, =3

replies(3): >>45671078 #>>45671584 #>>45671674 #
frumplestlatz ◴[] No.45671584[source]
This is a metric ton of completely pointless theater.

Your services should simply be unreachable over anything but wireguard (or another secure VPN option).

replies(2): >>45672039 #>>45672104 #
fencepost ◴[] No.45672104[source]
"We had a secure VPN option set up, but then we had to replace our Ivanti VPN solution so we switched to Fortigate. Then there were some concerns so we jumped to Sonicwall. After that debacle we finally got the budget to go with Cisco and I'm sure everything will be fine now!"
replies(2): >>45672297 #>>45675478 #
immibis ◴[] No.45675478[source]
These are what I call, corporate solutions. They're used to make CEOs feel good while deflecting blame, not to actually do the job. See also how nobody gets blamed if AWS goes down, but everyone who used a different host with higher uptime did get blamed when that went down.

Open source tools are good at actually doing the job, as long as it's a programmer type of job. We've known how to do unbreakable encryption for decades now. Even PGP still hasn't been broken. Wireguard is one of those solutions in the "so simple it has obviously no bugs" category - that's actually what differentiates it from protocols like OpenVPN.

Think about the recent satellite listening talk at DEFCON and how that massive data leak could have been prevented by even just running your traffic through AES with a fixed key of the CEO's cat's name on a Raspberry Pi, but that's a non-corporate solution and so not acceptable to a corporation, who will only ever consider enabling encryption if it comes with a six figure per year license fee which is what the satellite box makers charged for it. Corporations, as a rule, are only barely competent enough to make money and no more.

replies(2): >>45676056 #>>45676120 #
tptacek ◴[] No.45676056[source]
PGP has very much had breaks, both in its authenticator and a full-on confidentiality break for the mail plugins, both traceable to the structure of the system itself, and that's before we get into the fundamental DOS flaw that killed the keyservers, which themselves are an antifeature. I don't think you can find a practicing cryptography engineer to stick up for PGP.

I don't like or trust OpenVPN. I'd sooner expose OpenSSH itself, which has really a pretty stunning security track record.

replies(1): >>45676181 #
1. Joel_Mckay ◴[] No.45676181[source]
The key concept is accountability, and if only 7 people have access to a host instance... the damage done by malicious or incompetent actors is kept small.

The biggest weakness in VPN is client-side cross-network leaks.

IPSec is simply a luxury if the LAN supports it, but also an administrative nightmare for >5k users. =3