No route to host until I ping and then it works fine?
Agreed ! Also it would make graphs pretty boring ;)
A VPN is easy to setup (and I have it setup by the way), but no VPN is even easier. SSH by itself is sufficiently secure if you keep it up to date with a sane configuration. Bots poking at my ssh port is not something that bother me at all, and not part of any attack vector I want to be secure against.
Out of all the services I expose to the clear web, SSH is probably the one I trust the most.
Yeah I know, I just don't really care about that traffic to bother changing it :) Also, I'm talking about a server hosted on Hetzner, so I feel like it's scanned a lot.
I get what you say, and you're definitely not wrong to do it. But as I see it, you only saved ~80Kib of ingress and a few lines of logs in the end. From my monitoring I get ~5000 failed auth per day, which account for less than 1Mbps average bandwidth for the day.
It's not like it's consuming my 1Gbps bandwidth or threatening me as I enforce ssh key login. I like to keep things simple, and ssh on port 22 over internet makes it easy to access my boxes from anywhere.
Lol you could have read the post, he's been doing that for 20+ years
I've recently started writing JS recently, after writing C, go, shell and ruby for years.
Ended up with this gem in my code:
var total = +qty + +pool[0] - +pool[1];
I hate it.
That's interesting. Unbound doesn't support that afaik. The local data feature was requested by OP so I just provided a solution for it.
Each line is a separate lemonbar process, with its own refresh rate.
I have setup my own DNS locally with unbound(1). It blackholes domains, but I also use it as a caching + forwarder to my external DNS over TLS (for improved privacy regarding my ISP). I don't do it, but unbound let's you add local data manually to provide direct answers without forwarding it:
local-zone: "local." static
local-data: "plex.local. 10800 IN A 10.0.0.3"
local-data: "paperless.local. 10800 IN A 10.0.0.4"
local-data: "pihole.local. 10800 IN A 10.0.0.53"
[...]
Then you can either configure it to include a generated list of domains to explicitly NXDOMAIN, or just forward everything to the pihole:
forward-zone:
name: "*"
forward-addr: 10.0.0.53
Live location isn't supported. Audio messages work though.
I didn't know there was a tarpit target for iptables, that's neat. Unfortunately I run OpenBSD and pf so I can't use it, but I'll look into how it works to see if I can replicate it in my setup. Thanks !
That's more of a framework for RDP right ?
Yeah that was my question. I never mentioned docker though ?
As you please ;)
Be aware that I've been doing that for all my servers for the past 5 years and it works like a charm. I run OpenBSD, and only need to rcctl start smtpd to start sending outbound emails.
They're all sent from "root@host.domain.tld", which have neither SPF nor DMARK records, and end up in my inbox no problem (I use spamassassin as my spam filter). They won't end up on Blocklist as the volume is just waaayyyyyyy too low anyway.
Most distro provide either EXIM or Postfix installed by default, and configured to send outbound emails from localhost. All you need to do is start the service, change /etc/aliases to add root: and run newaliases.
You don't need MX records for that. MX is only needed to receive emails on a domain. Worst case is your monitoring emails will end up in spam (because there's no SPF configured for your machine), but your spam filter will eventually accept them as you move them from the spam folder to inbox.
Pretty KISS in my opinion. More than changing all your apps to use an external relay, setup accounts, yada yada...
"Ability to reboot without breaking a sweat"
Because it's the simplest form of mechanism for SPF, and the most understandable in my opinion.
a and mx mechanisms are just ip4/ip6 with extra resolving steps and more complex rules. For a selfhosted setup where you only have a single IP address, this is the most straightforward
As an example, try to guess which one of these SPF records will or will not pass SPF, given that the IP address sending emails is 1.2.3.1:
$ORIGIN domain.tld.
$TTL 1d
@ SOA pluto.domain.tld. admin.domain.tld ([…])
NS pluto.domain.tld.
NS saturn.domain.tld.
MX 10 mx.domain.tld.
A 1.2.3.5
TXT "v=spf1 a -all"
TXT "v=spf1 mx -all"
TXT "v=spf1 ip4:1.2.3.1 -all"
jupiter A 1.2.3.1
pluto A 1.2.3.2
saturn A 1.2.3.3
venus A 1.2.3.4
mx CNAME jupiter.domain.tld.
Sure we do, but you cannot expect everyone to simply run their own DNS and call it a day.
The vast majority of people don't even know that DNS even exist, let alone that your ISP can monitor/alter your traffic through it.
I've also been doing that for ~10 years. It's not the easiest service to run, but it's definitely not the one I had the most issues with. I would agree that in the professional field, there isn't much advantage to host it yourself, and I would advise going with hosted services in this case. But on a selfthosted community forum I see no reason to say such things to a new user trying it out, especially if they don't plan to host other people mailboxes.
I'd say the difficulty depends mostly on the stack you decide to run. I've tried Microsoft Exchange, which is very complex, postfix which is okay once you get the hang of the config file syntax, and opensmtpd which is delightful to configure given its simplicity. Docker also helps tremendously compared to what was available 15 years ago.
Actually delivering emails into inbox is another difficult aspect, but now there are just so many good resources to learn from that you can easily figure out what to do.
I would put my money on that too.