>>2330
In terms of hosting, all you need is a spare computer and an ISP that won't block you for opening up port 80.

In terms of DDOS protection, you're basically out of luck trying to do this diy. Not only will your ISP probably blackhole you if they see a surge of traffic, but dealing with a ddos is a matter of raw resources and you're unlikely to win against a determined adversary. But unless you're running something controversial, your average forum will be fine just setting up fail2ban. There are other players with enough bandwidth to soak up ddos attacks though if this is a particular concern.

Password prompts are useless against ddos since you're still serving requests while what you want to do is drop packets as early on as possible (cloudflare probably has dedicated asics to inspect packets as soon as it enters their network and drop them based on heuristics).

DDoS and DoS are (Distributed) Denial of Service attacks. It's not a matter of security, it's matter of how much traffic you can handle, and what is your capacity of cutting out the undesired traffic.
Your ISP/server host might already have the capacity to protect you, while others will not want to do business with you, and will nullroute your traffic (it will get discarded without reaching you).
Depending on what you host, you might not need any kind of such protection.
Cloudflare has ot

>>2331
And a static IP, which is not common for residential clients.

DDoS and DoS are (Distributed) Denial of Service attacks. It's not a matter of security, it's matter of how much traffic you can handle, and what is your capacity of cutting out the undesired traffic.
Your ISP/server host might already have the capacity to protect you, while others will not want to do business with you, and will nullroute your traffic (it will get discarded without reaching you).
Depending on what you host, you might not need any kind of such protection.
Cloudflare has other advantages (and disadvantages), like hiding your IP, and being a MitM glownigger operation.

>>2331
And most often a static IP, which is not common for residential clients.

>since you're still serving requests
Is there any way to change the order of this, so to send packets to the server, a password would have to be entered first?
>In terms of DDOS protection, you're basically out of luck trying to do this diy.
How about a physical bandwidth manager like this one?
https://shop.netgate.com/products/1541-base-pfsense
And if that isn't good enough, is there some other way of serving live-content that is immune to these kinds of attacks?

>>2334
No, not unless you fundamentally redesign the architecture of the internet. See linked paper for how to prevent ddos by redesigning connections using a capabilities-based security model.
>>2334
Even if you have the best in class hardware for processing inbound packets, you're still bottlenecked by the link between you and your ISP. And most ISPs are not prepared to handle a huge spike in traffic and will blackhole you until the traffic decreases.

