• 0 Posts
  • 187 Comments
Joined 3 years ago
cake
Cake day: June 18th, 2023

help-circle

  • NaibofTabr@infosec.pubtoProgrammer Humor@programming.dev𝚒𝚏...
    link
    fedilink
    English
    arrow-up
    18
    ·
    edit-2
    3 days ago

    No no, the imperative “get six” overrides the previous “buy a gallon of milk” if the “they have eggs” condition is met.

    “get six” implies x === 6 not x = x + 6, that would be “get six more

    The real problem is that “buy” was only specified in the first case. Because the conditional was met, he should get six gallons of milk but not buy them.



  • You SHOULD NOT do software RAID with hard drives in separate external USB enclosures.

    There will be absolutely no practical benefit to this setup, and it will just create risk of transcription errors between the mirrored drives due to any kind of problems with the USB connections, plus traffic overhead as the drives constantly update their mirroring. You will kill your USB controller, and/or the IO boards in the enclosures. It will be needlessly slow and not very fault-tolerant.

    If this hardware setup is really your best option, what you should do is use 1 of the drives as the active primary for the server, and push backups to the other drive (with a properly configured backup application, not RAID mirroring). That way each drive is fully independent from the other, and the backup drive is not dependent on anything else. This will give you the best possible redundancy with this hardware.


    1. If you are not already, start using a password manager. BitWarden, or VaultWarden if you want to self-host. Reset all of your passwords, starting with email addresses that are used to access other accounts, then financial accounts, government service accounts, healthcare accounts, etc.

    2. Reset the PIN numbers on your bank/credit cards, starting with whichever you use most frequently.

    3. Freeze your credit. Check your credit reports and make sure there aren’t any new accounts you don’t recognize.

    4. Consider getting a new phone number.

    5. Consider getting a new email address (with a provider that at minimum provides encryption at rest).

    6. Keep the official notice of the theft of your identity somewhere safe. You may need it to help prove that any new accounts created with your information are not legitimate.

    7. If you do find out that someone is illegally using your identity, check with your relevant government office. In the US you can apply for a new SSN if there’s evidence that someone is actively impersonating you, though of course changing it creates a host of follow-on problems for you.

    8. Identity information is a commodity item on the Internet, with both legal and illegal information traders. If you’re concerned about exposure, you might want to pay for a data removal service like EasyOptOuts or Delete Me. These services are not scams, they are effective for what they do, but they only work with legally registered data brokers. Having them submit deletion requests for your data will mostly remove it from OSInt sources and people search services. They can’t actually delete your information from any sources that are trading it illegally or take it off the “dark web”, and can’t protect you from someone opening new credit accounts or impersonating you for job applications.
      The effectiveness of this is limited, and it costs money, which is why it’s low on this list.

    9. Depending on what you do for work, consider letting your manager know. If your personal details could be used to access your employer’s information system for some malicious purpose, giving them notice might help them avoid trouble and might save you from taking the blame for some illegal activity. I would mostly recommend this if you work for some government agency, healthcare organization, or financial institution where malicious access could harm other people.




  • A modern OS running with low RAM (e.g. an RPi with 2G) is going to fill the RAM pretty quickly just in normal operation, so a larger swap space will allow it to run more efficiently as it regularly moves things in and out of swap. You still want to have some overhead to allow for storing the live RAM for hibernation, which with a small amount of RAM is likely to be near 100%. Therefore, running with 3x RAM for swap space is recommended.

    it only needs to be at least the size of RAM

    Yes, technically it only needs to be the size of the RAM, but no matter how much RAM you have some of the swap space will be used at any given time for the swap file during system operarion. If you only have exactly as much swap space as RAM, there won’t be enough available swap space to store the entire live RAM for hibernation.

    The size of the swap file and the size of the live RAM image at any point is unpredictable, therefore 1.5x RAM is the lowest recommended value that is probably safe for hibernation, assuming the swap file is not being used heavily enough to be 50% of the RAM. If you can’t provide at least that much disk space for swap, you should disable hibernation.


  • This is the best simple guideline: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/managing_storage_devices/getting-started-with-swap#recommended-system-swap-space

    Basically, if you want your system to be able to hibernate then you need enough swap space to sustain both the active swap file and a full image of the live system RAM (hibernate = suspend-to-disk, and uses the swap space). The swap file could be as large as the RAM, so a safe value is 2x the RAM. If you don’t want to dedicate that much disk space to swap, the safe option is to disable hibernation but note that suspend-to-disk is safer for system recovery in the event of power failure.

    If you’ve ever had a Linux system go into hibernate and fail to awake, lack of swap space was probably the reason.

    In Red Hat’s chart where they recommend 1.5x RAM for 8-64 GiB, basically you’re hoping that your system is never completely using all of the RAM. If you do cap out the RAM such that the swap file plus the in-use memory is greater than 1.5x RAM, and the system goes into hibernate, it will not recover because there isn’t enough free swap space to store the in-use memory. You have to make a judgment call when you set up your system about how you’re going to use it - whether you expect to be using 100% of the RAM at any point, whether you’ll remember to close some running applications to free up memory every time you leave the system idle long enough to go into hibernate, whether other users will be using the system (if they’re logged in then they are partially using the RAM and the swap), etc.

    Deciding how much swap space you need is a risk management decision based on your tolerance for data loss, application stability, and whether or not you need hibernation.



  • Whatever you do, and whoever you end up working with, document document document. Take notes.

    And I mean on paper, in a notebook, something that can’t crash or get accidentally deleted and doesn’t require electricity to operate.

    You’re doing this for yourself, not for a boss, which means you can take the time to keep track of the details. This will be especially important for ongoing maintenance.

    Write down a list of things you imagine having on your network, then classify them as essential vs. desired (needs and wants), then prioritize them.

    As you buy hardware, write down the name, model and serial number and the price (so that you can list it on your renter’s/homeowner’s insurance). As you set up the devices, also add the MAC and assigned IP address(es) to each device description, and also list the specific services that are running on that device. If you buy something new that comes with a support contract, write down the information for that.

    Draw a network diagram (it doesn’t have to be complicated or super professional, but visualizing the layout and connections between things is very helpful)

    When you set up a service, write down what it’s for and what clients will have access to it. Write down the reference(s) you used. And then write down the login details. I don’t care what advice you’ve heard about writing down passwords, just do it in the notebook so that you can get back into the services you’ve set up. Six months from now when you need to log in to that background service to update the software you will have forgotten the password. If a person you don’t trust has physical access to your home network notebook, you have a much more serious problem than worrying about your router password.



  • You can just use openssl to generate x509 certificates locally. If you only need to do this for a few local connections, the simplest thing to do is create them manually and then manually place them in the certificate stores for the services that need them. You might get warnings about self-signed certificates/unrecognized CA, but obviously you know why that’s the case.

    This method becomes a problem when:

    1. You need to scale - manually transferring certs is fine maybe half a dozen times, after that it gets real tedious and you start to lose track of where they are and why.
    2. You need other people to access your encrypted services - self-signed certs won’t work for public access to an HTTPS website because every visitor will get a warning that you’re signing your own encryption certs, and most will avoid it. For friends and family you might be able to convince them that your personal cert is safe, but you’ll have to have that conversation every time.
    3. You need to implement expiration - the purpose of cert expiration is to mitigate the damage if the cert private key leaks, which happens a lot with big companies that have public-facing infrastructure and bad internal security practices (looking at you, Microsoft). As an individual, it is still worthwhile to update your certs every so often (e.g. every year) if for no other reason than to remind yourself how your SSL infrastructure is connected. It’s up to you whether or not it’s worth the effort to automate the cert distribution.

    I’ve used Letsencrypt to get certs for the proxy, but the traffic between the proxy and the backend is plain HTTP still. Do I need to worry about securing that traffic considering its behind a VPN?

    In spite of things you may have read, and the marketing of VPN services, a VPN is NOT a security tool. It is a privacy tool, as long as the encryption key for it is private.

    I’m not clear on what you mean by “between the proxy and the backend”. Is this referring to the VPS side, or your local network side, or both?

    Ultimately the question is, do you trust the other devices/services that might have access to the data before it enters the VPN tunnel? Are you certain that nothing else on the server might be able to read your traffic before it goes into the VPN?

    If you’re talking about a rented VPS from a public web host, the answer should be no. You have no idea what else might be running on that server, nor do you have control over the hypervisor or the host system.






  • I tend to agree with this line of thinking. If you’re trying to hire an effective problem solver, well the first step to solving any problem is understanding the problem - the whole problem - and often more importantly the context in which the problem exists.

    And while my first reaction is to be frustrated with the person asking for a solution to such a vague problem… in the real world problems are rarely clearly stated, and frequently misstated. Investigating the apparent conditions of the problem is always necessary, and generally the fastest path to resolution.


  • Based on the provided information, there are some switches of unspecified type in one room and a light bulb of unspecified type in another room. There is no power source, nor do we know if there is even wiring between the switches and the bulb. For all we know, the switches and the bulb are still in their product packaging waiting to be installed by an electrician.

    The bulb is not controlled by any of the switches in any meaningful manner.

    Also, per the problem specification, I am allowed to visit the room with the light bulb only once. I am not allowed to visit the room with the switches, or operate the switches.

    The comment in the original image is the most rational possible answer to such an exercise. Poorly stated problems are a waste of time.

    *Edit: You know what, scratch all that, none of it really matters.

    I’m not messing with an unknown electrical circuit without seeing the circuit diagram and verifying any relevant lockout/tagout. People die from that shit.


  • This assumes several things to be true, which might not be true:

    • power is available/the upstream circuit is on (always a bad assumption to make)
    • the bulb is an incandescent type that will generate an appreciable amount of heat in a short amount of time
    • the bulb was in the off state before you changed the position of any switches, and has been off long enough to be cold
    • the bulb is connected to any of the switches
    • the bulb is connected to only one of the switches (parallel circuits are a thing, as are multi-switch lighting circuits)

    If any of the above is not true, the conclusion is invalid.