Shogun

very exciting story, when's the netflix series coming up?

Thank you, not anymore though.

Hello everyone. As some may know, I make a living from securing servers against ddos attacks and intrusions, among other less exciting administrative tasks. I also mantain a blog about FreeBSD which you can visit here [Hidden Content] where I try to share some tutorials I wrote on common tasks on FreeBSD. I would like today to write a word of warning to those who are considering their security, as well as a sort of answer to someone who suggested I should publish my system because others are profiting from it. My first thought is I don't give a crap if you pay 400 euro to some random dude you're the one getting scammed not me. If you wonder what am i talking about: In the past I posted occasionally some configurations for the pf firewall and other useful materials, and more recently I coded, with my basic knowledge of PHP, a simple and poorly written script to whitelist IPs on your firewall, which I named Gatekeeper. (By the way I do not recommend you to follow any of my posts you see anywhere except for those in the blog which I do keep reasonably updated) Anyhow back to the topic I have installed this script, or system, for a number of clients who wanted to have a better chance of resisting DDoS attacks. I consider it a tool in my arsenal, rather than some definitive solution to attacks. In other words, it's not something you can install with a nice installer script and sleep better at night. It's just a quick and dirty fix to a very specific problem, one which I had to perfect with various additions until it became sort of foolproof. There are many other problems or attack vectors that this script will do nothing about. Regardless, quite a lot of people have seen fit to take this script and resell it to others, in most cases for a higher price than I was charging myself for my full service. It is also vox populi that there is this portugese guy whose name would be pointless to repeat and who "sells" a "protection system" which basically consists on a bunch of firewall configurations and a proxy whose only function is hide the fact that the one who is attacking you in the first place is himself. Needless to say none of these people have much of a notion about security, but that never stopped the bold and the brave from making a buck in the scene did it? Let me get this straight: just like an antivirus won't save you from getting hacked if you use 1234 as password and believe in nigerian prince, there's no "file" or "config" or "solution" that will save you from DDoS attacks. The only defense against a DDoS attack is having the expertise and skill on your side. But I don't intend this to become an advertisement for my services, which I cannot provide as much as I they are demanded. But I have been there, I have mindlessly copied things thinking they would magically fix stuff without me needing to understand them in the first place. If you are worried about DDoS attacks in general, but you have no particular enemies, you will probably get attacked by our portuguese friend, and you may just play along with the extorsion just to get rid of it. Or you may have other attackers who actually want to see you down rather than make money, in which case you should contact someone who knows what he is doing. By the way... FreeBSD 14 is out. It has a much newer PF on it than FreeBSD 13, where you can do some cool stuff. FreeBSD 13 also has a much newer PF than the PF on FreeBSD 12 which is probably older than you. Just so you can start seeing the tip of the iceberg of the problem with just copying some pf.conf files and why I'm not "sharing the stuff": because there is nothing to share unless one day I decide to write a whole book I would be fooling you if I told you X is going to keep you safe. Ah, and Linux is trash. Have a nice day.

The default socket path in MySQL changed many years ago. Here's the wrong, but "easier", way to fix it: Find your my.cnf: mysql --help Edit it and add or edit this line: socket = /tmp/mysql.sock

MySQL 5.5 was released in 2010 and has been End of Life for years. Even 5.6 is ancient. On December 31st, 2018, MySQL version 5.5 entered End of Life status. Any server currently running MySQL 5.5 will not receive any updates, bug fixes, or security patches for MySQL until MySQL is updated to a version 5.6 or later. As far as I recall from my youth, you do not need any configuration change or upgrade process to use mysql 5.5 data with 5.6, but it is always advised to run mysql_upgrade after importing your data.

Great tutorial. However I'm skeptical about a real life scenario with a free CDN. Let's remember Cloudflare released not long ago their free Wireguard based VPN. Sounds great doesn't it? Except it's hardly usable at all because many sites are blocking it straight away. Back in the day I tested paid CDN -Rackspace, MaxCDN - for file distribution and it was... pretty bad. One has to be careful with any sort of cache as an outdated cache will mean the client downloading files over and over every time. Moreover when we consider most of players would be located in a geographically small area, the need for a CDN is perhaps questionable. In any case I'm looking forward to people reporting their experiences with this, if it actually works it could be very valuable for peak traffic scenarios.

