• 0 Posts
  • 140 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle
  • In the old days, it used to be a problem because everyone just connect their windows 98 desktop with all their services directly exposed to the internet because they’re using dial up internet without the concept of a gateway that prevents internet from accessing internal resources. Now days, you’re most likely behind your ISP router that doesn’t forward ports by default, and you’re only exposing the things you’d actually want to expose.

    For things you’d actually want to expose, having a service on the default port is fine, and reduces the chances of other systems interacting with it failing because they’d expect it on the default port. Moving them to a different port is just security through obscurity, and honestly doesn’t add too much value. You can port scan the entire public IPv4 space fairly quickly fairly cheaply. In fact, it is most likely that it’s already been mapped:

    https://www.shodan.io/host/<your-ip-here>

    Keeping the service up-to-date regularly and applying best practices around it would be much more important and beneficial. For SSH, make sure you’re using key based authentication, and have password based authentication disabled; add fail2ban to automatically ban those trying to brute force. For Minecraft, online mode and white listed only unless you’re running a public one for everyone.


  • Stop addressing them as “normies” would be a great start.

    Can’t speak for rest of the Fediverse as I’m not super active on microblogging anymore, but at least here on Lemmy, there is such a strong “in” culture and quirky skewed perception of the world, and often times come off as actively hostile against those that do not share the same quirky skewed world view. The anti-AI, anti-corporate, would rather shoot myself in the foot if it’s not FOSS, etc kind of views, with their own strong vocal proponents, comes off as unwelcoming. People are addicted to socials because of the positivity they can get, not the negative sentiments that’s often echo’ed.

    Amongst those that doesn’t share the kind of view, you’d already be looking at an extreme small minority that might be willing to give the platform a try, but as long as the skewed perception of the world dominates the discussions, you can expect them to go back to main stream centralized platforms where they can get more main stream view points based discussions.



  • I’m not saying you’re wrong — I’ve even upvoted your earlier comments because I’m generally in agreement; you’re an instance admin judging by your handle, go and check the vote history yourself lol.

    I’m saying people shouldn’t force their janky unproven solo solution on to someone else who doesn’t have their level of distrust, and would just rather trust the multibillion multinational corporation, when all they want is something that’s been working fine for them for all they care.


  • There’s always the add more of everything so something could fail without impacting the stability aspect, and that’s great for a corporation needing the redundancy; but it’s probably prudent to not forget there’s also the “I’m interested in learning” aspect, where people running a home server to play with software side of things.

    You’re spot on in that we’d need to know what it is that OP would like to do with the system, but I’m getting the feeling that stability isn’t that high of a concern just yet.


  • Until the basement floods and the server goes offline for a few days; or botched upgrade that’s failing quietly; over zealous spam assassin configuration; etc etc

    It sounded like they were trying to archive things from Gmail to their own server, so just cut the middleman jank out, and let the wife continue to use her Gmail as intended.






  • I’m aware this is the selfhost community, but for a company of 20 engineers, it is probably best to use something commercial in the cloud.

    Biggest pain point was for our ops guy, who constantly had to stay behind to perform upgrades and maintenance, as they couldn’t do it during business hours when the engineers are working. With a team of at least 20, scheduling downtimes could get increasingly more difficult.

    It also adds an entire system to be audited by the auditors.

    The selfhost vs buy commercial kind of bounces back and forth. For smaller teams, less than 5 to 10 engineers, it might be a fun endeavour; but from that point on, until you get to mega corp scale with dedicated ops department maintaining your entire infrastructure, it is probably more effective to just pay for a solution from a major vendor in the cloud instead.



  • There’s also the problem that sadly Lemmy is filled with vocal users with skewed view of the world, and they tend to be extreme polarizing. The “if you’re not one of us, who firmly believes the world should work a certain way, and if you’re not willing to shoot yourself in the foot with a shotgun to prove it as a point, then you’re one of them; you should get the eff off of Lemmy and crawl back to Reddit” kind of way. They’re so scared of losing that pedestal that they’re going to go out of their way to alienate anyone who doesn’t drink their koolaid and push them off the platform so they can remain dominant. Sadly, these people also never really learned much of the real world, so those that are more experienced / educated gets pushed off the platform, and we end up with a bunch of weird superstonk culty kind of vibe everywhere.

    I find myself more and more just make a comment and don’t look back. It’s quite literally futile and pointless trying to expect any discussion of any actual sustenance. You wonder why it’s just shitposting… well this is why.





  • You do not strictly need to open a port – tunnelling through another server could be a solution, but let’s park this for a moment.

    What you are describing as “open a port in my firewall” is actually many smaller parts, some key ones that may be relevant are:

    1. (Firewall) Telling your gateway to not drop traffic when someone outside is request to connect to the specified port; and
    2. (Port Forwarding) Telling your gateway to forward traffic from that port to a specific computer’s specific port within the network (i.e.: your computer, port 80)
    3. (Running a service) Having a service (say for example, a web server) running on the specified computer’s specific port answering requests

    All three things (amongst others that’s not immediately relevant here) must be properly setup for any network request to happen. What do I mean by that? I can have a port not drop traffic (i.e.: firewall down). When someone from outside of my network trying to access the port, they’d get to my router, but nothing happens because there’s no where for the packet to go. I can have my firewall down, and port forwarding enabled, but the web server isn’t running. When someone from outside of my network trying to access the port, they’d get to my router, get forwarded to my computer, but because the web server isn’t running, nothing happens. Someone from outside of my network can only gain access to my service (and only that service) only when all three are setup and working together.

    “But what about the hackers?”

    Yes, the untrusted networks, such as the internet, could be a bad place with people with bad intentions. There are many different things they could do to make things undesirable; let’s explore some of them together.

    Say we want to run an instance of Lemmy using a new experimental server software (i.e.: not the official Lemmy server). Now, unfortunately, some racist people decided to come and make racist posts on our instance. A tunnel / proxy doesn’t solve this. Instead, we have to ban their accounts. It may not seem much, and it was completely innocuous to our system, but we’ve just dealt with our first attack.

    One of those racist person happens to be the “scary hacker” type, so they came back and try to brute force our admin account’s password to unban themselves. This is not too bad, but we need to address this somehow. A tunnel / proxy doesn’t solve this; but something like Fail2Ban might be able to look at the login failures and put a temporary IP ban on the attacker.

    They’re back! And this time, they decide to repeatedly hammer the search function, thereby taking all the resources from our database, so our instance cannot serve other users. A tunnel / proxy doesn’t solve this; but some rate limiting configurations in the server application might help.

    They’re not happy about getting rate limited there. So this time, they decided to continuously post garbage to our instance, not even normal requests, just connect to our web server, and spam AAAAAAAAAAAAAA… non stop, at such a quick pace that it fully saturates our network connection, and we cannot do anything else on the network. A tunnel / proxy doesn’t solve this; we’d need to block them from the firewall. This is not entirely true; blocking them at the firewall doesn’t solve the problem, because the traffic still goes from the ISP to the firewall, which will still be saturated before the firewall could drop the traffic, but to use as an example it narrates a potential problem well enough.

    They’re angry now, and they pay a few bucks to botnets to have many many many thousands of infected computers to spam AAAAAAAAA… non stop at our service. Again, a tunnel / proxy doesn’t solve this; we’d need to have something smarter than just our firewall and individually ban the IP addresses. This is where we’d need the professionals with typically commercial offerings.

    It could escalade the other direction. Instead of attacking with aim to take the service down, they could do other damaging things. Say they found a problem with our server software. Instead of giving the /post/ a numeric id, they can do something fancy like /post/1 AND 1 ==1; UPDATE users SET banned = FALSE WHERE username = 'racist-user' and unban themselves. A tunnel / proxy doesn’t solve this; but a Web Application Firewall (WAF) might.

    Now it escalades more. Through a complex chain of intentionally malformed image uploaded to the instance, the image resizer attempting to resize the image, which gets tripped over by the malicious image, which causes a remote code execution, which they use to create a remote access trojan (RAT) shell so they can connect to our server and run commands. This is usually the “big bad” that most people are scared of… someone from outside of their network having access to their system and thus gains the ability to extract their documents or encrypt their photos etc. A tunnel / proxy doesn’t solve this; but a WAF or an anti-virus on the server itself might.

    Through these albeit simplified but lengthy exploration, we see that none of these would actually be addressed by a tunnel / proxy. There are other possible attacks, and they’d require other solutions.

    So, goes back to what I was saying earlier… it is important to know why you’re trying to do something. Blindly prescribing tunnel / proxy doesn’t actually solve the problem.


  • What kind of attacks, against what service?

    DDoS? It’s cheaper to hire botnets to attack than to defend. You’d most likely still be knocked off even just by the amount of traffic that leaks through your proxy before the VM gets cut off at the data centre. Specifically: it is much more likely that data centres will give higher thresholds before null routing your VM than your residential ISP would be wiling to tolerate.

    Brute force on shell? SQL injection? Remote shell execution? Deploying the extra layer will not protect you from these as your own proxy will not give you WAF.

    It is always important to know why you’re doing something, before anyone can prescribe a solution.



  • What is your objective for ‘hide server IP’?

    Privacy to disconnect your identity from the service? There is no solution to this. Full stop. Even with Tor, the state backed acronym entities will figure it out if you get on their radar.

    If your objective is to keep your service online, you’re going to be hard pressed to find cost effective alternatives… Commercial solutions are expensive, like, “if you have to ask about the price, you can’t afford it” expensive.

    Alternatively, you can try to roll your own by having many many proxy servers yourself… but if you’ve got a target on your back, you’ll never have enough instances; DDOS-as-a-Service is much cheaper than the amount of reverse proxies required to keep your service online.

    There’s probably other use cases, but chances are, you’d still be hard pressed to find a solution that’s cost effective.