• 1 Post
  • 422 Comments
Joined 6 months ago
cake
Cake day: March 20th, 2025

help-circle

  • That’s called split DNS. You can probably use that term to figure out if a particular router supports it. Basically, you would tell the router “if a DNS request for a specific URL is coming from a local IP, use a different (usually local) DNS table”. So like you can tell it “if a device asks for this URL, route it to this local IP instead.” So the DNS request never actually leaves your network.

    It can be handy for cases where you don’t always want to be reliant on an external DNS server. For instance, if your internet is spotty. You don’t want your Jellyfin to stop working just because your internet went out; Everything is local, so it should be able to connect. But if you’re only using an external DNS provider, it won’t be able to connect without internet. So split DNS will allow you to connect to local services even when your internet is out.

    The big downside to split DNS is that you often run into DNSSEC (DNS over https) warnings. Since the URL was intercepted before it actually reached an external DNS server, the traffic isn’t taking the path that the service “expected” it to take. So it may throw some warnings, or refuse to connect because it thinks your traffic is being intercepted, (because… Well… It is being intercepted… By you.)


  • A stack is a group of containers that were all started together via a docker-compose.yml file. You can name the stack and have all of the containers dropped down below it. Compose is simply a straightforward way to ensure your containers all boot with the same parameters each time.

    Instead of needing to remember all of the various arguments for each container, you simply note them in the compose file and run that. Docker Compose reads the file and runs the containers with the various arguments.

    Moving from docker to docker-compose is the single largest ease-of-use change I made in my setup. If you want some help in how to use it, I can post a quick example and some instructions on setting it up. You would use cd [directory with your docker-compose.yml] to select the proper directory, then docker-compose up -d to run the compose file.

    Updating would be docker-compose down to stop the stack, docker-compose pull to pull updated images, docker-compose up -d to start your stack again, then docker image prune -f to delete the old (now outdated and unused) images.


  • I assume I need to have a domain name through a DNS service like cloudflare in order to make use of it

    Yes, you’re correct here.

    Once I have my DNS setup, how do I associate it with my server or point it through the nginx reverse proxy?

    You begin by forwarding ports 80 and 443 to your Nginx proxy server’s external ports. These are the standard ports for http and https requests, respectively. So your Nginx will immediately be able to tell if a request is http or https based on which port it is coming in on.

    Next, you would set an A name record on your domain manager. This A name record will point a subdomain to a specific IPv4 address. So for instance, maybe the name is “abs” and the IP is your home WAN IP. So whenever an http or https request comes in on “abs.{your domain}” it will get redirected to your WAN IP. If you wanted to use IPv6, that would be an AAAA name record instead… But if this is your first foray into self-hosting, you probably don’t want to use IPv6.

    On Nginx’s side, it receives all of those incoming http and https requests because the ports are forwarded to it. You configure it to take requests for those subdomains, and route them to your various devices accordingly. You’ll also need to do some config for SSL certificates, which will allow https requests to resolve successfully. You can either use a single certificate for the entire site, or an individual certificate for each subdomain. Neither is “more” correct for your needs, (though I’m sure people will argue about that in responses to this).

    So for instance, you send a request to https://abs/.\{your domain}. The domain manager forwards this to your WAN IP on port 443. Nginx receives this request, resolves the SSL certificate, and forwards the request to the device running abs. So your ABS instance isn’t directly accessible from the net, and needs to bounce off of Nginx with a valid https request in order to be accessible.

    You’ll want to run something like Fail2Ban or Crowdsec to try and prevent intrusion. Fail2Ban listens to your various services’ log files, and IP-bans repeated login failures. This is to help avoid bots that find common services (like ABS) and try to brute-force them by spamming common passwords. You can configure it to do timeouts with increasing periods. So maybe the first ban is only 5 minutes, then 10, then 20, etc…

    Lastly, you would probably want to run something like Cloudflare-DDNS to keep that WAN IP updated. I’m assuming you don’t have a static IP, and you don’t want your connections to break every time your IP address changes. DDNS is a system that routinely checks your WAN IP every few minutes, and pushes an update to your provider if it has changed. So if your IP address changes, you’ll only be down for (at most) 5 minutes. This will require some extra config on your provider’s part, to get an API key and to configure the DDNS service to point at your various A name records.

    If you need any help setting the individual services up, let me know. I personally suggest docker-compose for setting up the entire thing (Nginx, DDNS, and Fail2Ban) as a single stack, but that’s purely because it’s what I know and it makes updates easy. But this comment is already long enough, and each individual module could be just as long.




  • mic_check_one_two@lemmy.dbzer0.comtoScience Memes@mander.xyztall tails
    link
    fedilink
    English
    arrow-up
    139
    arrow-down
    1
    ·
    edit-2
    4 days ago

    Soft tissues can also become fossils under the right conditions. For an example, here is the fossil used for the B. markmitchelli holotype:

    It’s the single most detailed and complete soft tissue fossil ever discovered. It took the technician six years to extract and separate the fossil from the surrounding stone. The technician’s name is Mark Mitchell, and the species was named after him.












  • A space exploration video game. It had a famously bad launch, because the director had over-promised on basically every single feature. It was massively anticipated because the director had hyped it up so much. And when it launched, players quickly discovered that many of the promised features were only half finished, or were missing entirely. The backlash was swift, but the company said they planned to keep working on the game.

    And now many years later, the game is actually fairly solid, and basically meets the original promises. But at launch, it definitely didn’t.


  • Yes, the salt is stored right alongside the username and hashed password. The point of the salt isn’t to be unknown; It’s to make every single password unique before it gets hashed, which invalidates the hackers’ pre-generated rainbow tables. It forces them to re-generate their table for each user. Even identical passwords will create different hashes, because the salt is different for each user. Essentially requiring the hacker to brute force every single password, even after they have the database downloaded.

    Basically, the hash algorithms are known. There are a few common ones, but they’re all reliable. A rainbow table is generated by running potential passwords through each hash, and saving the results. For a simplified example: maybe for a certain hashing algorithm, “password” generates the hash “12345”. I have a pre-generated table with millions of potential passwords that tells me as much. And I have repeated this for all of the most popular hashes. This gigantic database (literally hundreds of GB in size) of millions of potential passwords and resulting hashes for the most popular algorithms is my rainbow table. This took hours of cooking my CPU to generate.

    So I hack an unsalted password database, and find a bunch of hashes that are listed as “12345”. I can now guess that they’re probably using that specific hash algorithm, and can immediately crack a bunch of passwords purely because I have already brute-forced them before I hacked anything. I can also crack the rest of the passwords much faster, because I’m only needing to brute force the one algorithm I know they used, instead of being forced to hash with all of them.

    But now let’s say it’s a salted hash instead. When I hack the database, my pre-generated rainbow tables are useless. Because now “password” is not being hashed as “12345”. It’s being hashed as something entirely different, because the salt is added before it gets hashed. Even if multiple users use “password”, it still doesn’t help me because each of their salts is unique. So even if two different users use “password”, they’ll each return different hashes. So I need to recreate my rainbow table for every single user. Even if two users both used “password” I’ll still need to check each one individually, with their unique salts.

    This doesn’t completely invalidate the breach, but it drastically slows down my ability to access individual accounts. The goal is simply to slow me down long enough for the company to be able to send out “hey, change your password” notifications, and for the users to do so. Without a salt, once I have the database, I instantly know which hash the company is using. And I can immediately access a bunch of accounts using my pre-generated rainbow table. But with the salt, I’m still forced to crack each user individually.

    To be clear, weak passwords will still crack faster. A good password guessing attack doesn’t just brute force. It starts with known lists of common/popular/weak passwords, because that known list of weak passwords will often get you into an account extremely quickly.


  • You can’t reverse the hash, but you can generate hashes until you find a match.

    That’s called a rainbow table attack, and that’s why you should salt your hash. This salt basically appends a unique string of characters to every password before it goes into the hash. Let’s say your users are dumb and use “password” for their password. If a hacker has pre-generated a rainbow table, (which is extremely time and resource intensive), then they’ll instantly crack that as soon as they get a match on those common passwords. Even if they haven’t generated a rainbow table, they can just look for identical hashes and guess that those users are using common passwords.

    But if you salt it, it’ll slow the hackers down drastically by invalidating their pre-generated table. Each user has their own salt stored alongside the username and hash, so User 1’s hash actually saw “password19,jJ03pa5/-@“ while user 2’s hash saw “passwords)205JrGp02?@-“. Because each of their salts are unique, their resulting hashes are unique too. Even though they used the same password. Now the hackers need to crack the hash for each user, by incorporating the existing salts for each user. They’ll start with the weak and common passwords first, which is why it’s still best practice to use strong passwords. But they can’t actually start the rainbow table process until after they have hacked the info, and they’ll need to create fresh tables for every single user.