chiisana

You didn’t wreck the big corps. You opted yourself out of their warranty thereby saving them any money they would’ve had to spend on repairing your purchase during the defined warranty window. If anything you lined their pockets by making yourself a cheaper customer.

The anon user could be used by an advanced alien specie, trying to understand the technology underpinning operating systems in order to launch an attack against the humanity. Thus, the developer is specist against non human entities.

No? Too extreme? Where do we draw the line between leaping to conclusions and labeling people? Refusing to change a gendered pronoun to a gender agnostic one isn’t a great look. One can most certainly make an argument that it’s a sexist view of the landscape in favouring male users over others; but no where in the discourse that I could see did they attack transgenders, so it wouldn’t be fair to label the developers as transphobic. I think it’d be prudent to address the issue as they are, not leap to conclusions and apply labels.

Need the phone to sync, the watch can keep track of health data until it gets back close to the watch. If you have the cellular version, and an applicable data plan, you can make and receive calls with it without your phone, too.

Strictly speaking, they also have wifi, but power management on them (due to the limited battery) makes it pretty difficult to actually use effectively.

Pretty sure UniFi Access can also control the lock mechanism they’re describing. So it’d be a nicely integrated solution.

You aren’t wrong, but that’s also the point… It makes no difference if they’re securing a VPS or their own network. In fact, they’d need to secure both systems — and I’ve seen so many neglected VPS’s in my time… I’ll be the first to admit: myself included.

There are very valid reasons to need a tunnel; CGNAT, ISP level port blocking, network policies (ie campus dorm), etc etc etc. However, if you read the other replies, this doesn’t seem to be the case here, and OP doesn’t seem to even know why they’re hiding their IP. They just wanted to do it because of some loose notion that it may be nice since they’re opening up their port.

For someone in that situation, introducing a whole stack that punches through the firewall via an VPN or alike introduces way more risk than just securing down the gateway directly, and handle the other issues as they come up.

Say someone wants to take your service down, you’ve got 500Mbits line at home ISP, and 10Gbits on your VPS; they sends 1Gbits of traffic to your VPS, your VPS happily tries to forward 1Gbits, fully saturating your home ISP line. Now you’re knocked offline.

Say someone discovers the actual IP, dropping traffic from anything else other than the VPS doesn’t help if they just, again, flood your line with 500Mbits of traffic. The traffic still flows from the ISP to your gateway before they could be dropped.

Say someone wants to perform SQL injection on your website, there is no WAF in this stack to prevent that.

Say someone abuses a remote code execution bug from the application you’re hosting in order to create a reverse shell to get into your system, this complex stack introduced doesn’t protect that.

You’ve provided a comprehensive guide, and I don’t want to single you out for being helpful, but I must ask: What problem does this solve, and does OP actually have the problem this stack can solve? From the replies we’ve seen in this thread, OP doesn’t have sufficient understanding to the full scope of the situation. Prescribing a well intended solution might be helpful, but it gives a false sense of security that doesn’t really help with the full picture.

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/<postid> 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.

Again, that’s what you’d like to achieve, but why?

Without the reason, there is no way to provide a useful answer that would adequately address the underlying reason.

Other ramifications aside, it wouldn’t be that costly to splice real time.

YouTube has standard profiles of video and audio quality levels. As long as the video stream is the same quality, the stream can basically be concatenated one after another without any meaningful over head. Try it: ffmpeg -f concat -i files.list -c copy output.mp4 for two files with same codec (audio and video) was processed at over 900x speed for me with just CPU.

So all YouTube would need to do is transcode the ads they’d intend to splice in into the standard formats they’d offer the stream at (which they’d already have the video transcoded into), and splice the ads they’d want to show in realtime at request time.

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.

Locks can happen by registrar (I.e.: ninjala, cloudflare, namecheap etc.) or registry (I.e.: gen.xyz, identity digital, verisign, etc.).

Typically, registry locks cannot be resolved through your registrar, and the registrant may need to work with the registry to see about resolving the problem. This could be complicated with Whois privacy as you may not be considered the registrant of the domain.

In all cases, most registries do not take domain suspensions lightly, and generally tend to lock only on legal issues. Check your Whois record’s EPP status codes to get hints as to what may be happening.

Their grievances with the Lemmy dev team is pretty universal. I can’t wait for Sublinks to become the mature release.

For projects, where they have their community presence also speaks to their ideology. Those projects’ communities chose to move off of Reddit, and be on Lemmy; those projects’ communities chose the instance they’re on.

One may plea ignorance in the early days of Lemmy, that they’re misguided by the instance description; but now a year later after all the drama, their decision to remain there will start to influence who will be able to interact with their community.

I have no sympathy for communities that chose to remain on CSAM infested instances that got defederated, and I will have no sympathy for project communities that continues to associate with ideologies by the ml admins.

It’s a shame bar washroom stalls didn’t get disrupted by VC money; it remains a pure place where people continue to post whatever they want without a care as to who sees it.

Rather !announcements@lemmy.openmw.org, !general@lemmy.openmw.org, !bugs@lemmy.openmw.org, … etc.

So much more flexibility for organizations to build structured communities!

My understanding is that the “host” instance of the community is responsible in sending things out to the subscribers. As such, when users from B post on a community on C, C will broadcast the activity of user from B to instance A’s federated copy of community on C, and users on A will see the post from the user from B. They should also be able reply to each other’s comments on the community on C.

Intel generally target Xeon products for enterprise servers and workstations. They usually also come with very high price tag to differentiate from retail offering. For most of us, it’s generally drooling over them for 5 years, wait until they’re out of warranty, and buy them from companies offloading servers that are no longer under warranty for a still-hefty-but-more-affordable price.

Yeah… you’re the one asking questions. I’ve not asked any.

Good luck with your life.

I’m not taking sides. I’m saying I don’t hear the similarities and there’s stats supporting it. That’s all. That’s what I said earlier. No need to take sides.