Anyone who deals professionally with web hosting knows the threat posed by infected users with malware, web shells etc. In the general case it is used maldet a not bad script. It is distinguished by 3 things

  1. It's terribly slow
  2. It's terribly slow and if you put it in monitoring mode it will mess with your server
  3. Supports own database with md5 / hex definitions for bad code.

It is its last feature that makes it useful, because, among other things, you can submit files that have not been detected so far and will enter the databases at a later stage.. As I shared in point 1 and 2 its speed is shockingly low – at low machine load, 70k files were scanned in about an hour and a half. For this reason, I started helping my good friend ShadowX with Malmo – an alternative to maldet written in python with a little more flexibility. Unfortunately for lack of time (mainly but not only) we have not completed the project, which is not very usable at the moment – there are a lot of bugs that need to be cleared. In the past few days I had problems with clients infected with CryptoPHP who had huge public_html files ~ 60k + user inods. Since a total of over 200k files had to be scanned, which would take roughly 5+ hours I decided to tune the configuration of maldet, to reduce the files that will be scanned to a reasonable number and time. As I picked up the conf, I noticed the following lines

# Attempt to detect the presence of ClamAV clamscan binary
# and use as default scanner engine; up to four times faster
# scan performance and superior hex analysis. This option
# only uses ClamAV as the scanner engine, LMD signatures
# are still the basis for detecting threats.
# [ 0 = disabled, 1 = enabled; enabled by default ]
clamav_scan=1

Interesting… Apparently there is an opportunity to use ClamAV – which also does not differ in its high speed, but why not give it a try. I quickly installed it

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

/scripts/check_cpanel_rpms --fix --targets=clamav

I run the maldet on a small folder – I don't see a difference in speed and behavior – he used his perl scanner instead of the clamav. After a short digging through the source of maldet, I found the following lines

 clamscan=`which clamscan 2> /dev/null`
 if [ -f "$clamscan" ] && [ "$clamav_scan" == "1" ]; then
        eout "{scan} found ClamAV clamscan binary, using as scanner engine..." 1
    for hit in `$clamscan -d $inspath/sigs/rfxn.ndb -d $inspath/sigs/rfxn.hdb $clamav_db -r --infected --no-summary -f $find_results 2> /dev/null | tr -d ':' | sed 's/.UNOFFICIAL//' | awk '{print$2":"$1}'`; do

Hmmm, I made one which clamscan and to my great surprise I found that clamav is not in the PATH at all, but the stupid Cpanel left it only in / usr / local / cpanel / 3rdparty / bin / from where he uses his binaries. A quick ln solved the problem:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

When re-scanning, maldet already reports the above

{scan} found ClamAV clamscan binary, using as scanner engine...

After already using ClamAV maldet, it finishes its scan 3-4-5 times faster than before. The test showed – 70k inod-a rubbed them for about 25 min which is about 3 times and a half faster than before.

