You know on most operating systems such as Windows 8 / 10 , Mac OS X as well as GNU / Linux / BSDs (FreeBSD) etc. with graphical environments such as GNOME / KDE etc. , there is this default functionality nowadays that is helping to reduce eye strain and improve night sleep by modifying the light and brightness as well as coloring eminated by the monitor.
On Windows this technology is called Night Light and is easily enabled by nagivating through menus:
Start > Settings > System > Display > Night light > Night light settings.
Even though Night Light / and redshift monitor color warmth change is often mostly useful and have a positive impact improving sleep as well removes eye strain on Linux my experience with it is not too positive as it changes the monitor color gamma and makes it often quite reddish and annoying even through a normal day and not only night time. This makes the work experience on the computer not pleasurable thus just removing it for me and I guess for many would be a must.
Assuming that you have installed Free software OS such as Linux with redshift (note that on on older releases of Deb and RPM package based distributions: you will have to manually install it with something like:)
2. * Set the color temperature of the Monitor / Screen back to 6500K (this can be done either by the button menu that most screens have)
or manually with redshift itself by executing command:
root@linux:~# redshift -O 6500
As the screen is back to normal color gamma, its now time to completely remove redshift in order to prevent it to mess up with your monitor colors, on next PC boot or on Gnome / Mate whatever UI used session logout.
To do so issue commands:
root@linux:~# dpkg –purge redshift redshift-gtk (Reading database … 516053 files and directories currently installed.) Removing redshift-gtk (1.11-1) … Purging configuration files for redshift-gtk (1.11-1) … Removing redshift (1.11-1) … Processing triggers for man-db (2.8.3-2) … Processing triggers for hicolor-icon-theme (0.17-2) … Processing triggers for mime-support (3.61) … Processing triggers for gnome-menus (3.13.3-11) … Processing triggers for desktop-file-utils (0.23-3) … Processing triggers for menu (2.1.47+b1) …
3. Enjoy normal colors on your monitor Goodbye Forever REDSHIFT, goodbuy dark crappy Screen during the day. Hello normal Screen light !!! 🙂
After a recent new Debian Squeeze Apache+PHP server install and moving a website from another server host running on CentOS 5.7 Linux server, some of the PHP scripts running via crontab started displaying the following annoying PHP Warnings :
debian:~# php /home/website/www/cron/update.php
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/suhosin.so' – /usr/lib/php5/20090626/suhosin.so: cannot open shared object file: No such file or directory in Unknown on line 0
Obviously the error revealed that PHP cli is not happy that, I've previously removes the suhosin php5-suhosin module from the system. I wouldn't have removed php5-suhosin if sometimes it doesn't produced some odd experiences with the Apache webserver. To fix the PHP Warning, I used first grep to see, where exactly the suhosin module gets included in debian's php.ini config files.
debian:~# cd /etc/php5
debian:/etc/php5# grep -rli suhosin *
apache2/conf.d/suhosin.ini
cgi/conf.d/suhosin.ini
cli/conf.d/suhosin.ini
conf.d/suhosin.ini
Yeah that's right Debian has three php.ini php config files. One for the php cli – /usr/bin/php, another for the Apache webserver loaded php library – /usr/lib/apache2/modules/libphp5.so and one for Apache's cgi module – /usr/lib/apache2/modules/mod_fcgid.so .
I was too lazy to edit all the above found declarations trying to include the suhosin module in PHP, hence I remembered that probably all this obsolete suhosin module declaration are still present because probably the php5-suhosin package is still not purged from the system.
A quick check with dpkg , further strenthened my assumption as the php5-suhosin module was still hanging around as an (rc – remove candidate);
The last 15 years, we've been accustomed to listen about the Climate Change and the Global Warming problem. I remember for a first time heard about this possible problem from my Grandfather in late 1990's. Since then there is plenty of initiatives like Kyoto (Protocol) Convict for reduce of unwanted emissions. While browsing I found interesting video which is short overview of History of Climate Change. I think it is worthy to see it and get idea on the pure mess and lack of interest of governments to work well for solving the is issue…
There are plenty of youth organizations who claim to suggest how to solve global warming. But most of it is just talks. The fact is to stop it, the only way is by individual change of each of us. It is impossible for a consumer society to keep going. From time of creation of human, God created us not as consumers but as creator beings. Now most of us are dumb consumers hanging in front of Computer in Youtube and Facebook all day, watching post after post video after video, then you go to shop and you buy a lot of food. Because we're depressed of the unhuman way of living most of us eat plenty of food to somehow mitigate our awareness of unhappy reality (Americans are best in that). With overeating there is the increased number of health issues in us. We produce too much and consume too much, if we don't stop this parasite behavior soon it is more than clear, humans and our planet as ecosystem will not survive.
If you’re a a remote Linux many other Unix based OSes, you have defitenily faced the security threat of many failed ssh logins or as it’s better known a brute force attack
During such attacks your /var/log/messages or /var/log/auth gets filled in with various failed password logs like for example:
Feb 3 20:25:50 linux sshd[32098]: Failed password for invalid user oracle from 95.154.249.193 port 51490 ssh2
Feb 3 20:28:30 linux sshd[32135]: Failed password for invalid user oracle1 from 95.154.249.193 port 42778 ssh2
Feb 3 20:28:55 linux sshd[32141]: Failed password for invalid user test1 from 95.154.249.193 port 51072 ssh2
Feb 3 20:30:15 linux sshd[32163]: Failed password for invalid user test from 95.154.249.193 port 47481 ssh2
Feb 3 20:33:20 linux sshd[32211]: Failed password for invalid user testuser from 95.154.249.193 port 51731 ssh2
Feb 3 20:35:32 linux sshd[32249]: Failed password for invalid user user from 95.154.249.193 port 38966 ssh2
Feb 3 20:35:59 linux sshd[32256]: Failed password for invalid user user1 from 95.154.249.193 port 55850 ssh2
Feb 3 20:36:25 linux sshd[32268]: Failed password for invalid user user3 from 95.154.249.193 port 36610 ssh2
Feb 3 20:36:52 linux sshd[32274]: Failed password for invalid user user4 from 95.154.249.193 port 45514 ssh2
Feb 3 20:37:19 linux sshd[32279]: Failed password for invalid user user5 from 95.154.249.193 port 54262 ssh2
Feb 3 20:37:45 linux sshd[32285]: Failed password for invalid user user2 from 95.154.249.193 port 34755 ssh2
Feb 3 20:38:11 linux sshd[32292]: Failed password for invalid user info from 95.154.249.193 port 43146 ssh2
Feb 3 20:40:50 linux sshd[32340]: Failed password for invalid user peter from 95.154.249.193 port 46411 ssh2
Feb 3 20:43:02 linux sshd[32372]: Failed password for invalid user amanda from 95.154.249.193 port 59414 ssh2
Feb 3 20:43:28 linux sshd[32378]: Failed password for invalid user postgres from 95.154.249.193 port 39228 ssh2
Feb 3 20:43:55 linux sshd[32384]: Failed password for invalid user ftpuser from 95.154.249.193 port 47118 ssh2
Feb 3 20:44:22 linux sshd[32391]: Failed password for invalid user fax from 95.154.249.193 port 54939 ssh2
Feb 3 20:44:48 linux sshd[32397]: Failed password for invalid user cyrus from 95.154.249.193 port 34567 ssh2
Feb 3 20:45:14 linux sshd[32405]: Failed password for invalid user toto from 95.154.249.193 port 42350 ssh2
Feb 3 20:45:42 linux sshd[32410]: Failed password for invalid user sophie from 95.154.249.193 port 50063 ssh2
Feb 3 20:46:08 linux sshd[32415]: Failed password for invalid user yves from 95.154.249.193 port 59818 ssh2
Feb 3 20:46:34 linux sshd[32424]: Failed password for invalid user trac from 95.154.249.193 port 39509 ssh2
Feb 3 20:47:00 linux sshd[32432]: Failed password for invalid user webmaster from 95.154.249.193 port 47424 ssh2
Feb 3 20:47:27 linux sshd[32437]: Failed password for invalid user postfix from 95.154.249.193 port 55615 ssh2
Feb 3 20:47:54 linux sshd[32442]: Failed password for www-data from 95.154.249.193 port 35554 ssh2
Feb 3 20:48:19 linux sshd[32448]: Failed password for invalid user temp from 95.154.249.193 port 43896 ssh2
Feb 3 20:48:46 linux sshd[32453]: Failed password for invalid user service from 95.154.249.193 port 52092 ssh2
Feb 3 20:49:13 linux sshd[32458]: Failed password for invalid user tomcat from 95.154.249.193 port 60261 ssh2
Feb 3 20:49:40 linux sshd[32464]: Failed password for invalid user upload from 95.154.249.193 port 40236 ssh2
Feb 3 20:50:06 linux sshd[32469]: Failed password for invalid user debian from 95.154.249.193 port 48295 ssh2
Feb 3 20:50:32 linux sshd[32479]: Failed password for invalid user apache from 95.154.249.193 port 56437 ssh2
Feb 3 20:51:00 linux sshd[32492]: Failed password for invalid user rds from 95.154.249.193 port 45540 ssh2
Feb 3 20:51:26 linux sshd[32501]: Failed password for invalid user exploit from 95.154.249.193 port 53751 ssh2
Feb 3 20:51:51 linux sshd[32506]: Failed password for invalid user exploit from 95.154.249.193 port 33543 ssh2
Feb 3 20:52:18 linux sshd[32512]: Failed password for invalid user postgres from 95.154.249.193 port 41350 ssh2
Feb 3 21:02:04 linux sshd[32652]: Failed password for invalid user shell from 95.154.249.193 port 54454 ssh2
Feb 3 21:02:30 linux sshd[32657]: Failed password for invalid user radio from 95.154.249.193 port 35462 ssh2
Feb 3 21:02:57 linux sshd[32663]: Failed password for invalid user anonymous from 95.154.249.193 port 44290 ssh2
Feb 3 21:03:23 linux sshd[32668]: Failed password for invalid user mark from 95.154.249.193 port 53285 ssh2
Feb 3 21:03:50 linux sshd[32673]: Failed password for invalid user majordomo from 95.154.249.193 port 34082 ssh2
Feb 3 21:04:43 linux sshd[32684]: Failed password for irc from 95.154.249.193 port 50918 ssh2
Feb 3 21:05:36 linux sshd[32695]: Failed password for root from 95.154.249.193 port 38577 ssh2
Feb 3 21:06:30 linux sshd[32705]: Failed password for bin from 95.154.249.193 port 53564 ssh2
Feb 3 21:06:56 linux sshd[32714]: Failed password for invalid user dev from 95.154.249.193 port 34568 ssh2
Feb 3 21:07:23 linux sshd[32720]: Failed password for root from 95.154.249.193 port 43799 ssh2
Feb 3 21:09:10 linux sshd[32755]: Failed password for invalid user bob from 95.154.249.193 port 50026 ssh2
Feb 3 21:09:36 linux sshd[32761]: Failed password for invalid user r00t from 95.154.249.193 port 58129 ssh2
Feb 3 21:11:50 linux sshd[537]: Failed password for root from 95.154.249.193 port 58358 ssh2
This brute force dictionary attacks often succeed where there is a user with a weak a password, or some old forgotten test user account. Just recently on one of the servers I administrate I have catched a malicious attacker originating from Romania, who was able to break with my system test account with the weak password tset .
Thanksfully the script kiddie was unable to get root access to my system, so what he did is he just started another ssh brute force scanner to crawl the net and look for some other vulnerable hosts.
As you read in my recent example being immune against SSH brute force attacks is a very essential security step, the administrator needs to take on a newly installed server.
The easiest way to get read of the brute force attacks without using some external brute force filtering software like fail2ban can be done by:
1. By using an iptables filtering rule to filter every IP which has failed in logging in more than 5 times
To use this brute force prevention method you need to use the following iptables rules: linux-host:~# /sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state -state NEW -m recent -set
linux-host:~# /sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state -state NEW
-m recent -update -seconds 60 -hitcount 5 -j DROP
This iptables rules will filter out the SSH port to an every IP address with more than 5 invalid attempts to login to port 22
2. Getting rid of brute force attacks through use of hosts.deny blacklists
sshbl – The SSH blacklist, updated every few minutes, contains IP addresses of hosts which tried to bruteforce into any of currently 19 hosts (all running OpenBSD, FreeBSD or some Linux) using the SSH protocol. The hosts are located in Germany, the United States, United Kingdom, France, England, Ukraine, China, Australia, Czech Republic and setup to report and log those attempts to a central database. Very similar to all the spam blacklists out there.
To use sshbl you will have to set up in your root crontab the following line:
These crontab will download and substitute your system default hosts with the one regularly updated on sshbl.org , thus next time a brute force attacker which has been a reported attacker will be filtered out as your Linux or Unix system finds out the IP matches an ip in /etc/hosts.deny
The /etc/hosts.deny filtering rules are written in a way that only publicly known brute forcer IPs will only be filtered for the SSH service, therefore other system services like Apache or a radio, tv streaming server will be still accessible for the brute forcer IP.
It’s a good practice actually to use both of the methods 😉 Thanks to Static (Multics) a close friend of mine for inspiring this article.
If're a Linux user and you need to script certain page extraction from PDF files, crypt protect with password a PDF file or decrypt (remote password protection from PDF) or do some kind of structural transformation of existing PDF file you can use a QPDF command line utility. qpdf is in active development and very convenient tool for Website developers (PHP / Perl / Python), as often on websites its necessery to write code to cut / tailer / restructure PDFs.
1. Install QPDF from deb / rpm package
qpdf is instalalble by default in deb repositories on Debian / Ubuntu GNU / (deb derivative) Linux-es to install it apt-get it
apt-get install –yes qpdf
On RPM based distribution CentOS / SuSE / RHEL / Fedora Linux to install qpdf, fetch the respective distribution binary from rpmfind.net or to install latest version of qpdf build it from source code.
2. Install QPDF from source
To build latest qpdf from source
on RPM based distributions install with yum fullowing packages:
QPDF has a vast range of split and merge features. It can combine all the files in a folder (*.pdf), you can use it to try to recover damaged pdf files, extract individual pages from PDF, dump and reverse page range, make new created PDF with old PDF's reversed pages (pages 1,2,3,4 to become in order 4,3,2,1), apply some single pdf file metadata to multiple files.
4. Try to Recover damaged PDF file
To try to recover some damaged file with qpdf:
qpdf file-to-repair.pdf repaired-file.pdf
5. Extract certain pages or page range from PDF
It is recommended to use the version built from source to extract certain page range from PDF
If you're migrating a website from Apache Webserver to Nginx to boost performance and better Utilize your servers hardware and the websites (Virtualhosts) has sections with implemented Apache .htaccess / .htaccess password authentication, you will have to migrate also Apache directory password protection to Nginx.
This is not a hard task as NginX's password protection uses same password format as Apache and Nginx password protection files are generated with standard htpasswd part of apache2-utils package (on Debian / Ubuntu servers) and httpd-tools on CentOS / Fedora / RHEL. If you're migrating the Apache websites to Nginx on a fresh new installed server and website developers are missing htpasswd tool to install it depending on Linux distro:
On Debian / Ubuntu deb based servers, install htpasswd with:
apt-get install –yes apache2-utils …
On CentOS / Fedora … other RPM based servers:
yum -y install httpd-tools …
Once installed if you need to protect new section site still being in development with password with Nginx, do it as usual with htpasswd
Note that if .htpasswd file has already exist and has other user records, to not overwritted multiple users / passes and let all users in file login to Nginx HTTP auth with separate passwords, do:
In the article I’ve examined a number of Linux kernel sysctl variables, which significantly improve the way TCP/IP networking is handled by a non router Linux based servers.
As the time progresses I’ve been continuing to read materials on blogs and internet sites on various tips and anti Denial of Service rules which one could apply on newly installed hosting (Apache/MySql/Qmail/Proxy) server to improve webserver responce times and tighten the overall security level.
In my quest for sysctl 😉 I found a few more handy sysctl variables apart from the old ones I incorporate on every Linux server I adminstrate. The sysctl variables improves the overall network handling efficiency and protects about common SYN/ACK Denial of service attacks.
Here are the extra sysctl variables I started incorporating just recently:
############ IPv4 Sysctl Settings ################
#Enable ExecShield protection (randomize virtual assigned space to protect against many exploits)
kernel.randomize_va_space = 1
#Increase the number of PIDs processes could assign this is very needed especially on more powerful servers
kernel.pid_max = 65536
# Prevent against the common 'syn flood attack'
net.ipv4.tcp_syncookies = 1
# Controls the use of TCP syncookies two is generally a better idea, though you might experiment
#net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
##################################################
#
############## IPv6 Sysctl Settings ################
# Number of Router Solicitations to send until assuming no routers are present.
net.ipv6.conf.default.router_solicitations = 0
# Accept Router Preference in RA? Again not necessery if the server is not a router
net.ipv6.conf.default.accept_ra_rtr_pref = 0
# Learn Prefix Information in Router Advertisement (Unnecessery) for non-routers
net.ipv6.conf.default.accept_ra_pinfo = 0
# disable accept of hop limit settings from other routers (could be used for DoS)
net.ipv6.conf.default.accept_ra_defrtr = 0
# disable ipv6 global unicasts server assignments
net.ipv6.conf.default.autoconf = 0
# neighbor solicitations to send out per address (better if disabled)
net.ipv6.conf.default.dad_transmits = 0
# disable assigning more than 1 address per network interface
net.ipv6.conf.default.max_addresses = 1
#####################################################
To use this settings paste the above sysctl variables in /etc/sysctl.conf and ask sysctl command to read and apply the newly added conf settings:
server:~# sysctl -p
...
Hopefully you should not get errors while applying the sysctl settings, if you get some errors, it’s possible some of the variable is differently named (depending on the Linux kernel version) or the Linux distribution on which sysctl’s are implemented.
For some convenience I’ve created unified sysctl variables /etc/sysct.conf containing the newly variables I started implementing to servers with the ones I already exlpained in my previous post Optimizing Linux TCP/IP Networking
I use this exact sysctl.conf these days on both Linux hosting / VPS / Mail servers etc. as well as on my personal notebook 😉
Here is also the the complete content of above’s sysctl.conf file, just in case if somebody wants to directly copy/paste it in his /etc/sysctl.conf
# Sysctl kernel variables to improve network performance and protect against common Denial of Service attacks
# It's possible that not all of the variables are working on all Linux distributions, test to make sure
# Some of the variables might need a slight modification to match server hardware, however in most cases it should be fine
# variables list compiled by hip0
### https://www.pc-freak.net
#### date 08.07.2011
############ IPv4 Sysctl Kernel Settings ################
net.ipv4.ip_forward = 0
# ( Turn off IP Forwarding )
net.ipv4.conf.default.rp_filter = 1
# ( Control Source route verification )
net.ipv4.conf.default.accept_redirects = 0
# ( Disable ICMP redirects )
net.ipv4.conf.all.accept_redirects = 0
# ( same as above )
net.ipv4.conf.default.accept_source_route = 0
# ( Disable IP source routing )
net.ipv4.conf.all.accept_source_route = 0
# ( - || - )net.ipv4.tcp_fin_timeout = 40
# ( Decrease FIN timeout ) - Useful on busy/high load server
net.ipv4.tcp_keepalive_time = 4000
# ( keepalive tcp timeout )
net.core.rmem_default = 786426
# Receive memory stack size ( a good idea to increase it if your server receives big files )
##net.ipv4.tcp_rmem = "4096 87380 4194304"
net.core.wmem_default = 8388608
#( Reserved Memory per connection )
net.core.wmem_max = 8388608
net.core.optmem_max = 40960
# ( maximum amount of option memory buffers )
# tcp reordering, increase max buckets, increase the amount of backlost
net.ipv4.tcp_max_tw_buckets = 360000
net.ipv4.tcp_reordering = 5
##net.core.hot_list_length = 256
net.core.netdev_max_backlog = 1024
#Enable ExecShield protection (randomize virtual assigned space to protect against many exploits)
kernel.randomize_va_space = 1
#Increase the number of PIDs processes could assign this is very needed especially on more powerful servers
kernel.pid_max = 65536
# Prevent against the common 'syn flood attack'net.ipv4.tcp_syncookies = 1
# Controls the use of TCP syncookies two is generally a better idea, though you might experiment
#net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
###################################################
############## IPv6 Sysctl Settings ################
# Number of Router Solicitations to send until assuming no routers are present.
net.ipv6.conf.default.router_solicitations = 0
# Accept Router Preference in RA? Again not necessery if the server is not a router
net.ipv6.conf.default.accept_ra_rtr_pref = 0
# Learn Prefix Information in Router Advertisement (Unnecessery) for non-routersnet.
ipv6.conf.default.accept_ra_pinfo = 0
# disable accept of hop limit settings from other routers (could be used for DoS)
net.ipv6.conf.default.accept_ra_defrtr = 0
# disable ipv6 global unicasts server assignmentsnet.
ipv6.conf.default.autoconf = 0
# neighbor solicitations to send out per address (better if disabled)
net.ipv6.conf.default.dad_transmits = 0
# disable assigning more than 1 address per network interfacenet.
ipv6.conf.default.max_addresses = 1
#####################################################
# Reboot if kernel panic
kernel.panic = 20
These sysctl settings will tweaken the Linux kernel default network settings performance and you will notice the improvements in website responsiveness immediately in some cases implementing this kernel level goodies will make the server perform better and the system load might decrease even 😉
This optimizations on a kernel level are not only handy for servers, their implementation on Linux Desktop should also have a positive influence on the way the network behaves and could improve significantly the responce times of opening pages in Firefox/Opera/Epiphany Torrent downloads etc.
Hope this kernel tweakenings are helpful to someone. Cheers 😉
One good module that helps in mitigating, very basic Denial of Service attacks against Apache 1.3.x 2.0.x and 2.2.x webserver is mod_evasive
I’ve noticed however many Apache administrators out there does forget to install it on new Apache installations or even some of them haven’t heard about of it. Therefore I wrote this small article to create some more awareness of the existence of the anti DoS module and hopefully thorugh it help some of my readers to strengthen their server security.
Here is a description on what exactly mod-evasive module does:
debian:~# apt-cache show libapache2-mod-evasive | grep -i description -A 7
Description: evasive module to minimize HTTP DoS or brute force attacks mod_evasive is an evasive maneuvers module for Apache to provide some protection in the event of an HTTP DoS or DDoS attack or brute force attack. . It is also designed to be a detection tool, and can be easily configured to talk to ipchains, firewalls, routers, and etcetera. . This module only works on Apache 2.x servers
How does mod-evasive anti DoS module works?
Detection is performed by creating an internal dynamic hash table of IP Addresses and URIs, and denying any single IP address which matches the criterias:
Requesting the same page more than number of times per second
Making more than N (number) of concurrent requests on the same child per second
Making requests to Apache during the IP is temporarily blacklisted (in a blocking list – IP blacklist is removed after a time period))
These anti DDoS and DoS attack protection decreases the possibility that Apache gets DoSed by ana amateur DoS attack, however it still opens doors for attacks who has a large bot-nets of zoombie hosts (let’s say 10000) which will simultaneously request a page from the Apache server. The result in a scenario with a infected botnet running a DoS tool in most of the cases will be a quick exhaustion of system resources available (bandwidth, server memory and processor consumption). Thus mod-evasive just grants a DoS and DDoS security only on a basic, level where someone tries to DoS a webserver with only possessing access to few hosts. mod-evasive however in many cases mesaure to protect against DoS and does a great job if combined with Apache mod-security module discussed in one of my previous blog posts – Tightening PHP Security on Debian with Apache 2.2 with ModSecurity2 1. Install mod-evasive
Installing mod-evasive on Debian Lenny, Squeeze and even Wheezy is done in identical way straight using apt-get:
In case of the above configuration criterias are matched, mod-evasive instructs Apache to return a 403 (Forbidden by default) error page which will conserve bandwidth and system resources in case of DoS attack attempt, especially if the DoS attack targets multiple requests to let’s say a large downloadable file or a PHP,Perl,Python script which does a lot of computation and thus consumes large portion of server CPU time.
The meaning of the above three mod-evasive config vars are as follows:
DOSHashTableSize 3097 – Increasing the DoSHashTableSize will increase performance of mod-evasive but will consume more server memory, on a busy webserver this value however should be increased DOSPageCount 30 – Add IP in evasive temporary blacklist if a request for any IP that hits the same page 30 consequential times. DOSSiteCount 40 – Add IP to be be blacklisted if 40 requests are made to a one and the same URL location in 1 second time DOSBlockingPeriod 120 – Instructs the time in seconds for which an IP will get blacklisted (e.g. will get returned the 403 foribden page), this settings instructs mod-evasive to block every intruder which matches DOSPageCount 30 or DOSSiteCount 40 for 2 minutes time. DOSPageInterval 2 – Interval of 2 seconds for which DOSPageCount can be reached. DOSSiteInterval 1 – Interval of 1 second in which if DOSSiteCount of 40 is matched the matched IP will be blacklisted for configured period of time.
mod-evasive also supports IP whitelisting with its option DOSWhitelist , handy in cases if for example, you should allow access to a single webpage from office env consisting of hundred computers behind a NAT. Another handy configuration option is the module capability to notify, if a DoS is originating from a number of IP addresses using the option DOSEmailNotify Using the DOSSystemCommand in relation with iptables, could be configured to filter out any IP addresses which are found to be matching the configured mod-evasive rules. The module also supports custom logging, if you want to keep track on IPs which are found to be trying a DoS attack against the server place in above shown configuration DOSLogDir “/var/log/apache2/evasive” and create the /var/log/apache2/evasive directory, with: debian:~# mkdir /var/log/apache2/evasive
I decided not to log mod-evasive DoS IP matches as this will just add some extra load on the server, however in debugging some mistakenly blacklisted IPs logging is sure a must.
4. Restart Apache to load up mod-evasivedebian:~# /etc/init.d/apache2 restart
...
Finally a very good reading which sheds more light on how exactly mod-evasive works and some extra module configuration options are located in the documentation bundled with the deb package to read it, issue:
At security critical hosts running Apache + PHP based sites it is recommended functions like:
system();
exec();shell_exec();.....
to be disabled. The reason is to mainly harden against script kiddies who might exploit your site/s and upload some shitty SK tool like PHP WebShell, PHP Shell and the probably thousands of “hacker” variations that exist nowdays.
In latest Debian stable Squeeze, suhosin – advanced protection module for php5 is being installed and enabled in Apache (by default). Simply disabling a number of functions using suhosin, could prevent multiple of future headaches and hours of pondering on who 0wn3d your server ….
Disabling the basic PHP system(); and other similar functions which allows shell spawn is not always possible, since some websites or CMS platforms depends on them for proper runnig, anyways whether it is possible disabling ’em is a must. There are two ways to disable system(); functions; One is through using /etc/php5/apache2/conf.d/suhosin.ini and 2nd by adding a list of functions that has to be disabled directly in Website Virtualhost file or in apache2.conf (/etc/apache2/apache2.conf; For people hosting multiple virtualhost websites on the same server using the custom domain Virtualhost method is probably better, since on a global scale the functions could be enabled if some of the websites hosted on the server requires exec(); to work OK. In any case using /etc/php5/apache2/conf.d/suhosin.ini to disable system(); functions in PHP is less messy …
1. Disabling PHP system(); fuctions through /etc/apache2/apache2.conf and custom site Vhosts
Place somewhere (I prefer near the end of config);;;
Disabling it for custom virtualhost is done by simply adding above Apache directvies (before the closing tag in /etc/apache2/sites-enabled/custom-vhost.com
2. Disabling PHP system();, exec(); shell spawn with suhosin.ini
Substitute the /var/www/yourwebsite with your correct website location in between the opening and closing Directory apache directive place something similar to the following lines:
AllowOverride All AuthName “Add your login message here.” AuthType Basic AuthUserFile /etc/apache2/.htpasswd AuthGroupFile /dev/null require user name-of-user
Eventually your Directory directive in your let’s say /etc/apache2/apache2.conf should look something like the example in below
<Directory /var/www/yourwebsite>
AllowOverride All
AuthName "Add your login message here."
AuthType Basic
AuthUserFile /etc/apache2/.htpasswd
AuthGroupFile /dev/null
require user name-of-user
</Directory>
Of course in this example you need to set the name-of-user to an actual user name let’s say you want your login user to be admin, then substitute the name-of-user with admin
Of course set the desirable location for your .htpasswd in the AuthUserFile. Just in case if you decide to keep the same location as in my example you will further need to create the /etc/apache2/.htpasswd file.
Note here that in the above exapmle the AllowOverride All could also be substituted for AllowOverride AuthConfig , you might need to put this one if you don’t want that all .htaccess directives are recognized by Apache.
To create the .htpasswd issue the command:
debian~:# htpasswd -c /etc/apache2/.htpasswd admin
New password:
Re-type new password:
In the passwords prompts just type in your password of choice. Now we’re almost ready to have the website apache authentication working, only thing left is to reastart Apache. I’m using Debian so restarting my apache is done via:
debian:~# /etc/init.d/apache2 restart
In other Linux distributions exec the respective script for Apache restart.
Now access your website and the password protection dialog asking for your credentials to login should popup.
