Search the Community

There instructions have been tested on FreeBSD 12.1! First of all we want to install update the package repository: pkg update If you have never used pkg probably you will be asked to install it. Now run this command to install php7.4 and nginx pkg install php74 nginx We can install the most common php extensions running this command: pkg install php74-extensions php74-mysqli php74-mbstring php74-curl php74-gd The following extensions will be installed: php74-ctype: 7.4.14 php74-curl: 7.4.14 php74-dom: 7.4.14 php74-extensions: 1.0 php74-filter: 7.4.14 php74-gd: 7.4.14 php74-iconv: 7.4.14 php74-json: 7.4.14 php74-mbstring: 7.4.14 php74-mysqli: 7.4.14 php74-opcache: 7.4.14 php74-pdo: 7.4.14 php74-pdo_sqlite: 7.4.14 php74-phar: 7.4.14 php74-posix: 7.4.14 php74-session: 7.4.14 php74-simplexml: 7.4.14 php74-sqlite3: 7.4.14 php74-tokenizer: 7.4.14 php74-xml: 7.4.14 php74-xmlreader: 7.4.14 php74-xmlwriter: 7.4.14 Enable nginx and php service to automatically start sysrc nginx_enable=yes sysrc php_fpm_enable=YES We can start nginx and php for the first time by running service nginx start service php-fpm start You can open now your web browser and type the server ip in the address bar. You should see a page like this We are going to configure nginx now. Open the file nginx.conf located in /usr/local/etc/nginx and modify the section "server": server { listen 80; server_name _; root /var/www; index index.php index.html index.htm; location / { try_files $uri $uri/ =404; } location ~ \.php$ { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; } location ~ /\.ht { deny all; } } Change mydomainname.com with your domain (or server ip). We can test now if php is working correctly. The files of your webiste will be hosted in the folder /var/www (you can change it in the configuration above). Create a new file inside that folder and call it index.php with this content: <?php phpinfo(); Now open again the browser and type the ip address/domain name and you should see something like this: The server is working properly and you can upload now your script You might need to install more php extentions according to the requirements of your script

