CyanogenMod, the popular open source OS for smartphones and tablet computers, based on the Android mobile platform is out with yet another milestone release. CyanogenMod pushes newer releases on a nightly, milestone, and “stable version” schedule.
CyanogenMod Team has started pushing the latest milestone release CyanogenMod 11.0 M7 to the download servers for the general public. The latest version of the CyanogenMod is based on Android 4.4.2 KitKat and is now available for download for all compatible devices.According to the team, the new release runs on Android 4.4.2 and the 4.4.3 based milestone release M8 will come sometime in July because the android 4.4.3 KitKat source was release only a week back and they didn’t want to rush it in the stable release. But the 4.4.3 source has been merged into CM for nightlies. You can try the CyanogenMod nightly builds if you’re interested in getting your hand on Android 4.4.3 right away.
In terms of the changes, the M7 builds include an overhaul of the theme chooser, revamped calculator app, improved performance on low memory devices, and many more. The team has also revealed the changelog for CyanogenMod 11.0 M7 which includes:
Common: Theme Chooser UI Overhaul
Common: Calculator app redesign
Common: Performance Profiles
Common: Improved theming performance on low memory devices (~512MB RAM or less)
Trebuchet: Move settings to new slide-out panel
Trebuchet: Consolidate settings for home and drawer options
Media: Add FFMPEG support (expanded media format support)
Bluetooth: Improved support for new car audio systems and docks
Various small bugfixes, global and device-specific
With the latest build, Cyanogen has announced support for new devices that include the HTC One M8, Samsung Galaxy Tab Pro 8.4 (mondrianwifi), Galaxy Note 8.0 LTE (n5120) and LG G2 Docomo (l01f).The CM Team also mentioned that the non-device specific code was branched on May 22nd and Device specific code was branched on May 31st. The team has also tipped those who jump between nightlies and M releases to pay attention to the May 22nd branch point.
Updated builds can be grabbed from CM Updater on your CM running device as an over-the-air update or directly from CyanogenMod website for manual flashing. CM 11.0 M7 is available for around 40 devices and is the most stable AOSP (Android Open Source Project) fork available.
Mail servers are exploited a lot these days to flood out spam mails from the ones which have been compromised.
Securing your mail service is very much important. There are some tweaks which can be carried out from WHM panel.
–> In Home >> Server Configuration >> Tweak Settings
* Prevent “nobody” from sending mail – This will ensure that PHP
scripts running under the ownership ‘nobody’ will not be able to send mails. Most of the times, any of the vulnerable PHP script will be the culprit for sending out spams from your account.
* Restrict outgoing SMTP to root, exim, and mailman – This prevents users from bypassing your mail server to send mail. Only the ones mentioned here are authorized to connect to remote SMTP servers.
// If you get an error while trying to enable SMTP restrictions, then you probably are missing an iptables module required for the proper functioning. Ask your provider to enable it for you, or if you have the ways to do it, give-in the following :
# modprobe ipt_owner
–> In Home >> Service Configuration >> Service Manager, you can find the option Antirelayd. Keep this disabled, so that each time POP3 connects authentication would be required.
–> If you are facing any issues related to IMAP getting restarted numerous times, check
to see if you have many authentication failures from any IPs. If so, your account is being brute-force attacked. Block the offending IPs in your server firewall.
–> Use secure passwords for your email accounts. Check out the various domains and make sure there are no test accounts created. Under normal cases, test email accounts are created with insecure passwords, which can easily be guessed by the attacker.
Sometimes the biggest problems, have the easiest fixes. If you are getting a warning message like the one shown below, then the reason behind this will be nothing other than an error in system date & time.
Whenever you get a warning message like this, make a look at the right bottom corner of your system and check whether the system date and time is correct. If it is not correct, then correct the date and time and try reloading the page.
If you are getting the same message after the next restart then it’s time to change your CMOS battery inside the CPU.
You don’t have to call a technician to rectify this issue. It is as easy as changing the battery of a clock. Get one new CMOS battery and replace it with the old one. Open the CPU box and find a circular shaped battery fixed towards the rear end and dislodge it from its current holding and place the newly bought one.
SSH is the most powerful tool with which you can access your server. As Uncle Ben says in Spiderman —
Remember, with great power, comes great responsibility.
If your service is not hardened, it can be exploited to a level directly proportional to the power of SSH. Let us now consider some of the ways in which you can secure/harden your SSH server.
–> Use key based authentication instead of passwords. There are a lot of botnets trying brute force attacks against your SSH server. Using a password authentication system at the first place, gives them more opportunities. If you use password authentication system, it would mean any machine can connect to your server, if they are aware/have successfully brute forced the password. On the other hand, if you use public/private key based authentication system, not every machine around the world can get in access. Only the ones for which the private/public key pairs match can get-in. And brute-forcing such a system is currently impossible.
To set up key-based authentication, follow the steps given below :
ClientMachine # ssh-keygen
^ Generate a passphrase-protected SSH key
Once this is complete, the private key gets stored to /root/.ssh/id_rsa and public key to /root/.ssh/id_rsa.pub.
Now you need to copy paste the contents of /root/.ssh/id_rsa.pub to your server or transfer this to your server. You can transfer this using :
# ssh-copy-id SERVERIP ( will prompt for root password as well )
or copy paste the contents of /root/.ssh/id_rsa.pub ( from ClientMachine) to the file /root/.ssh/authorized_keys found in the server.
Once this is complete, open your SSH configuration file ( /etc/ssh/sshd_config ) and give-in the below line and restart the service :
PasswordAuthentication no ( If its already commented, uncomment and make sure the argument passed is ‘no’
Now you can SSH from your ClientMachine without passing any passwords ( you might have to type your passphrase if it was given )
–> For a server with user’s around the world having to SSH in and the machines which they use are subject to changes, key based authentication can become a real headache.
Even when we are using Password based authentication, we can make it more secure. Disabling root login can be a big plus-point. Most of the brute force attacks are carried out with the username as ‘root’ in perpective. We can change that root user to be able to login, allow a system user and then sudo in to get the root privilages.
$ First create a system user for this purpose ( Ingnore this step if you already have one user in mind )
# adduser newusername
# passwd newusername
$ Now, we want to edit the sudo rights and grant administrative privilages to this user.
# visudo or # vi /etc/sudoers
Add the username which we just created, below the space
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
After adding, it would look like :
Now save and close this file. Go to your ssh configuration file and give the setting :
This will make sure, root login is disabled and you can SSH as the newusercreated, then sudo in to get as root
–> You can also consider about changing the custom SSH port from 22 to any other.
–> If you have multiple IP’s, you can think about binding SSH server to just one IP.
^ These 2 options can be found from /etc/ssh/sshd_config file
–> If you have a defined networking environment, you can provide the range of IPs which can access the SSH service and deny all others. This can be done using TCP_Wrapper. Using the files /etc/hosts.deny and /etc/hosts.allow
sshd: Trusted IPs/subnet
A recent & common issue faced with dovecot service in cPanel based server’s is the corruption of dovecot.index files for the email accounts. When the index file is broken, the respective user facing this issue will not be able to login to his webmail and will throw up a ‘server error’. The basic idea behind Dovecot’s index files is that it makes reading the mailboxes a lot faster.
Checking the logs to confirm its the issue with dovecot.index file :
# tailf /var/log/maillog
host dovecot: imap(email@example.com): Error: Transaction log file /pathto/dovecot.index.log seq 302: log_file_tail_offset update shrank it (988 vs 1184 sync_offset=972)
host dovecot: imap(firstname.lastname@example.org): Error: broken sync positions in index file /pathto/dovecot.index
The solution to fix this issue is to delete the dovecot.index file for the respective user and for the respective folder.
# rm -rf /path-to-the-/dovecot.index
If you find that this file is broken for the folder ‘Trash’, then do delete the index file which is found in Trash. This happens to be a long term bug with dovecot and deleting the index file and recreating ( automatically done by dovecot) is the only solution at this juncture.