Then it’s the same situation. Find a box, setup an LDAP service, populate it, and you’re good to go. That’s it.
Use unprivileged port numbers for your services.
It’s not fine. Easiest way to rack up utilization on your server is getting hits on all the default service ports. Change that port to any unprivileged port to avoid that somewhat. Not every bot crawler is doing port scans on random non-commercial and unidentified IP space.
What you’re describing is security through obscurity, but switching from the default port has other benefits like the above.
Not sure I can expand on it a ton more in a way that will make sense if it already doesn’t sound familiar.
Basically, there are various methods to authenticate yourself to most services. Password is usually the weakest and most succeptible to brute-force and social engineering. There’s certificates, key pairs, RBAC…etc. You can even setup TOTP/MFA really easily for anything that supports it these days. Just don’t leave a service hanging out on the Internet to get brute-forced by password though.
If you’re unfamiliar with this, start with SSH and key pairs. It’s probably the simplest intro and you can be up and running to try it out in seconds.
You cant. You can only do your best to make it as secure as possible, but given enough time, someone can break it.
Basic tips:
For ssh specifically, lock down your sshd config, make sure only key-based auth is enabled, and maybe as an extra step, create a dedicated user, and jail it by only allowing it access for the commands you need to interact with.
Then you don’t understand how it works with local auth services.
I think you’re missing the point of LDAP then. It’s a centralized directory used for querying information. It’s not necessarily about user information, but can be anything.
What you’re asking for is akin to locally hosting a SQL server that other machines can talk to? Then it’s just a server. Start an LDAP server somewhere, then talk to it. That’s how it works.
If you don’t want a network service for this purpose, then don’t use LDAP. If you want a bunch of users to exist on many machines without having to manually create them, then use LDAP, or a system configuration tool that creates and keeps them all eventually consistent.
CUPS already does this though, and that’s where I’m getting confused. This is the entire point of CUPS. If your issue is with drivers, then you need to configure it to just print from its own driver via a spooled queue like PostScript, or maybe IPP.
Gotta say, this question and the process explained threw me for a loop.
You have a network print server where it’s advertising an available printer, but instead of the native printer system on a client device, you want to NOT use the CUPS server to print? That’s what it’s there for. I’m confused on why you have it then.
If your goal is just to have clients print as directly as possible to a printer…you already have that with CUPS running. I guess I’m not getting why submitting via web form is useful in this case.
How would describe the “reduced attack surface” of something running a container?
Have a look here: https://www.backblaze.com/blog/ssd-edition-2023-mid-year-drive-stats-review/
I’ve never had a single problem with Crucial, Seagate, WDC. I’ve had a few issues with Seagate 990 Pros having issues, though it was later made known that Samsung had some bad batches out in the world. Hopefully that is not the case anymore.
Just stick to the brands with multi-year warranties.
Super cool story though.
As is your want to do. I’ve run thousands of different combinations and type of SMTP related services at all stages of processing, and I’ve seen the above 100% of the time.
You are talking about receiving mail from another forwarded entity. It’s not the same thing. You’re also proving my point, because you’re already getting your intake handled upstream, so there you go. What I said is accurate. 👍
Jake, the OP is asking for something that actually works. You’re just throwing out some random bits that says you get two ports to talk to each other, but like I said…that’s not how this works. You can read my other post in the thread if you want, or go read about actually hosting SMTP service out in the world, and the nightmare it is.
Mail hosting is not that simple anymore. Your understanding of how it works is missing an entire world of complex issues that you need to solve outside of just hosting a mail server with an open SMTP port.
The biggest certainty is that just having an open port for an SMTP server dangling out there means you will 100% be attacked. Not just sometimes, non-stop. So you don’t want to host on a machine with anything else on it, cuz security. So you need a dedicated host for that portion, and a very capable and restrictive intrusion detection system (let’s say crowdsec), which is going to take some amount of resources to run, and stop your machine from toppling over.
Next, you need all your secondary record systems (SPF, DKIM, DMARC) pointing at a defined and unchanging record for your SMTP server, so you’ll need a static IP. If you don’t have that already, you’re kind of SOL.
Next, you’ll need to be running your own peer authentication system, then a spam filtering system (of which none of them work well without massive amounts of sample data, but you can use public lists to help block known bad actors), decent file threat scanning…you see where I’m going with this. It all takes a fair amount of resources, and even more if/when you get bad actors spamming the machine all the time.
Finally, you’ll probably want this machine completely segmented from the rest of your network, which isn’t really complicated, just costs a bit more money.
There’s a reason why mail hosts and forwarding services cost money, and still exist. It takes a large amount of effort to be somewhat secure, or at least to best of your efforts. With the added costs associated with hosting your own mail servers, most people just avoid the hell out of it. I certainly wouldn’t recommend it.
Not how that works.
That there is a spider.
A lot of manufacturers either have their own refurbished sites they sell from (warrantee and all), or some will liquidate on other places like eBay or Newegg.
If you’re looking to build, pcpartspicker is probably the most popular component configuration app these days.
You’re thinking too hard about this.
There needs to be a source of truth. LDAP is just a simple protocol that can be backed by whatever. You’re worried about the LDAP server going down, but guess what? It’s all in flat files. Go ahead and set it up in a bit repo for config management service for the server/protocol portion, and backup the DB. Easy peasy.
You can also cluster your LDAP service amongst all of your nodes if you have 3+ nodes and un-even number of them to ensure consensus amongst them. You can even back LDAP with etcd if you really want to go down that road.
You’re being paranoid about what happens if LDAP goes down, so solve for that. Any consumer of LDAP should be smart enough to work on cached info, and if not, it’s badly implemented. Solve for the problem you have, not for what MIGHT happen, or else you’re going to paranoid spiral like you are now because there is no such thing as a 100% effective solution to anything.