There was a time, when Metin2 was still a recent game, when it was fairly easy to perform Layer 7 attacks on FreeBSD servers, or even hack into them. Much software was shipped with insecure defaults, and it was expected from the user to properly secure it. This has changed, and now MySQL is only listening to localhost by default, Apache is for the most part an unnecessary relic from the past, root user cannot login to ssh, and so on. But there is a part of the structure that has always been extremely vulnerable: the website, particularly the cheap webhosts many people opt for when they need to use certain poorly written CMS or Forum software that doesn't play well with Nginx. Since the needs of a game server (payment, voting and so on) can hardly be covered by any off-the-shelf solution, there will often be a need for some php script directly pulling data from the database to show a player ranking, or similar functions. This script can be repeatedly hit by one or multiple IP addresses and eventually overload the MySQL database which your game happens to use as well; eventually, both your game server and website go down. And no, Cloudflare will not help you unless you pay money and/or configure it extensively and properly, a process I may explain some other time. Today we are going to introduce two extremely easy solutions to mitigate this sort of attack I described with the help of nginx and a bit of mysql. Two stage rate limiting The first technique is rate limiting. It involves throttling repeated request from the same IP, particularly to php files which are the ones that consume by far more resources in the server. Hitting anything else is unlikely to cause any harm. In order to enable rate limiting, first we must add in the http context a "zone" where IPs are saved: limit_req_zone $binary_remote_addr zone=www:10m rate=5r/s; This will create a 10 mb memory zone to store a log of connections; if any of them exceeds 5 requests per second, they will be refused with a 503 error. But for this to actually work we must add this extra line into the php part of the server context - just mind the first two line heres and ignore the others that are there for context: location ~ \.php$ { limit_req zone=one burst=20 delay=10; limit_req_status 444; try_files $uri =404; fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_index index.php; include fastcgi_params; } Besides specifying where to perform this rate limiting (.php files), the settings enabled here make the experience a bit smoother by allowing the client to send a burst of up to 20 requests/second before refusing subsequent requests. Finally, the delay parameter indicates that when the connection speed exceeds 10r/second, the subsequent requests will be served with a delay. The second limit_req_status line instructs to give an empty response (444) instead of the default 503 error to excess connections, slightly reducing the server resources needed to deal with the presumed attack. FastCGI cache: serving stale content Now this is all fine and well, but what happens if we are attacked from multiple IPs? The feared DDoS! Well, it depends on what our hypotetical php script is exactly doing. If it's simply pulling data from the Database, we can use the proxy cache to force NGINX to serve such pages from a cache and avoid making repeated connections to the database. Let's define our cache in the http context: fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=mycache:10m inactive=10m; fastcgi_cache_key "$request_method$host$request_uri"; fastcgi_cache_use_stale updating; The first line creates a cache zone in memory of 10 mb, and specifies that if there are no requests for 10 minutes, the cache will be refreshed anyway. The second line specifies the arguments to use for creating a key (a sort of hash) in the cache for this request. In practice this means that if, for example, the query string is different in two requests they will still be considered to be the same request and for caching purposes, as the query string is not part of this "key". And the third line and most relevant means that while the cache is updating, the client will not wait for said update to finish before serving the requested content;instead it will serve the outdated ("stale") version of the page. Since every request normally triggers a cache update, this technique reduces the number of times the php script is actually executed during a flood enormously. (On a side note, this setting also allows us to show stale content when the backend is not responding. This is exactly what Cloudflare does with its "offline mode". We can enable this behavior by adding further triggers:) fastcgi cache use stale updating error timeout invalid_header http_500 http_503; Finally and to use the cache we defined in a location (in this case it must be the php location since its a fastcgi cache) we add this. Second line specifies for how long a 200 OK response is valid; other response codes will not be cached: fastcgi_cache mycache; fastcgi_cache_valid 200 5m; The icing in the cake: limit MySQL connections by user What about scripts that UPDATE the database? Things can get nasty here, since there's no cache to speak of all we can do is limit the total amount of requests that can be made to the backend and the database. In this case, nginx is not going to help; instead, create a specific user for your website different from the game user in MySQL and set a strict limit of connections. This means such attack will not take down the database. create user 'website'@'someip' identified by 'somepassword'; grant usage on account.* to 'website'@'someip' with max_user_connections 10; As an extra measure you can set more strict rate limits for the most vulnerable POSTing scripts in nginx (register, login...). Be aware you need to place specific locations (such as login.php) above the wildcard *.php location in the nginx config: location /login.php { limit_req zone=one burst=5 delay=2; limit_req_status 444; fastcgi_pass unix:/var/run/php-fpm.sock; include fastcgi_params; } And that is all you need to prevent your php scripts from being flooded. Of course, that's only one of the vector attacks, but also the most overlooked, yet easiest to fix. PHP programmers may also add extra checks in their code for repeated connections - memcached is your friend. But that's outside of our scope here.

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.

Hello community, As I already have some years of experience installing webservers and developing websites, I decided to share one of the methods I usually use for small and big websites. If you don't know anything about web server configuration and don't want to learn, you don't need to follow an old tutorial on google in which you may not even be able to start your website. In this topic I will explain how to install CyberPanel + OpenLiteSpeed. What is CyberPanel? CyberPanel is a control panel open source where you will manage your websites. What is OpenLiteSpeed? OpenLiteSpeed is the best, fastest and most secure alternative open source to apache and nginx. My site uses htaccess how do I convert it? You dont need convert anything, OpenLiteSpeed can load your apache rules. Note: The openlitespeed rules are loaded at startup and not in real time, you after editing your rules must restart the controller. (Don't worry, you can restart the openlitespeed easily with 3 clicks through the cyberpanel) Do you really advise the use of CyberPanel + OpenLiteSpeed? Yes, in my opinion CyberPanel with OpenLiteSpeed besides its great performance and the safest choice. In my opinion with years of experience testing web panels, CyberPanel is superior to any other panel, be it paid or open source too. I don't understand any of this, is it difficult to learn how to use? No, you don't even need to run commands on your machine other than the one installation command. All the configuration of your websites will be done through the browser using CyberPanel. Requirements Centos 7.x, Centos 8.x, Ubuntu 18.04, Ubuntu 20.04 Python 3.x 1GB or more RAM. 10GB Disk Space. Setup CyberPanel + OpenLiteSpeed [Hidden Content] Questions? Comment, as soon as possible I will answer. Best Regards, Papix

