[HN Gopher] Knocker, a knock based access control system for you...
___________________________________________________________________
Knocker, a knock based access control system for your homelab
Author : xlmnxp
Score : 62 points
Date : 2025-10-22 08:37 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| myzek wrote:
| I don't want to be a hater, but exposing access to your homelab
| through a "fully vibe coded" application (it's mentioned at the
| bottom of the README) is probably not a good idea.
|
| The idea itself sounds fun though
| sandblast wrote:
| I guess I have to implement the habit of checking such things,
| since I never assume such a possibility. I prefer this info to
| be at the top of the readme, though - much more information
| value than the logo that deceived me into thinking this is a
| mature project.
|
| Regardless; what benefits this would have over Wireguard?
| gregoriol wrote:
| Github should have a tag about it on projects
| dugite-code wrote:
| Perhaps not requiring a wireguard client installed on the
| machine you are accessing from. There are several
| circumstances where installing a VPN client isn't possible or
| practical
| jamesbelchamber wrote:
| I guess at least they're being honest, but I would agree -
| there's a large delta between Al-assistance and Al-driven, and
| "vibe coding" is one step further (just accepting everything Al
| does without critique, so long as it "works").
|
| Great for prototyping, really bad for exposing anything of any
| value to the internet.
|
| (Not Anti-Al, just pro-sensible)
| nextlevelwizard wrote:
| Github should have "LLM" as language for repos that self
| report to be vibe coded or at least this kind of disclosure
| should be at the top of the readme not after thought.
|
| Also the "If you're Anti-AI please don't use this." is pretty
| funny :D I guess I must be "Anti-AI" when I think this kind
| of code is wild to rely on.
| Eisenstein wrote:
| I fully support the AI self-disclosure, but what I wonder
| what it is about AI generated code that makes this a
| separate problem from any other code where you don't know
| the programmer's competence?
|
| Is it because the AI can generate code that looks like it
| was made by a competent programmer, and is therefore
| deceiving you?
|
| But whatever the reason, I think that if we use it as a way
| to shame the people who do tell us then we can be assured
| that willingness to disclose it going forward will be
| pretty abysmal.
| muvlon wrote:
| I think it makes sense for stuff that is fully AI
| generated to the point where you commit the prompts to
| git. At that point, they become the real "source code"
| and the generated code is more of a build artifact. It
| makes sense to tag the language as "LLM" instead of e.g.
| "Python" because that's what contributors will be
| expected to touch when interacting with the codebase.
| xenophonf wrote:
| > _Great for prototyping_
|
| I must be Doing It Wrong(TM), because my experience has been
| pretty negative overall. Is there like a FAQ or a HOWTO or
| hell even a MAKE.MONEY.FAST floating around that might clue
| me in?
| eitland wrote:
| No. You have just missed the two last steps. Here is the
| full explanation, and it is the same as it has always been
| on HN:
|
| 1. Make prototype
|
| 2. _Magic happens here_
|
| 3. Make lots of $$$
|
| Great for prototyping only makes it easier to get to step
| 2, but done correctly, it certainly does that.
|
| As proven by the nice app I have running on my laptop, but
| probably won't make any money from.
| V__ wrote:
| > If you're Anti-AI please don't use this.
|
| I'm pro security. The gall to put something out there, pretend
| it being vibe coded is not a big deal and possibly exposing
| hundreds of people to security issues. Jesus.
| sanex wrote:
| It's open source. Audit it like you would any other service
| that exposed your homelab to the Internet. How do you know XYZ
| repo isn't coded for some bootcampers capstone project? I bet
| those are even less secure.
|
| Edit: should have mentioned I am a bootcamp grad, not just
| throwing random shade.
| QuantumNomad_ wrote:
| > How do you know XYZ repo isn't coded for some bootcampers
| capstone project?
|
| I gate access to my homelab using Wireguard.
|
| Wireguard is widely deployed across the world, and has been
| worked on for years.
|
| No random new repo that was vibe coded can measure up in the
| slightest to that.
| OrderlyTiamat wrote:
| If I had to audit security services for exposing homelab to
| the internet, I wouldn't use those services in the first
| place. I'm fine trying things out, but this is a very
| important security boundary, and it's a solved problem. Why
| risk it with an auditor who does it for a hobby (me)?
| dawnerd wrote:
| It's getting scary how many security related apps are being
| vibe coded by people with very little security experience (not
| a knock heh on op, they could very well be experienced).
| muppetman wrote:
| Suggesting people don't shoot themselves with a loaded gun is
| not being a hater, it's being a good person.
| mano78 wrote:
| I implemented something similar as a caddy module, then I
| realized that if I was connected to a public wifi network I was
| actually authorizing the whole bunch of people that were
| connected to it with me. How do you avoid this, or is it just not
| important?
| OJFord wrote:
| It shouldn't be your only layer of security, and then it's not
| important. Think of it as replacing explicit IP
| black/whitelisting - you still want a login wall or something,
| but now you restrict access to guess logins or otherwise obtain
| access through app vulnerabilities etc.
| teddyh wrote:
| It's the third option: Port knocking is stupid.
|
| <https://news.ycombinator.com/item?id=39898061>
| symbogra wrote:
| I implemented port knocking couple decades ago as a teenager
| and it was stupid then too.
| TuxPowered wrote:
| > How do you avoid this
|
| IPv6 of course.
|
| > or is it just not important
|
| Port knocking not a security feature anyway.
| eastabrooka wrote:
| Its 2025, Just use Tailscale.
| lucideer wrote:
| If you're running a homelab, the likelihood that you're
| interested in removing cloud-dependencies from your stack is
| above average. If that's the case, Tailscale is out.
|
| Tailscale is just an added unnecessary external dependency
| layer (& security attack surface) on top of vanilla Wireguard.
| And in 2025 it's easier to run vanilla Wireguard than it's ever
| been.
| aspenmayer wrote:
| Also, Headscale exists.
| lucideer wrote:
| I haven't tried Headscale but isn't it _more_ complicated
| than Wireguard?
|
| The selling point of Tailscale is that they simplify
| Wireguard UX by adding a proprietary control server - this
| adds complexity to the stack (extra component) but
| simplifies user experience (Tailscale run the control
| server for you).
|
| Headscale seems like it's complicating the stack (adding an
| extra component) as well as complicating the user
| experience (you have to maintain two components yourself
| now instead of just the one Wireguard instance).
|
| Granted I presume the Headscale control server might
| simplify management of your Wireguard instance but...
| you're still maintaining the control server yourself.
| aspenmayer wrote:
| It likely does add some complexity, though it's relative.
| Self-hosting is always going to have some overhead.
| Managing WireGuard servers and clients and associated
| keys etc is probably the part that is most annoying, so I
| can see how it might be easier to throw that over the
| fence to Headscale even though it is introducing another
| dependency.
|
| I was speaking more to doing it all in-house, versus
| outsourcing things to Tailscale, a third party not fully
| under one's control, even if they act of behalf of the
| user. I think I largely agree with what you said.
| lucideer wrote:
| Fwiw I bought an Asus router that came with Wireguard
| pre-installed & has a nice management UI. It handles
| client onboarding via a simple QR code that integrates
| with the Wireguard mobile app - even my mother had no
| issue setting it up.
|
| Buying hardware is an investment (& not something
| everyone can do) but I've really never understood the
| point of the control server from the perspective of an
| open-source self-hoster (for a business like Tailscale it
| makes sense as it introduces an element of control, user
| dependency & likely analytics of some value).
|
| There's still a lot that can be done to improve
| Wireguard's UX but I think the Asus example proves it can
| be done well. Headscale seems to be doing the worst of
| both worlds (promoting an architecture & user-flow of a
| proprietary closed-source competitor, while still
| requiring CLI setup & instance maintenance). For example,
| it seems to me like it would be better for them to wrap
| Wireguard directly & integrate with the actual Wireguard
| mobile app instead of having people install proprietary
| Tailscale app on their phones to use your own open-source
| self-hosted control server.
| aspenmayer wrote:
| There's a cost with using Asus firmware instead of using
| stock OpenWRT, which might even be compatible with your
| router. Many Asus products are compatible, and may even
| be running OpenWRT themselves. The upshot is you get a
| nice GUI and a nice out of the box experience, but you're
| also phoning home to Asus in small ways, just like one
| would be if they ran Tailscale.
|
| I would agree that stock WireGuard is going to have the
| fewest dependencies, and I don't mean to nitpick or be
| disagreeable because I do agree with you, that fewer
| third party dependencies is usually better than more.
|
| The Asus-Merlin firmware is also nice, though the stock
| Asus firmwares have gotten pretty good and work for most
| folks for many use cases. I think VLAN config and tagging
| support might be one of the only features I wanted that
| stock Asus firmware didn't handle when I used them last.
| lucideer wrote:
| I'm on Merlin currently but I'm in the process of moving
| over to OPNSense for this exact reason.
|
| However, while you can never really trust anything you
| run with internet access, I feel there's a fundamental
| line between an explicitly cloud-dependent service like
| Tailscale (e.g. a Tailscale control server outage
| incident would impact your home server access) compared
| to a fully self-hosted service that may or may not phone
| home if you don't put preventative measures in front of
| it, but will continue to function fine if you do put said
| measures in place.
|
| The Asus mobile app is another potential concern but the
| Merlin browser UI is fine for most purposes.
| aspenmayer wrote:
| > However, while you can never really trust anything you
| run with internet access, I feel there's a fundamental
| line between an explicitly cloud-dependent service like
| Tailscale (e.g. a Tailscale control server outage
| incident would impact your home server access) compared
| to a fully self-hosted service that may or may not phone
| home if you don't put preventative measures in front of
| it, but will continue to function fine if you do put said
| measures in place.
|
| This is why I mentioned Headscale in the first place.
| It's not for everyone or every use case, but it's good
| that it exists, on the whole.
| reedf1 wrote:
| It's much simpler to babysit a service than to manage a
| relatively higher risk thing like generating, rotating
| and communicating public keys between all of the nodes in
| the network.
| fragmede wrote:
| It exists on a spectrum. Time for hobbies including
| homelabbing is limited, so while someone who's retired and
| has all the time in the world to tinker can go self host
| every last single thing, I'd bet that more people just want
| to be able to have something that works without a huge
| depency on the cloud. As long as the bits are on the hard
| drive in my basement, how the packets get routed around is
| less critical, to some people, I imagine.
|
| Everybody's got their own set of beliefs and understandings,
| and they get to decide how they want their homelab to work.
|
| For me, tailscale fits in just right. Others can come to
| their own conclusion based on how they feel about networking
| and points of failure and depency and all that.
| bakugo wrote:
| Normally I'd agree with the philosophy, but I don't really
| see how you can say this about vanilla Wireguard in
| particular considering how involved it is, especially if you
| have more than 2 devices that you want to connect together.
|
| Not only do you need to manually manage the keys for each
| device and make sure they're present in every other device's
| configuration, but plain Wireguard also cannot punch through
| NATs and firewalls without any open ports like Tailscale can,
| as far as I know.
|
| Combine that with the fact that networking issues can be some
| of the hardest to diagnose and fix, and something like
| Tailscale becomes a no-brainer. If you prefer using plain
| Wireguard instead, that's fine, and I still use it too for
| some more specific use cases, but trying to argue that
| Tailscale is entirely unnecessary is just wrong.
| lucideer wrote:
| > _trying to argue that Tailscale is entirely unnecessary
| is just wrong_
|
| Tailscale is great if it meets your requirements, & it
| probably does for most - I wasn't arguing that at all. Only
| that it won't be an option for everyone: in particular a
| non-tiny subset of home server hosters.
| sneak wrote:
| Not really. Most things people run in homelabs have tons of
| cloud dependencies. Try running Home Assistant offline, for
| example.
| lucideer wrote:
| I run home assistant offline. I've never encountered any
| issues, except for the little weather widget that comes
| enabled by default not working.
|
| I know there's plenty of HA integrations that require some
| cloud service but the core application is very offline-
| friendly...
| lucideer wrote:
| > _This is ideal for homelab environments where you want to
| expose services to the internet without a persistent VPN
| connection, while minimizing your public-facing attack surface._
|
| To an untrained eye, the wording here could be construed to imply
| that this is more secure than a VPN. Might be worth a reword to
| clarify _why_ one might prefer it want to over a VPN.
| yaris wrote:
| The authentication part does not look much different from
| password authentication (key [?] password), and the "Configurable
| TTL" bit is somewhat confusing, the first part of the sentence
| assigns the TTL to API keys but the second part says it applies
| to IPs being whitelisted. I would expect that TTL for a key means
| that after the TTL expires the key itself becomes unusable.
| TZubiri wrote:
| Port knocking is a very hacky technique that was used:
|
| 1- In the 90s were security was whatever
|
| 2- In modern days as a way to keep your logs squeaky clean (
| although you get 99% there with custom ports)
|
| 3- As a cute warm up exercise that you code yourself with what's
| available in your system. (iptables? a couple of python scripts
| communicating with each other?)
|
| It's not a security mechanism, and downloading external
| dependencies or code (especially if vibecoded) is a net loss (by
| a huge margin).
|
| It's also a waste of time to overengineer for the reasons noted
| above, I've seen supposedly encrypted port knocking
| implementations. It feels as if someone had a security checklist
| and then a checklist for that checklist.
| imiric wrote:
| There's nothing "hacky" about port knocking. It was never meant
| to be a complete security solution--nothing is.
|
| But it works very well as an additional layer of security. Sec
| nerds often scoff at "security through obscurity", but it is a
| very valid strategy. Running sshd on a random high port is not
| inherently more secure, but it avoids the vast majority of dumb
| scanners that spam port 22, which is why all my systems do
| that. Camouflage is underrated, yet wildly effective. You can
| see how well it works in nature.
|
| In any case, this is not a port knocking solution anyway, as I
| mentioned in another comment.
| frumplestlatz wrote:
| It's really, really not a valid strategy for anything. Just
| put your services behind WireGuard.
| abujazar wrote:
| Nowadays public facing client IPs are often shared by thousands
| of users behind CGNAT. IP based firewall rules are useful when
| the peers have their own static IP address, but provide no real
| security when the IP address is shared.
|
| This is vibe coded security through obscurity, i. e. quite
| useless. Use Tailscale or a self hosted VPN.
| nextlevelwizard wrote:
| It could be fun extra layer. Like of course you should always
| use VPN, but maybe a magic packet so your VPN server even opens
| a port could be fun.
| imiric wrote:
| Neat project, thanks for sharing. I'll stay away since it was
| vibecoded, but I appreciate the honesty.
|
| Though this is not technically a "knocker", but a typical token-
| based auth gateway. I experimented with something similar
| recently as well, and think it has its use cases.
|
| But I would agree with some of the comments here. If you need to
| expose many services to the internet, especially if their
| protocols are not encrypted, then a tunneling/mesh/overlay
| network would be a better solution. I was a happy tinc user for
| several years, and WireGuard now fills that purpose well. As much
| as people use solutions like Tailscale, ZeroTier, etc., I
| personally don't trust them, and would prefer to roll my own with
| WG. It's not that difficult anyway.
|
| There's also Teleport, which is more of an identity-aware proxy,
| and it worked well last time I tried it, but I wouldn't use it
| for personal use.
| Halan wrote:
| IP based exclusion should not be considered a security measure,
| not even for a low risk environment like a home lab
| password4321 wrote:
| > _IP based exclusion should not be considered a security
| measure_
|
| Apologies in advance if I'm missing something obvious here, but
| are you saying an IP allow list is not a standard security
| practice? If so I'd appreciate further explanation.
| abujazar wrote:
| It's useful when the client always has its own static IP that
| _doesn't change_ between sessions. In this case, where the
| public facing IP may be shared by thousands of users, it
| provides no real security. All you'd have to do to gain
| access would be getting the client IP and finding some way of
| getting on the same network. Which in many cases could be as
| easy as subscribing to the same cell network or other ISP, or
| connecting to the guest wifi network of an office building.
| password4321 wrote:
| Thanks for filling in the details. I agree that an IP allow
| list works best for users who are alone on an IP that
| doesn't change often, which is the case for a majority of
| home internet users but not when they're away from home.
| yccs27 wrote:
| Unfortunately there's an increasing number of home
| internet connections behind CGNat, as IPv4 adresses run
| out (and IPv6 doesn't gain momentum, heaven knows why)
| abujazar wrote:
| I guess it's partially because ISPs are perfectly happy
| selling crippled internet connectivity as the base
| service and charging hefty premiums for "luxuries" like
| static IPs. It has also become common to only offer
| static IPs to business customers.
| ianburrell wrote:
| IPv4 addresses have run out, everything has been
| allocated, and they are now being traded.
|
| IPv6 is slowly growing in popularity. Google stats are
| close to 50%. If your ISP has IPv6, you might be
| accessing Hacker News with IPv6 since they added support
| recently.
| scottydelta wrote:
| When every problem seems like a nail then every solution you come
| up with is a hammer.
|
| This is what it feels like people using AI for everything.
|
| AI is not good at telling you best solution but it will tell you
| that you can build it yourself since that approach is what AI is
| good at.
|
| Using self hosted vpn, cloudflare zero trust or Tailscale is the
| easiest way to go.
|
| I self host extensively and have multiple self hosted VPN(OpenVPN
| and WireGuard) along with Tailscale and cloudflare protecting my
| infra.
| OutOfHere wrote:
| If you're getting people to rely on external dependency
| services, e.g. Cloudflare or Tailscale, then you're a part of
| the problem, not the solution!
| foofoo12 wrote:
| Also FWIW, if you're using nftables you can set up port knocking:
| https://wiki.nftables.org/wiki-nftables/index.php/Port_knock...
| giantg2 wrote:
| Aw man, I thought this was going to be audio sensor that logs you
| in with a secret physical knocking pattern (like on a door or
| desk).
| jedimastert wrote:
| That's what I thought was well, like a Morse code detector tied
| to the lock on the door or something lol
| luc_ wrote:
| Maybe I'll vibecode that this weekend...
| lugarlugarlugar wrote:
| https://www.youtube.com/watch?v=zE5PGeh2K9k&list=PL6AGg52_Gz...
| WJW wrote:
| I had hoped this would allow me to use various patterns of
| knocking on my desk to perform system actions. Do the cut-and-a-
| hair-shave knock to log in, or taptaptaptap-wait-tap to lock the
| screen, etc. Maybe with two microphones you could even
| distinguish between left and right handed knocks.
|
| ...now I'll have to make this myself.
| spicybright wrote:
| I was thinking exactly the same thing. Or maybe a knock on the
| door before you enter to set stuff in your room to a certain
| state.
| Dilettante_ wrote:
| >Cut-and-a-hair-shave knock
|
| TIL that that has a name.[1] All I ever knew it as was "the
| knock from Roger Rabbit".
|
| [1]https://en.wikipedia.org/wiki/Shave_and_a_Haircut
| dugite-code wrote:
| I use fwknop in a similar manner, the main advantage it has is
| it's using an encrypted UDP packet. It's ability to call shell
| scripts for more advanced uses is its best feature. I have a
| packet set up for a rolling restart of all my services as well as
| ssh access
| sneak wrote:
| I use this thing called sshd that listens on only a single port
| and its main advantage is that it uses _actual cryptography_ to
| authenticate using a client keypair.
| dugite-code wrote:
| Fwknop uses HMAC keys so quite good crypto by itself, but
| it's for single shot commands. Good for keeping the ssh port
| locked until you actually need it. I use it on top of SSH key
| pairs as part of my layered security, Just as any good access
| control strategy should.
| RickJWagner wrote:
| Somebody must tell Mel Brooks about this.
| SoftTalker wrote:
| Yeah the urge to post a "What Knockers!" Gene Wilder gif is
| strong. Good thing HN doesn't allow that.
| tptacek wrote:
| 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.
| mdhb wrote:
| I mostly agree.. there's a couple of very specific scenarios
| where maybe something like knockd makes sense I think but they
| are all scenarios where you're doing things covertly, not as a
| general authentication mechanism.
|
| As a side note I just happen to be reading a book at the moment
| that contains a fairly detailed walkthrough of the procedure
| required to access the Russian SVRs headquarters in New York in
| 1995.
|
| Think of this as an analogue version and in no way a perfect
| analogy but it does include a step that has more or less the
| same security properties as this... anyways here's a relevant
| quote:
|
| "After an SVR officer passed through various checkpoints in the
| mission's lower floors, he would take an elevator or stairs to
| an eighth-floor lobby that had two steel doors. Neither had any
| identifying signs.
|
| One was used by the SVR, the other by the GRU. The SVR's door
| had a brass plate and knob, but there was no keyhole. To open
| the door, the head of the screw in the lower right corner of
| the brass plate had to be touched with a metal object, such as
| a wedding ring or a coin.
|
| The metal would connect the screw to the brass plate,
| completing an electrical circuit that would snap open the
| door's bolt lock and sometimes shock the person holding the
| coin.The door opened into a small cloakroom. No jackets or suit
| coats were allowed inside the rezidentura because they could be
| used to conceal documents and hide miniature cameras.
|
| SVR officers left their coats, cell phones, portable computers,
| and all other electronic devices in lockers. A camera
| videotaped everyone who entered the cloakroom. It was added
| after several officers discovered someone had stolen money from
| wallets left in jackets. Another solid steel door with a
| numeric lock that required a four-digit code to open led from
| the cloakroom into the rezidentura.
|
| A male secretary sat near the door and kept track of who
| entered, exited, and at what times. A hallway to the left led
| to the main corridor, which was ninety feet long and had
| offices along either side. "
|
| Excerpt from Comrade J by Pete Earley
|
| As another funny side note... I once discovered years ago that
| the North Koreans had a facility like this that they used to
| run a bunch of financing intelligence operations using drugs in
| Singapore where I was at the time and thought it would be funny
| to go and visit. It was in a business complex rather than a
| dedicated diplomatic facility from memory. But as I recall it
| was a similar scenario of unmarked door with no keyhole.
| tptacek wrote:
| WireGuard is designed to be silent preceding a
| cryptographically authenticated INIT message. It's a superset
| of whatever security features you'd get from "knocking".
| mdhb wrote:
| I'm not arguing with you or pretending to not know the
| difference. I'm saying that is the right answer 999/1000
| but there are other scenarios as well.
| akerl_ wrote:
| In fairness, most of the fervor for these kind of knock-
| based flows predate Wireguard existing. They come from the
| era where OpenVPN and friends were the common practice in
| that space, and I would not have considered "add OpenVPN"
| to be a rational way to improve the security of anything I
| was doing.
| frumplestlatz wrote:
| OpenVPN was a perfectly reasonable answer to this problem
| for many years.
|
| "Port knocking" et al were most definitively _not_.
| akerl_ wrote:
| Eh. I've used OpenVPN over many years for many kinds of
| problems. I'm hesitant to call it perfectly reasonable
| even for the most mundane use case of "running an
| entirely vanilla virtual private network". For the use
| case of securely wrapping services in the way Wireguard
| can do, it's hilariously bad.
|
| OpenVPN is basically 1000 configuration options and magic
| incantations wearing a trenchcoat, and if you get any of
| them wrong the whole thing crumbles (or worse, appears to
| work but is not secure).
| nati0n wrote:
| Enjoyed the read, thanks for passing along. What book is it
| from?
| mdhb wrote:
| Comrade J by Pete Earley
| hatradiowigwam wrote:
| 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.
| mdhb wrote:
| 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.
| Joel_Mckay wrote:
| 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
| akerl_ wrote:
| If a slow brute force attack is working on your system,
| all the port knocking and tripwires and whatever are just
| gimmicks.
|
| Don't waste resources putting lipstick on the pig.
| Joel_Mckay wrote:
| Stolen password-less key bots are also common these days,
| and again it is more about reducing log noise.
|
| "Don't waste resources putting lipstick on the pig."
|
| I would never kink-shame someone that ignored the recent
| CVE-2025-48416, that proved exposing unprotected services
| is naive =3
| akerl_ wrote:
| If somebody has a stolen credential, they aren't going to
| be brute forcing at all. Likewise that CVE wouldn't be
| attacked by a brute force attack.
|
| But I see you've backpedaled to this being about log
| noise, not security.
| Joel_Mckay wrote:
| Threat detection is a higher security priority than
| prevention in my experience.
|
| One may believe whatever they like, as both our
| intentions are clear friend.
|
| Have a wonderful day =3
| akerl_ wrote:
| It's weird to assign them comparatively like that but
| also, what does that have to do with fail2ban?
|
| The roving spam it blocks are not threats, and stolen
| credentials aren't going to be detected by it.
| Joel_Mckay wrote:
| In general, bots/worms/clowns will first check if a
| host/router is already infected or vulnerable to a shim.
| Thus, tripwires on those checks or URI often auto-ban
| infected/hostile hosts before a scan fully escalates to a
| successful payload. Note, people don't want a VM delta-
| snapshot of their zero-day around for automated analysis.
|
| 99.98% of hostile traffic simply reuse already published
| testing tools, or services like Shodan to target hosts.
|
| One shouldn't waste resources guessing the motives behind
| problem traffic. =3
| akerl_ wrote:
| You're just sort of loosely interweaving unrelated
| comments?
|
| You're back on prevention instead of detection, but also
| no: an attacker with valid creds isn't going to run other
| checks first before using them.
|
| And yes: by volume, most attacks on the internet are just
| spam reusing published tools and IP lists. And that
| traffic is zero percent risky unless your auth is already
| busted.
| frumplestlatz wrote:
| This is a metric ton of completely pointless theater.
|
| Your services should simply be unreachable over anything
| but wireguard (or another secure VPN option).
| Joel_Mckay wrote:
| Depends on the use-case, IPsec is often not supported by
| many LANs. Also, network crossing is 1 badly configured
| client away from full infrastructure worming.
|
| At some point, the idealism of white-listed pears and VPN
| will fail due to maintenance service costs. Two things
| may be true at the same time friend. =3
|
| https://www.poetry.com/poem/101535/the-blind-men-and-the-
| ele...
| frumplestlatz wrote:
| Yes, and those two true things are:
|
| - You should be using WireGuard.
|
| - "Port knocking" is pointless theater.
| Joel_Mckay wrote:
| CVE-2024-26950 is also true, and while I respect your
| opinion... a VPN has a lot of additional links in the
| chain trivially broken by competent hostiles or
| incompetent client installations.
|
| IPSec is simply a luxury unavailable on some LANs =3
| tptacek wrote:
| I don't understand what you think CVE-2024-26950 has to
| do with this thread. Do you understand what that
| vulnerability actually is, or did you just go search
| "WireGuard CVE" to find ammunition?
| Joel_Mckay wrote:
| Firewall administrative network port traffic priority is
| important for systems under abnormal stress.
| tptacek wrote:
| I don't know what this even means. Do you understand the
| vulnerability you cited? Can you explain it here?
| fencepost wrote:
| "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!"
| frumplestlatz wrote:
| I said a _secure_ VPN option.
|
| However, even with all those choices, "port knocking"
| still wouldn't be a solution for anything.
|
| [edit]
|
| Are you just searching for random WireGuard CVEs now?
|
| CVE-2024-26950 was a *local-only* DoS and potential UaF
| requiring privileged access to wireguard netlink sockets.
| Joel_Mckay wrote:
| You mean CVE-2024-26950 ? =3
|
| <edit>
|
| Firewall administrative network port traffic priority is
| important for systems under abnormal stress.
| immibis wrote:
| 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.
| tptacek wrote:
| 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.
| Joel_Mckay wrote:
| 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
| Joel_Mckay wrote:
| Cisco spent years marketing every solution as a router or
| appliance box.
|
| A lot of VPN installations are simply done wrong, and it
| only takes 1 badly configured client or cloud side-
| channel to make it pointless. IPSec is not supported on a
| lot of LANs, and 5k users would prove rather expensive to
| administer.
|
| Also, GnuPG Kyber will not be supported by VPN software
| anytime soon, but it would be super cool if it happens.
| =3
| mdhb wrote:
| I recently wrote a deception / honeypot service that does
| some similar stuff so that all makes sense to me and I
| think the general strategy of impose costs on attackers
| by making them expose more of their infrastructure etc
| are actually a really good move especially in the context
| of developing an early warning signal.
|
| I had some additional logic that gave me a really easy
| but unintuitive way to tell with an incredibly high
| degree of confidence the difference between a bot and a
| human on keyboard scenario and for what it's worth I
| think that is the specific thing that makes it worth the
| effort.
|
| If I have reasons to suspect it's a bot I just drop the
| request and move on with my day. The signal to noise
| ratio isn't worth it to me.
| Joel_Mckay wrote:
| I would simply bounce these users to a video game site,
| that paid us for referrals.
|
| So we made coffee-money wasting spammers time, and
| attacks stayed rudimentary. =3
| tptacek wrote:
| No, fail2ban is cargo cult security, and if you actually
| "need" it, you've misconfigured your system. Don't allow
| password authentication.
| dugite-code wrote:
| IMHO Fial2ban, just like port knocking, isn't cargo cult
| security. They are a single tool that can be included in a
| general system security arsenal, not the only tool you
| should use but one of a suite of tools that can be used
| depending on what you want to achieve.
|
| Personally I use fwknop for port knocking as it doesn't
| suffer from replay attacks as it's an encrypted packet. But
| still serves the same niche
| akerl_ wrote:
| The point being made is that unless "what you want to
| achieve" is "run a tool that isn't improving your
| security posture", port knocking isn't providing value to
| the security model.
|
| Hence the cargo cult.
| dugite-code wrote:
| I can't agree that it's "a tool that isn't improving your
| security posture", if it's a layer on top of other tools,
| you might argue it's effectiveness isn't great but to say
| it's effectively nothing is a reach.
| akerl_ wrote:
| It's not nothing: it's one more thing that can break or
| eat resources or have a vuln. And it's not improving the
| thread model. It's net negative.
| wolrah wrote:
| They can't get in but they can still fill my logs up, so
| fail2ban cuts them off after a few failures.
|
| Also by collecting data on the IP addresses that are
| triggering fail2ban I can identify networks and/or ASes
| that disproportionally host malicious traffic and block
| them at a global level.
| tptacek wrote:
| Why bother logging them at all? What is this doing for
| you? You can't meaningfully characterize attacker traffic
| this way. They'll come from any AS they want to.
| hrimfaxi wrote:
| Don't compliance regimes like NIST 800-53 require logging
| access attempts, whether successful or not, and
| especially for privileged users?
| akerl_ wrote:
| > To balance monitoring and auditing requirements with
| other system needs, event logging requires identifying
| the subset of event types that are logged at a given
| point in time. For example, organizations may determine
| that systems need the capability to log every file access
| successful and unsuccessful, but not activate that
| capability except for specific circumstances due to the
| potential burden on system performance.
|
| It's possible that some compliance regimes exist that
| mandate keeping logs of all unsuccessfully authentication
| attempts. There's surely a compliance regime out there
| that mandates every possible permutation of thing.
|
| But the far more common permutation, like we see with
| NIST, is that the organization has to articulate which
| logs it keeps, why those logs are sufficient for
| conducting investigations into system activity, and how
| it supports those investigations.
| hrimfaxi wrote:
| I was thinking of:
|
| > The need to limit unsuccessful logon attempts and take
| subsequent action when the maximum number of attempts is
| exceeded applies regardless of whether the logon occurs
| via a local or network connection. Due to the potential
| for denial of service, automatic lockouts initiated by
| systems are usually temporary and automatically release
| after a predetermined, organization-defined time period.
|
| https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-7/
| akerl_ wrote:
| That's almost always going to be a setting in your IDP,
| not based on log capture/retention.
|
| The IDP will have some settings for max fails before
| lockout, and apply it by counting.
| wolrah wrote:
| > Why bother logging them at all? What is this doing for
| you?
|
| Logging both successful and failed requests is important
| for troubleshooting my systems, especially the client-
| facing ones (a subset of which are the only ones that are
| accessible to the open internet), and failed
| authentication attempts are just one sort of request
| failure. Sometimes those failures are legitimate client
| systems where someone misconfigured something, and the
| logs allow me to troubleshoot that after the fact. That
| it can also be fed to fail2ban to block attackers is just
| another benefit.
|
| > You can't meaningfully characterize attacker traffic
| this way. They'll come from any AS they want to.
|
| Obviously in a world full of botted computers, IoT
| devices, etc. it's true that an attacker can
| hypothetically come from anywhere, but in practice at
| least from the perspective of a small service provider I
| just don't see that happen. I'm aware that you are
| involved with much larger scale operations than I'm
| likely to ever touch so perhaps that's where our
| experiences differ. No one's targeting my services
| specifically, they're just scanning the internet for
| whatever's out there and occasionally happen to stumble
| upon one of my systems that needs to be accessible to
| wherever my clients happen to bring their devices.
|
| Sure, I see random domestic residential ISP addresses get
| banned from individual servers from time to time, but I
| never see the organized attacks I see which are usually
| coming from small hosting providers half way around the
| world from my clients. I have on multiple occasions seen
| fail2ban fire off rapidly sequential IP addresses like
| xxx.xxx.xxx.1 followed by xxx.xxx.xxx.2 then
| xxx.xxx.xxx.3, or in other cases a series of semi-random
| addresses all in the same subnet, which then triggers my
| network block and magically they're stopped instead of
| just moving on to another network. If I were to be packet
| sniffing on the outside of the relevant firewall I'm sure
| I'd see another address in the blocked network trying to
| do its thing but I've never looked.
| slightwinder wrote:
| Every door you close, is one less someone can break.
|
| Every complex services running, is a door someone can
| potentially break. Even with the most secure and battle tested
| service, you never know where someone fucked up and introduced
| an exploit or backdoor. Happened too often to be not a concern.
| XZ Utils backdoor for example was just last year.
|
| > Your network authentication should not be a fun game or
| series of Rube Goldberg contraptions.
|
| If there is no harm, who cares...
| mdhb wrote:
| Just to be super clear.. using this in place of something
| like WireGuard is absolutely _not_ an improvement. It's
| actively worse in the majority of scenarios assuming you can
| manage to secure your keys.
| slightwinder wrote:
| Yes, of course, should this just be an optional gadget for
| a setup, which is already as safe as possible for the
| situation. After all, when the port has been opened, your
| setup is also open for attacks. The knockers purpose is to
| reduce the timeframe of when your system is accessible for
| attackers.
| tptacek wrote:
| Just to clarify: it's actively worse in every scenario.
| It's engineering malpractice.
| fencepost wrote:
| Knocking can cut down on grinding. I have in the past created
| setups where you had to knock prior to establishing a VPN
| connection, and given the semi-regular problems with VPN
| implementations I really don't feel bad about that. Fortigate,
| Sonicwall, Cisco, Ivanti, etc - sure a big part of it is "don't
| run VPNs based on big legacy codebases" but who's to say there
| won't be implementation problems found (or introduced given
| "Jia Tan" style attacks) in Wireguard?
|
| Is knocking incredibly weak security through obscurity? Sure,
| but part of what it does is cut down on log volume.
| tptacek wrote:
| There is literally no value to cutting down on WireGuard
| attempts. Like, the exact same set of skbuffs are being
| created and destroyed in either case.
| immibis wrote:
| Sure there is, if the attacker has to fulfil some basic
| obfuscation then it cuts down on the amount of crypto work
| you have to do before ignoring the packet.
|
| It's not extra security but it is a little extra
| efficiency.
|
| Wireguard has something like this built in though, the
| PresharedKey (which is in addition to the public key
| crypto, and doesn't reduce your security to the level of a
| shared-key system). It's still more work to verify that
| than a port knock however.
| tptacek wrote:
| This has no value at all. WireGuard assumes an adversary
| trying to make it do extra work doing handshakes; a big
| chunk of the WireGuard paper discusses it. I don't think
| this is as important a problem as Jason does (but it's
| his baby), but either way: part of the point of WireGuard
| is that it's safe to hang out on the open Internet this
| way.
| sneak wrote:
| I view port knocking as just a very, very poor form of an
| unencrypted PSK (replayable) authentication step.
|
| Just skip the plaintext password (the sequence of ports
| transmitted) and use certificate based auth, as you note below.
| tptacek wrote:
| It's part of a long line of cargo culted security things
| people do because it makes them feel on-the-ball; they're all
| anti-tiger rocks. Even before WireGuard, port knocking never
| made sense, and for most of its history it was actively
| harmful.
| trelane wrote:
| Do you have a guide to using wireguard in this way?
| tptacek wrote:
| Using WireGuard in what way? WireGuard defaults to the
| security posture SPA/port knocking hopes to asymptotically
| achieve.
| trelane wrote:
| > Using WireGuard in what way?
|
| Using WireGuard to gate access to a server. It looks like
| it's a VPN, not an access control mechanism. So I am
| curious how this works.
| tptacek wrote:
| Set up WireGuard, filter everything but WireGuard
| (51820/udp) on en0, and then SSH in over the WireGuard
| connection.
| akerl_ wrote:
| WireGuard is sort of a VPN, but really its core is peer
| to peer links with simple, footgun-resistant configs.
|
| The most mundane setup is two peers with each other's
| public keys that let each peer talk to the other via the
| WireGuard link.
| immibis wrote:
| It is a VPN. The point was to block all external traffic
| except for VPN traffic. Then make sure your VPN is
| secure, and you're all set. When you want to connect to
| some service, connect to the VPN first and then connect
| to the service through the VPN. Then all your traffic has
| actual security and not just some light obfuscation via
| secret handshake.
|
| IMO, "only wireguard" is too restrictive of a policy - I
| also trust openssh and nginx to be open to the internet,
| if configured moderately carefully. Most FOSS servers
| that are widely deployed on the internet are safe to be
| deployed on the internet, or we'd know about it. I
| reviewed something that's not widely deployed on the
| internet though (Apache Zookeeper) and couldn't convince
| myself that every code path was properly checking
| authentication. That would have to go behind a VPN.
| mondainx wrote:
| Sorry, but I felt a bit of nostalgia here; I wrote some port
| knocking code a couple decades ago, this is straight-up "neat"
| and I'm surprised it is still around.
| trashb wrote:
| The way I see it, port knocking may not be a valid security
| measure but it can be a good filter. It will allow you to filter
| out port scanning and other mass cracking attempts.
|
| My opinion is that being able to filter out noise and false
| positives from authentication logs allows you to improve your
| actual security measures.
|
| An other advantage is that it may hide information about your
| system making it harder for an attacker to target you based on a
| broad scan without doing some (usually detectable) targeted
| reconnaissance first. For example imagine someone found a 0-day
| in one of the services behind the port-knock and is scanning for
| the vulnerable version.
|
| It does however add another cog in the machine that may break.
| aborsy wrote:
| Wireguard port is the only port that could be exposed to the
| Internet.
|
| With xz backdoor owning ssh, I wouldn't completely trust ssh
| public key authentication either.
| kazinator wrote:
| It has sequence diagrams so it must be a good idea.
| parliament32 wrote:
| The "port knocking" has surfaced often since the early 2000s, but
| it continues to be a rather silly exercise in making security-by-
| obscurity look more complicated while not really helping all that
| much.
|
| Briefly looking at the diagram at the top of the repo, it looks
| like you "knock" with an API key. Why not just run a reverse
| proxy in front of (whatever service you're trying to protect) and
| use the API keys there? To harden further, do some sort of real
| authentication (PKI, client certs). If you want your logs to look
| cleaner, install and actually configure fail2ban.
| NoPicklez wrote:
| "Knock Knock" kinda sounds like a cool name for an access control
| system
| operrs wrote:
| If you need to manage risk for a legacy service that has a
| requirement to be internet exposed, I suggest checking out
| https://knocknoc.io/ for a self-hosted and/or cloud based
| solution that was not built with vibe coding, but actual customer
| security use cases. The provide 2FA and/or single sign-on to
| allow just in time access to internet exposed applications which
| remain hidden from unauthenticated/approved users.
___________________________________________________________________
(page generated 2025-10-22 23:02 UTC)