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