Hello, today I will introduce steps to install a web server under FreeBSD. We need to install some programs: Main Programs -MySql56 Server -Appache24 -PHP 5.6 -Php 5.6 extensions -php 5.6 extra-extensions Advanced Firewall -IP Filter -mod_security -mod_antiloris -mod_evasive Before you begin configuring the web server you must install PKG. In FreeBSD console type: Command1: pkg after Y -> ENTER ( to confirm install) After : pkg update Installing and configuring MySQL. Now the mysql server : In the freebsd console type these commands : pkg install mysql56-server echo 'mysql_enable="YES"' >> /etc/rc.conf service mysql-server start --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Now create the mysql " root " user : mysql -u root GRANT ALL PRIVILEGES ON *.* TO root@"%" IDENTIFIED BY 'password' WITH GRANT OPTION; flush privileges; exit Where does the password, you put your desired password. DONE mysql Installing and configuring Apache24. pkg install apache24 The following command: echo 'apache24_enable="YES"' >> /etc/rc.conf --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Now open winscp and navigate to /usr/local/etc/apache22/httpd.conf In httpd.conf looking for the following line: # ServerName www.yourdomain.com:80 And delete # from you httpd.conf (# ServerName www.yourdomain.com:80 ) Delete # --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Now start the service : service apache24 start READY. Now to test if it works. Open a webpagee, and type the ip adress used for VDS (VPS ) If everything is OK should appear in the website: It Works !! Installing and configuring PHP 5.6 The command : pkg install php56 pkg install mod_php56 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Open /usr/local/etc/apache24/httpd.conf : And verifi if you have this line : LoadModule php5_module libexec/apache24/libphp5.so If there is no add manually. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- You open the FreeBSD console and put it and ENTER command: cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Now let’s configure Apache. Open the file /usr/local/etc/apache24/httpd.conf and look for the following line: DirectoryIndex index.html And change it so it reads as follows: DirectoryIndex index.html index.php --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Now apache just needs to know what it should parse the PHP files with. These two lines should be added to the httpd.conf file, and can be put at the bottom if needed: Or search in httpd.conf lines that start with new line AddType and start with these two: AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- If want to use PHP code inside of .htm files you can just add on those extensions. AddType application/x-httpd-php .php .htm .html --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- As an optional step, if you’d like to add multilanguage support to Apache, uncomment the following line( in httpd.conf) : Include etc/apache24/extra/httpd-languages.conf service apache24 restart service mysql-server restart --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Okay, now to test if it works php. Type this command in freebsd console : # echo "<? phpinfo(); ?>" >> /usr/local/www/apache24/data/index.php [Hidden Content] And type the ip on used by VDS (VPS) on a web browser. Installing and configuring php 5.6 extensions and extra extensions. pkg install php56-extensions pkg install php56-mysqli pkg install php56-mysql pkg install php56-gd pkg install php56-openssl DONE Varnish cache > Best Http accelerator pkg install varnish Then rc.conf : echo 'varnishd_enable="YES"' >> /etc/rc.conf Starting varnish . /usr/local/etc/rc.d/varnishd start Check if varnish really run? /usr/local/etc/rc.d/varnishd status varnishd is not running. Now, View varnish configuration ee /usr/local/etc/varnish/default.vcl Inside the file I see these : # Default backend definition. Set this to point to your content # server. # # backend default { # .host = “127.0.0.1”; # .port = “8080”; # } It means the content need to run on port 8080. Remove all # mark to be like this : backend default { .host = “127.0.0.1”; .port = “8080”; } 127.0.0.1 =replace with you ip host (vps, vds ) etc... save the file. Change apache configuration to run on port 8080. ee /usr/local/etc/apache22/httpd.conf Changer : Listen 80 with : Listen 8080 save the file. Restart apache : service apche24 restart Now retry to run varnish ? /usr/local/etc/rc.d/varnishd start Chech varnish : /usr/local/etc/rc.d/varnishd status P.S : you can enable varnish log echo 'varnishlog_enable="YES"' >> /etc/rc.conf /usr/local/etc/rc.d/varnishlog start Security Antiloris protection Slowloris allows a single machine to take down another machine’s web server with minimal bandwidth and side effects on unrelated services and ports. The tools used to launch Slowloris attack can be downloaded at [Hidden Content] Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. It accomplishes this by opening connections to the target web server and sending a partial request. Periodically, it will send subsequent HTTP headers, adding to—but never completing—the request. Affected servers will keep these connections open, filling their maximum concurrent connection pool, eventually denying additional connection attempts from clients. Install this : pkg install mod_antiloris Find the following line in your httpd.conf ( and uncomment it ? If there is this line after installing mod_antiloris add manually. #LoadModule antiloris_module libexec/apache24/mod_antiloris.so ModSecurity pkg install www/mod_security ModSecurity requires firewall rule definitions. Most people use the OWASP ModSecurity Core Rule Set (CRS). The easiest way to track the OWASP CRS repository right now is to use Git. Let's make a directory for all our ModSecurity related stuff, and clone the CRS repository under it. pkg install git mkdir -p /usr/local/etc/modsecurity cd /usr/local/etc/modsecurity git clone [Hidden Content] crs Copy the default ModSecurity config file, and fetch a necessary file which is currently not included in the package: cp /usr/local/etc/modsecurity.conf-example modsecurity.conf fetch [Hidden Content] cp crs/modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf Now we create an Apache configuration snippet in Apache's modules.d directory. It loads the ModSecurity module, and includes the configurations and CRS: ee << EOF > /usr/local/etc/apache22/modules.d/000_modsecurity.conf # Load ModSecurity # Comment out the next line to temporarily disable ModSecurity: LoadModule security2_module libexec/apache22/mod_security2.so <IfModule security2_module> # Include ModSecurity configuration Include etc/modsecurity/modsecurity.conf # Include OWASP Core Rule Set (CRS) configuration and base rules Include etc/modsecurity/modsecurity_crs_10_setup.conf Include etc/modsecurity/crs/base_rules/*.conf # Add custom configuration and CRS exceptions here. Example: # SecRuleRemoveById 960015 </IfModule> EOF When the configuration is all set, simply restart Apache, and confirm that ModSecurity is loaded by checking Apache's log file: service apache22 restart Log file saved to : /var/log/httpd-error.log Hopefully, the log will show something like this: ModSecurity for Apache/2.4.2 ([Hidden Content]) configured. ModSecurity: APR compiled version="1.4.8"; loaded version="1.4.8" ModSecurity: PCRE compiled version="8.34 "; loaded version="8.34 2013-12-15" ModSecurity: LIBXML compiled version="2.8.0" What log says is diferent by appache version Now that ModSecurity is active, try making a suspicious request to your web server, for instance browse to a URL [Hidden Content]. The CRS has a rule against this type of request. After browsing to the URL, you should now see this request logged in /var/log/modsec_audit.log. You'll notice that the request succeeds, and the response is sent to the browser normally. The reason is that ModSecurity runs in DetectionOnly mode by default, in order to prevent downtime from misconfiguration or heavy-handed blocking. You can enable blocking mode simply by editing modsecurity.conf and changing the following line : SecRuleEngine On Again, restart Apache. Now, make the same suspicious request to your web server. You should now see a "403 Forbidden" error! In practice, it's probably best to keep SecRuleEngine DetectionOnly for some time, while your users exercise the web applications. Meanwhile, you should keep an eye on /var/log/modsec_audit.log to see what is being blocked. If there are any false positives, you need to mitigate this by writing custom exceptions. Mod_evasive -DOS Hash Table Size -DOS Page Count -DOS Site Count -DOS Page Interval -DOS Site Interval -DOS Blocking Period -DOS Email Notify -DOS System Command -DOS Log Dir -Whitelisting IP Addresses Coming soon If you know other vulnerabilities leave a message and i edit solving. Going to edit my post time. When I have time,about security. If you need to install more extensions, leave message in topic. And I'll edit the post and fill you: D If you have errors, such as missing libraries or other errors will ask something in the topic. All steps tested on FreeBSD 10.1