If you want to serve live-content immune to DDOS, at a fundamental level you need to work around the single point of failure. Either you add enough redundancy or indirection through geo-distributed servers (á la cloudflare), or you can try to get fancy with some sort of p2p-esque scheme. But I'm less familiar with the p2p solutions in this area, and you're basically trading off ease of content updates (trivial if a single server, hard when needing to deal with distributed systems that you don't even own) with robustness against ddos attack.

>>2332
>And a static IP
You can work around this with a dyndns type setup. And in practice your assigned ip usually remains fixed unless your reboot the modem so it shouldn't be too much of a hassle. Definitely not a commercial-grade solution though.

>>2335
>See linked paper
The solution proposed in this article requires the involvement of ISPs, at least to update routers. So is a purely software-based solution that would put the computing burden of authentication on users impossible because of the physical infrastructure of the internet?

Could the address of a website not be obfuscated in some way, and periodically changed, so that the only way to find it and send packets to it, would be for the client to run a program that solves a complicated math problem or something?

>>2337
> requires the involvement of ISPs, at least to update routers
Yeah hence why I mentioned it requires basically redesigning the architecture of the internet.
>So is a purely software-based solution
I think what you mean is whether there exists a solution that can be implemented on top of the existing routing architecture, involving only changes to the endpoints? If so, my intuition is that this is not possible because by design the way routing works on the Internet is that a client can send packets to an server without that server having prior knowledge that the client exists. And in fact, since a client can spoof the source IP the server fundamentally _can't_ be sure of the client's identity. (Note: good ISPs will have ingress IP checks and nullroute spoofed packets, but all it takes is one non-conforming ISP to allow for this).

You might be interested in the attached paper which shows that even solving a strictly simpler problem: reconstructing the path that a packet takes throughout the network (thereby preventing spoofed source IPs) is still very difficult. The authors use a very elegant packet tagging scheme and go to great efforts to maintain compatibility with the existing IP packet formats. But the fundamental limitation is that it requires a significant fraction of ISPs to adopt it, and given that packet routing is mostly done in hardware these days it will require huge costs to replace all this hardware as well. (More generally, you'll see this chicken and egg situation is the single biggest issue with bringing academic research in networking security into practice. They usually only work if there's mass adoption, but no one will be the first to adopt it due to costs).


>Could the address of a website not be obfuscated in some way, and periodically changed, so that the only way to find it and send packets to it, would be for the client to run a program that solves a complicated math problem or something?

Once you deobfuscate it on one client, you can share that deobfuscated address between all clients. The asymmetry of the Internet – that the client needs to know about the server without the server having to know about the client – makes such schemes difficult I think. Moreover the distributed nature of the ddos means that even if each client needs to solve a complicated math problem, since each node in the ddos is running in parallel this doesn't slow down your adversary by too much. And you still need to allow legitimate users as well.

Note that all of the above is for a standard single-server accessed by multiple clients type of situation. As I mentioned before, you can probably get around this by doing some sort of p2p situation where each "client" also partially acts as a server (sort of like bittorrent). But these types of protocols have issues for delivering non-static content. I'd love for someone to chime in if there's such an example, but all of the ones I've seen (e.g. ipfs) have been serving static content.

Pro-tip, if you don't want to pay extra for a VPS that has an ipv4 address, you can use this to make your ipv6 only site accessible to those who only have an ipv4 address:

http://v4-frontend.netiter.com/

You could try using ssh-copy-id to basically make it so the devices you use to log into the server is given automatic access whilst password authentication can be completely disabled which basically prevents anybody from brute forcing into your server using a password guesser script of sorts.

Oh and also, how you're even going to get started may be something to consider. For example, some people use Static Site Engines, which have features such as automatically making lists of blogs, more consistency across pages, writing articles and such in markdown etc.

But some people might prefer to write their site without one, and instead with the aid of shell scripts for both automatically generating html files to write in or again, making lists of blogs. This although can be done using locally run scripts, apache offer something called "CGI", which allows you to run shell scripts on your apache server, which could help with automating a few repetitive tasks.

https://crippled.media/free-speech-vps-providers-put-to-the-test
I was reading this later the day and realized, that those services are all good and all in terms of anonymity, but there really isn't a way to know how reliable they are. In particular when you pay a year ahead with Monero or something, who guarantees that they don't disappear tomorrow from the face of the earth? While they don't host anything illegal, they still are advertising themselves as for high-risk websites, or websites at high risk of censorship, or anonymous this and that. I'm very well aware of how hosting providers have that legal privilege in almost every country, that they can't be hold responsible for their hosting, but if 90% of their sites hosted are illegal, there probably is a case to be made against them (see those cases of "bulletproof hosting", who got taken down for that very reason.) Personally, I am not hosting anything illegal and don't plan to, but I also don't want to dox myself to my hosting provider.

Of those on the list, I've only ever tried Flokinet and Frantec/BuyVM. Flokinet only needs and E-Mail address, but they are quite expensive for a normal VPS (the cheapest option, the Romania VPS, stopped working for no reason, and when I asked they replied I should buy the other option, which was around 10 euros + 4-5 euro for IPv4. They refunded the money however, so that's good.). Within Flokinet, I tried both the web hosting and the VPS. The webhosting was okay, albeit I couldn't cope with the CPanel nonsense, which was tedious at times. In regards of the VPS, the VPS was fast and responsive and they had the newest ISO for Debian 12, which was enough for me (and shouldn't be taken for granted, as a lot of hosting providers have outdated images). An SSH-key could be added while setting it up too. A minor thing noticed, was that they added some auto-update daemon to it, which didn't bother me.

Eventually I discontinued Flokinet, because they were too expensive (around 15 euros monthly). Following that, I looked into Frantec/BuyVM. Unlike Flokinet, they require your full legal name, address, phone number. Apparently they also check those things manually, when you pay them too. Either way, I did that and it was okay. It seems they have kind of limited capacities, because every time I looked, almost all their KVM-slices were sold out, and it was only through sheer luck, that I looked into it and they weren't sold out. They cost around 7 euros. However, when I ssh'ed into the thing, it was unbearably slow. I tried several little tricks to speed up the SSH session, but it didn't improve meaningfully. The nginx server was accessible just fine and wasn't as slow, but I couldn't resolve that issue and eventually gave up on BuyVM.

Now there is Kyun, Privex, NiceVPS and the others on the list. Do any of you have experience with those? All I want is a cheap VPS without technical problems...and maybe it being reliable enough to not disappear tomorrow or something. Kyun seems okay-ish, but their FAQ and canary gives out errors for me, which gives me a bad feeling about them. I have no opinion yet on Privex or NiceVPS, but I'm curious what Brohnos know about those services (in particular how they are in practice, when actually using them).

>>3583
What I do is self-host from my home internet connection using an inexpensive, renewed mini-pc, but connect that to a VPS with wireguard, and point my domain to the VPS. That way you can protect your privacy while also having full control of your data. If the VPS provider ever goes down, I can easily switch without having lost anything. This guide explains how to set up wireguard, and it can work on any distro.
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard-on-ubuntu-20-04

>Now there is Kyun, Privex, NiceVPS and the others on the list. Do any of you have experience with those?
I've used Privex and currently use Kyun because their options are more flexible. Both are good, but I think Privex is actually more reliable.

>when I asked they replied I should buy the other option, which was around 10 euros + 4-5 euro for IPv4.
You don't need to pay extra for IPv4. Just use http://v4-frontend.netiter.com/

For a domain, you can get a subdomain for free from https://freedns.afraid.org/

Post edited on 1st Jan 2025, 1:07pm