People can report stuff you upload to Google Drive or Mega claiming it's infringing their copyright. Free stuff isn't really free, it comes at the cost of handing over control over your data and your privacy. Anyhow if you don't have a big server you won't have thousands of people trying to download your files so you don't need load balancing. You won't have haters reporting your client to MEGA or Google and getting you suspended either. On the other hand, I do consider Amazon buckets and SaaS in general to be unnecesary expenses when there is a world of software you can host yourself for free in a simple Proxmox server. [Hidden Content] I am not a developer like most people here are are, but a systems administrator. "The time you spend configuring a centos server" -as you describe it- is not a burden like it's for you, it's literally my job. And I have plenty of work thanks to people like you who think because they know a programming language or two, they know anything about the systems that lie under them; I have some news for you: you don't. So it's great that Cloudflare caters to people like you and make a business out of it, some of us like to have control over our infrastructure and pay only for the metal it's running in. Also your thinking that changing a DNS in CF when your host goes down is cutting edge technology is so ridiculous I won't even comment of it. Romanian hosts? I think you are confusing your home internet -which is indeed fastest in the EU, and second cheapest after Poland- with servers. It's okay, you're just a programmer after all. As a matter of fact, Romanian datacenters have poor connectivity when compared to other EU countries. Of course, it's still much better than, say, Russia or Morocco, but at European level it's nothing to brag about, trust me.

I assume it's a bunch of servers you already paying for because you're using them for something else, not specifically rented for this. Naturally I haven't used "cloud storage" because that's marketed to developers since as a systems administrator it doesn't make sense to pay for services you can't fully control, but if you are serving files frequently to a large userbase that bill can become non-trivial.

Care to elaborate on your answer? Nginx is not "a webhost" and neither is cPanel. Cloudflare does not do load balancing in free accounts, certainly not with "simple redirects" and "quickly changing the IP" (what kind of insanity is that). Neither does sending people to a redirect based on their country qualify as "load balancing", unless the amount of users per country is predictable but still, it's a weird idea, unless we're talking about geographically better located hosts, which still isn't load balancing. Bottom line this is a developer forum, I would expect "people who don't want to deal with this tech part" to find their entertainment elsewhere.

they can have let's say main.mydomain.com which at every patchload randomly redirects to s1.mydomain.com s2.mydomain.com who are hosted on different hosts That's literally what I just described? I'm not sure what you mean with your message.

This is not counterstrike where you gonna miss a headshot if your ping is over 20ms & these days Europe is very heavily connected compared to years ago making the location a non issue compared to many other factors that affect gameplay smoothness in MMORPG. The countries with the best connectivity are Germany, France, UK and Netherlands.

it's harmless, just models converted to granny with features not supported by the game

He did You can close the topic.

Well that's a different problem. Your game is looking for /tmp/mysql.sock which is the old path of MySQL. Nowadays the default path for the socket is /var/run/mysqld/mysqld.sock. You can do one of three things: 1. Edit the path in /usr/local/etc/mysql/conf.d/server.conf (or /usr/local/etc/my.cnf or /var/db/mysql/my.cnf) to: socket = /tmp/mysql.sock and restart mysql-server 2. Edit the hardcoded path of this socket in the source and change it to /var/run/mysqld/mysqld.sock 3. Edit your CONFIG/conf.txt files and replace SOCKET with 127.0.0.1

Your screenshot says FreeBSD 11.2 that version is End of Life for a while. Update your FreeBSD: freebsd-update upgrade -r 12.3-RELEASE

Memory leak? that's how much RAM it uses, 2GB for a server isn't enough.