This is a Debian 7 nginx, MariaDB, and PHP-FPM (+phpMyAdmin) installation guide. Note on MariaDB: This is meant to be a REPLACEMENT of MySQL. It should work where MySQL works. 1. Installing and configuring nginx. # apt-get install nginx # service nginx start Now if you open your IP address or website address in your browser you should see a "Welcome to nginx!" page. This means you've successfully installed nginx. Now to configure... # nano /etc/nginx/sites-available/default Under the Server section set your "server_name" to your FQDN (fully qualified domain name). Don't forget to include "index.php" on the "index" line. It should look somewhat like this when finished: server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; root /usr/share/nginx/html; index index.php index.html index.htm; # Make site accessible from [Hidden Content] server_name mywebsitedomain.com; Scroll down to the Location section and uncomment the necessary lines. Make modifications as shown: location ~ .php$ { try_files $uri =404; fastcgi_split_path_info ^(.+.php)(/.+)$; # # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini # # # With php5-cgi alone: # fastcgi_pass 127.0.0.1:9000; # # With php5-fpm: fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; } CTRL+X, Y, Enter. Now you need to edit the nginx.conf file: # nano /etc/nginx/nginx.conf Set your "worker_processes" equal to your amount of cores. In this case I'll be using 4. Set your "worker_connections" equal to the input of the following command: # ulimit -n Change "keepalive_timeout 65;" to "keepalive_timeout 15;" then add these lines under the http block: client_body_buffer_size 10K; client_header_buffer_size 1k; client_max_body_size 8m; large_client_header_buffers 2 1k; client_body_timeout 12; client_header_timeout 12; send_timeout 10; CTRL+X, Y, Enter. You can test your configuration before proceeding, and if there are any mistakes you will be notified what they are and on which line. # nginx -t A correct modification of the configuration should output this data: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful Restart nginx: # service nginx restart 2. Installation of MariaDB. # apt-get install python-software-properties # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db # add-apt-repository 'deb [Hidden Content] wheezy main' # apt-get update # apt-get install mariadb-server mariadb-client -y Set the root user password for mysql when prompted. This is how you enter the prompt, when finished just type "quit": # mysql -v -u root -p Enter the root sql password you just chose. It will look like this, and you can figure out more things by following the notes: Welcome to the MariaDB monitor. Commands end with ; or g. Your MariaDB connection id is 2579 Server version: 10.1.1-MariaDB-1~wheezy-wsrep-log mariadb.org binary distribution, wsrep_25.10.r4123 Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. Reading history-file /root/.mysql_history Type 'help;' or 'h' for help. Type 'c' to clear the current input statement. MariaDB [(none)]> You can check the status of the server like this: # service mysql status Example output of command: [info] /usr/bin/mysqladmin Ver 9.1 Distrib 10.1.1-MariaDB, for debian-linux-gnu on x86_64 Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. Server version 10.1.1-MariaDB-1~wheezy-wsrep-log Protocol version 10 Connection Localhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime: 11 hours 8 min 3 sec Threads: 1 Questions: 44634 Slow queries: 0 Opens: 431 Flush tables: 1 Open tables: 113 Queries per second avg: 1.113. 3. Installation of PHP-FPM # apt-get install php5 php5-fpm php5-mysql # nano /etc/php5/fpm/php.ini Scroll down to the line "cgi.fixpathinfo=1" and uncomment it. Change the value from 1 to 0. Restart the service: # service php5-fpm restart Create a phpinfo page: # nano /usr/share/nginx/html/phpinfo.php Here are the contents of the file you've created: <?php phpinfo(); ?> CTRL+X, Y, Enter. Now in your browser, navigate to your IP address or domain followed by the phpinfo.php file. Here's an example: [Hidden Content] 4. Installation of phpMyAdmin # apt-get install phpmyadmin Select either option and hit OK. Even though we aren't using apache2 or lighttpd, we can make this work with nginx. Select "<Yes>" when prompted to configure database for phpmyadmin with dbconfig-common. Enter the SQL password you chose earlier as the "administrative user" password. Now enter a password for use with phpMyAdmin. Now to make it work with nginx we're going to use a symlink: # ln -s /usr/share/phpmyadmin/ /usr/share/nginx/html # service nginx restart Navigate in your browser to your IP/domain name and append a "/phpmyadmin" to the end like this: [Hidden Content] You can now login with the username root and password chosen earlier. You can use phpMyAdmin to easily setup databases and user accounts for anything you want to install that requires SQL.

Hey @ all For that people who are using Debian 6 and Apache could this be very nice! People who are using nginx, you are normaly safe, but if you fuck your configs up, slowloris can be a problem for you, too 1. What is slowloris? Slowloris is a perl script, which allows you to open hundreds of sessions on your webserver and hold them open! So your webserver crashes if it reaches ~700 connections at the same time 2. How to fix it? 1. Download and extract the mod wget ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/mod_antiloris-0.4.tar.bz2 tar -jxvvf mod_antiloris-0.4.tar.bz2 cd mod_antiloris-0.4/ 2. Install the compile kit: apt-get install gcc apache2-threaded-dev3. compile mod_antiloris /usr/bin/apxs2 -i -c mod_antiloris.c4. import the mod to apache echo "LoadModule antiloris_module /usr/lib/apache2/modules/mod_antiloris.so" > /etc/apache2/mods-available/antiloris.load a2enmod antiloris5. restart it /etc/init.d/apache2 restartI hope you enjoy it!Kind regards