On Linux, this is why I always turn to using abstract sockets when I only need local locking. Only one process can bind and the kernel cleans up automatically on process exit.
You could do the same thing with TCP/UDP, but abstract sockets give you more flexibility in naming with 108 characters vs. being forced to use a 16-bit integer. Also it means you aren't using up a port that could otherwise be used for actual network communication.
Abstract sockets also make for a nice process existence monitoring mechanism since any processes connected to the bound socket are guaranteed to be immediately notified when the process dies.
It's only an alternative if you have a backing swap device. zram does not have this requirement, so (aside from using no compression) it's basically the only solution for some scenarios (e.g. using entire disk(s) for ZFS).
Surge protectors definitely help handling surges from distant strikes, but they won't survive a more direct one. Lightning measures in the millions of joules, well above what any available surge protector is rated for. Given that lightning is an arc through air, breaking the circuit once the surge has started won't save you if your circuit gets a direct or near-direct hit.
Don't houses have spark gaps for that sort of thing? I don't remember this being a problem since I was a kid, when we used to have to unplug TVs and modems
Edit: come to think of it that's when I moved to New England so it could just be the nonexistence of lightning here. Which I do miss.
My parents lost their treadmill during a storm in a midwest US house built circa 1998. I think the power came as a surge through the grid rather than directly from the environment, though.
Surge protectors are not rated for lightning. There are protection systems for lightning (ham radio operators use them), but they're quite a bit more expensive and also involve driving a copper stake into the ground to establish a preferential path for the lightning.
Which is how grounding systems work in houses as well. Where I live, it's required code to have a 6 foot grounding rod driven into the ground, connected to your breaker panel. That's why modern houses in North America have 3 prong outlets instead of just 2.
New Zealand household grounding legislation[1] also allows a long horizontal grounding wire, or connection to the reinforcing within concrete foundations.
I've only seen rods - likely the easiest solution but also maybe I've not had much exposure to newer builds.
Grounding in very dry areas is more tricky, so US legislation will likely be different in very dry areas - maybe requiring a maximum resistance and testing?
AFAIK in New Zealand neutral is not tied/bonded to earth at the house but only at the substation. That's to (1) avoid the house earth floating to mains voltage in a specific double fault situation (neutral return failed open circuit plus house earthing failure equals danger since the outside of metal appliances are usually earthed), and (2) avoid corrosion due to long term leakage currents. We've also got less tingly 240 Volts here.
I tried to search for some better info on earthing but only found an unreliable source that said:
There is not one standard ground resistance threshold that is recognized by all agencies. However, the NFPA and IEEE have recommended a ground resistance value of 5.0 ohms or less. The telecommunications industry has often used 5.0 ohms or less as their value for grounding and bonding.
From comment about UK having three earthing standards:
TT - Terre Terre or Earth/Earth, where the installation earth is actually connected directly to earth via an earth rod or similar and only phase and neutral run back to the transformer. Very common still with older housing stock, particularly with older overhead cables, though things are gradually being upgraded. The earth in a TT system is high impedance and unlikely to pass enough current to blow a fuse under fault conditions, so a separate safety device must also be fitted which these days is an RCD, and there are all sorts of rules for that
TN-S - Terre Neutral - Separate, where the installation earth is connected to an earth installation at the transformer, where the neutral is also earthed. This earth is usually conducted over the metallic sheath of an underground cable and can blow fuses without the help of an RCD, though RCDs are mandated domestically for other reasons too
TN-C-S - Terre Neutral - Combined - Separate, where the installation earth connects to the supply neutral at the service cutout of the installation (and nowhere else), while the neutral is grounded not just at the transformer, but for obvious safety reasons at several points along its path to your house too.
I would not count on a surge protector to save you if there was a direct lightning strike. Even a hefty UPS, but especially not the small ones in a power bar or some consumer electronic chargers.
Better to not have your laptop or phone plugged in at all when using it during a storm.
This seems a bit strange to me considering the default behavior is to only show a suggested command if possible and do nothing else. That means they explicitly opted into the autocorrect feature and didn't bother to read the manual first and just guessed at how it's supposed to be used.
Even the original documentation for the feature back when it was introduced in 2008 (v1.6.1-rc1) is pretty clear what the supported values are and how they are interpreted.
It didn't work for me either, but apparently one of the issues is that it assumes window.speechSynthesis is available which may be disabled via about:config > media.webspeech.synth.enabled.
For what it's worth if you have control over both client and server and don't want to limit access using a strict IP whitelist, an alternative solution that will keep your logs quieter and add additional protection is to use good old fashioned port knocking. knockd on Linux helps with automating this on the server side. Client side you can use anything (although knockd does include a dedicated client) to send your sequence of packets before actually connecting.
I really think this solution is underrated. Port knocking is robust, doesn't use any special technology, and servers using it can't reasonably be scanned for. The only real disadvantage is that any passive observer can see your knock sequence in "plaintext" (so that includes anyone logging netflow).
Even so, I don't know why OpenSSH hasn't implemented it instead of the the silly fail2ban theatre we're discussing in these comments.
One thing to help with the passive observer would be to have the knock sequence be time varying like a TOTP. It's still a very thin addition but more defense in depth the better sometimes.
lol, hadn't read all the comments before posting mine.. Have an upvote! Actually who not do both. Vary the knock code and the resulting ssh port using succesive codes.
I just checked knockd man page and it turns out it can use a one_time_sequences file that contains a sequence of port knock combinations. I wonder if this file is dynamically checked, or loaded and parsed during startup? Or could one simply echo the TOTP code straight into that file and hup the knockd service each time (let's say the TOTP interval was set to something like 5 minutes).
I wonder could you combine command line TOTP tools with port knock for a fully time-based unique knock codes? Or even use the TOTP code for the ssh port?
I think it goes without saying that you would still want to be using keys instead of passwords for the actual authentication. Port knocking should always be an additional layer, not a replacement layer.
I find adding dynamic dns entries to my firewalls much more efficient and to have a more meaningful protection value.
A timed job that checks the up of your clients and updates the firewall every 30 seconds seems a much more secure method than having a magic sequence of ports that can be captured in the wild.
It’s hard to spoof a full tcp connection (with a key) needed to update your ddns.
Best part is you can leave your ddns to a separate box or service which complicates the compromise of a single host
Generally speaking (I've not tested this kind of setup with the cosmopolitan libc) what I've done in the past with C is use something like libmicrohttpd along with some web assets linked into the executable (`xxd -i` can help you with the assets). That gives you a single (small) binary where you can use HTML/CSS/JS for the main GUI and logic.
You can then integrate additional libraries as you please, such as sqlite3 to give yourself fast, local database access over an endpoint on the embedded HTTP/S/2 (or websocket) server.
Even with node.js, it's possible to be faster and/or use less memory than better-sqlite3. For example, here is an opinionated sqlite addon I wrote that shows just that (while executing queries asynchronously): https://github.com/mscdex/esqlite
You could do the same thing with TCP/UDP, but abstract sockets give you more flexibility in naming with 108 characters vs. being forced to use a 16-bit integer. Also it means you aren't using up a port that could otherwise be used for actual network communication.
Abstract sockets also make for a nice process existence monitoring mechanism since any processes connected to the bound socket are guaranteed to be immediately notified when the process dies.