Before I start with another random hate to 50 thin OS I mean, that I have to administer it every day and I know it first hand singular quite well. Today I took the time to test the new magical unheard and unseen feature for a destructive upgrade (pseudo) 😀 . The first thing that amazed me was, that RedHat in its infinite wisdom have decided to stop supporting the x86 architecture 🙄 . I am fully aware that we are 2014 and server processors with 32 bits instructions have been missing for a long time. Yep, but what do users of small VPSs do? – x64 paw more frame, as well as look at it, if you have a thin virtual machine with 512MB-1GB RAM, you will fight for every megabyte of it and you will not waste 20-30% from it just to use on the big set of instructions. I messed up because I had x86 CentOS installed and pulled an x64. I immediately saw a difference in the ISOs – ~100MB при minimal 6.5. I cursed once more. I reinstalled the virtual machine and decided to see how well RedHat did their job – I exported / var and / usr to separate LVM partitions 😈 . After the installation, I updated all the packages and installed apache, php, mysql и bind – it was interesting if they would turn on the services. As a good student, I opened the CentOS guide to the update and diligently began to follow it step by step.. When I got to the point where the real upgrade started, this cougar cut me off, that I have a critical problem 🙄 . I'm reviewing the detailed output – mdaaaa / usr can't be on a separate partition 😆 I knew, that I will not be disappointed with Jim Whitehurst and company. Except “the extreme” problem there were a lot of messages about unsigned packages, confiscation files that do not match and so on. WTF I hadn't even used 3rd repositories everything from their mirrors I took down I hadn't made any settings just simple yum install. Everything was already clear, so I unceremoniously forced the upgrade. I restarted diligently again as the script finally prompted me and everything ended because of the / usr partition. I was too lazy, that I'm trying to fix it, anyway, everything was just for scientific purposes, there is no way to upgrade a product server at the moment. I caught reinstalling my virtual machine and this time I pushed everything into it 1 title. I also learned a lesson, no updates no additional services, after installation direct upgrade. In the final step, the annoying dialogue he told me reappeared, that i have quite high problems – invalid packages, confiscations and so on but can continue. I knew in the beginning they didn't do things right. I restarted again and waited – oh what a miracle the upgrade ended successfully. And everything worked or at least the system boot and I never tried to install additional packages, but the halt command hung – huh still had to have a bug 💡 . After all this fuss, I decided to install Centos clean 7 let's see if it will growl for / boot partition in LVM – 6.5 does not allow such audacity. I started my ISO and was shocked by the installer to say the least – everything was extremely inconvenient “tidy”, completely illogical in order to be beautiful. After some struggle I succeeded with the cherished goal and aha to install and explode, that I have to take my / boot out of the LVM 👿 This is extremely not serious and annoying, if for some reason you forget to increase the size of the boot partition from 200MB and accumulate old kernels what happens.

In general, I did not expect anything and I am still disappointed with CentOS.

As much as I curse RHEL and CentOS shit, there are some things that are invented quite competently. For example, adding a large number of additional IPs is quite a pleasant task. In general, if I have to add a large number of addresses, I would write a bash script in which to perform the operation in question in a loop that it does not work by hand. При Centos/RHEL хората са го измислили доста приятно range файл. В общи линии създаваме файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0. Here we replace eth0 with the name network adapter if it is not eth0. Then we add the following content

IPADDR_START=192.168.0.129
IPADDR_END=192.168.0.254
NETMASK=255.255.255.128
CLONENUM_START=0

as the arguments are

  • IPADDR_START – home IP address
  • IPADDR_END – final address
  • NETMASK – net mask
  • CLONENUM_START – numbering from which to start the network adapter eth0:0 in our case

 

The Centos is a bit interesting in the set of bridge adapters. I assume that the bridge-utils package and eth0 are already installed (in this is in my example) is configured, so let's look at the basic steps

  1. Copy the eth0 settings to br0 (here already if you need another naming of your adapters you can correct it)
  2. You record the entries for eth0 in the configuration file of br0
  3. replace the Ethernet adapter type with Bridge
  4. Remove the MAC address from the br0 configuration
  5. You specify in the eth0 configuration that we will have a bridge adapter br0

To save time, I painted it as an elementary bash script

cd /etc/sysconfig/network-scripts/
cp ifcfg-eth0 ifcfg-br0
sed -i 's/eth0/br0/' ifcfg-br0
sed -i 's/Ethernet/Bridge/' ifcfg-br0
sed -i '/HWADDR/d' ifcfg-br0
echo 'BRIDGE="br0"' >> ifcfg-eth0

This morning I started doing the standard dist upgrade on a Debian server and Dovecot died with the following error 🙂

[….] Starting IMAP/POP3 mail server: dovecotError: socket() failed: Address family not supported by protocol
Error: service(pop3-login): listen(::, 110) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(pop3-login): listen(::, 995) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol
Fatal: Failed to start listeners
failed!

 

If you look closely at it, the mistake catches a person's eye listen(::, 993) failed apparently trying to listen to the ipv6 address i have banned 😈 . The solution is as obvious as the mistake itself – we need to make dovecot only work on ipv4, which is achieved with the following order in /etc/dovecot/dovecot.conf
listen=0.0.0.0
Then we hit a quick restart of Dovecot and everything is in order and we can continue with the distribution upgrade