Undo that last change then. You ARE running MySQL and set the database details in the site config right? Check /var/db/mysql/<yourhostname>.err for hints and/or set in the php code: mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); If you are running MySQL and it reports no error, try: /usr/local/etc/php.ini Uncomment and set: session.save_path = "/tmp" Then restart apache24 If you need further help, ask me on Discord, as this is all of no interest to others being so specific.

In: public function read($session_id) { $data = $this->select("SELECT session_data FROM {$this->table} WHERE session_id = :id", array('id' => $session_id), true); return $data['session_data']; } change this to: public function read($session_id) { $data = $this->select("SELECT session_data FROM {$this->table} WHERE session_id = :id", array('id' => $session_id), true); return $data['session_data'] ?? ''; } If you keep having issues I suggest you install php5 (if it's still a thing) which is the version this page was developed in.

Find in the page the following: SessionHandlerInterface And paste here what comes after that.

I'll make a wild guess: pkg add php74-session service apache24 restart

Try loading the leaves of any tree in Paint.net and then save them back as DXT3 with mipmaps on

So I was checking out Aeldra's Discord and apparently their patcher was slow as a snail, which reminded me of the opening of WoM3 back in the day. The typical OVH dedicated server has a bandwidth of 100 Mbps upstream if I remember well, although you can buy more bandwidth (which costs as much as the server itself) and some come with 1 Gbps. Anyway that's a gigaBIT per second which makes around 150 megabytes per second. Pretty good but not enough for a big opening thing where you have hundreds of users expecting to download at 4 Mbps each. NGINX (the one you pay for) includes some load balancing mechanism but we can emulate it with the free one. We are in fact sorta randomly distributing people among a number of servers. So here is how you can just throw money at the problem (if you have this problem you're probably gonna get rich anyway) and just rent more servers or just use a bunch of VPS you have lying around. I'm not going to make lengthy explanations here if u need help you know where to find me and my paypal. So we have our url let's say patch.wom2.org pointing to our main webserver, Here's where the magic happens (http context) split_clients "${remote_addr}" $destination { 50% alpha.patch.wom2.org:8080; 30% bravo.patch.wom2.org:8080; 20% charlie.patch.wom2.org:8080; } Here we have three subdomains pointing at three different servers (any place where u can install nginx will do, you can measure speed at the endpoint with nethogs for example to see which is slower and reduce the percent of requests that are sent there). The OG web server can serve files too (here it's alpha). Do not use Linux if you can avoid it. And do NOT use Apache. FreeBSD is the king when it comes to streaming sry Linux fanboys. The three servers must of course have identical copies of your files (use rsync when updating patches) and the same nginx configuration. Here's the config for the OG server which redirects the user to the previously chosen subdomain when downloading from the pack directory (server context obviously) server { listen 51.84.214.58:80; server_name patch.wom2.org; root /home/www/patch.wom2.org; location /1.1.1.1/ { log_not_found on; return 302 [Hidden Content]; } } Finally here's the config of one of our load balancing server, which in its root folder contains the contents of 1.1.1.1, in fact alpha.patch and patch are in the same folder. server { listen 51.84.214.58:8080 sndbuf=32k; server_name alpha.patch.wom2.org; root /home/www/patch.wom2.org; location / { limit_rate 4096k; if_modified_since off; expires epoch; } } As you can see I limited speed to 4 Mbps to avoid people with a big pipe taking all the bandwidth. Remember no Cloudflare here, CF is not for file serving.

So what's in /usr/local/www/apache24/data/inc/_config.php? I'm not psychic

Is your DNS even working? ee /etc/resolv.conf If there is no nameserver, it is commented out, or the file is empty, write this on it: nameserver 8.8.8.8 Then execute: local-unbound-setup Whether this commands work or not shouldn't make a difference. Now try: pkg update && pkg upgrade Finally I suggest adding this on /etc/rc.conf asit has been known to speed up pkg dramatically in certain cases; ip6addrctl_enable="YES" ip6addrctl_verbose="NO" ip6addrctl_policy="ipv4_prefer" Now try again what I wrote in my first post.

Wow, Apache. Feels like 2008 all over again. In the shell type: pkg add php74-pdo_mysql service apache24 restart