How to Configure Apache 2 to Control Browser Caching-Leverage browser caching

Before we get to browser caching, let’s answer the question: What is Caching? Visit our What is Caching? tutorial if you don’t already know what caching is!

Pre-Flight Check

• These instructions are intended specifically for configuring Apache 2 to control browser caching.
• I’ll be working from a Liquid Web Core Managed CentOS 7 server, and I’ll be logged in as root.

Step #1: Verify Modules

Apache must be configured with the appropriate modules to leverage browser caching.

Let’s check for mod_expires (expires_module) first:

apachectl -M | grep expires

… should return:

expires_module (shared)

Then let’s check for mod_headers (headers_module):

apachectl -M | grep headers

… should return:

headers_module (shared)

Step #2: Examples of Directives

This code can be placed in the .htaccess files for specific directories, or in your root web directory, but we suggest placing it in your httpd.conf.

<IfModule mod_expires.c>
# Turn on the module.
ExpiresActive on
# Set the default expiry times.
ExpiresDefault "access plus 2 days"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType text/css "now plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType text/html "access plus 600 seconds"
</IfModule>

• The default expiration (ExpiresDefault) is set to 2 days.
• Images expire after 1 month.
• CSS and JavaScript also expire after 1 month.
• HTML expires after 10 minutes (600 seconds).

Step #3: Implement Directives

The above directives can be implemented easily. If you’re not already, SSH into your server as root. Then we’ll use vim to edit the httpd.conf file. For a refresher on editing files with vim see: New User Tutorial: Overview of the Vim Text Editor. If you’re using Liquid Web’s CentOS 7 Core Managed image then the following command already uses the correct location:

vim /etc/httpd/conf/httpd.conf

Find a section that looks like this:

# Further relax access to the default document root:
<Directory "/var/www/html">

… the section above (in this case) is the default document root. Add the expiration directives between <Directory “/var/www/html”> and </Directory>.

Then restart Apache 2!

systemctl restart httpd

Full details for mod_expires can be found in the

How to change MySql Root Password

mysqladmin Command To Change Root Password

Method 1 - Set up root password for the first time

If you have never set a root password for MySQL, the server does not require a password at all for connecting as root. To set up a root password for the first time, use the mysqladmin command at the shell prompt as follows:

$ mysqladmin -u root password newpass

If you want to change (or update) a root password, then you need to use the following command:

$ mysqladmin -u root -p oldpassword newpass

Enter password:

If you get...

mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: YES)'

then follow the instructions below on how to recover your MySQL password.

Change MySQL password for other users

To change a normal user password you need to type:

$ mysqladmin -u user-name -p oldpassword newpass

Method 2 - Update or change password

MySQL stores usernames and passwords in the user table inside the MySQL database. You can directly update a password using the following method to update or change passwords:

1) Login to the MySQL server, type the following command at the shell prompt:

$ mysql -u root -p

2) Use the mysql database (type commands at the mysql> prompt):

mysql> use mysql;

3) Change password for a user:

mysql> update user set password=PASSWORD("newpass") where User='ENTER-USER-NAME-HERE';

4) Reload privileges:

mysql> flush privileges;
mysql> quit

This method you need to use while using PHP or Perl scripting.

Recover MySQL root password

You can recover a MySQL database server password with the following five easy steps:

Step # 1: Stop the MySQL server process.

Step # 2: Start the MySQL (mysqld) server/daemon process with the --skip-grant-tables option so that it will not prompt for a password.

Step # 3: Connect to the MySQL server as the root user.

Step # 4: Set a new root password.

Step # 5: Exit and restart the MySQL server.

Here are the commands you need to type for each step (log in as the root user):

Step # 1 : Stop the MySQL service:

# /etc/init.d/mysql stop

Output:

Stopping MySQL database server: mysqld.

Step # 2: Start the MySQL server w/o password:

# mysqld_safe --skip-grant-tables &

Output:

[1] 5988
Starting mysqld daemon with databases from /var/lib/mysql
mysqld_safe[6025]: started

Step # 3: Connect to the MySQL server using the MySQL client:

# mysql -u root

Output:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.15-Debian_1-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

Step # 4: Set a new MySQL root user password:

mysql> use mysql;
mysql> update user set password=PASSWORD("NEW-ROOT-PASSWORD") where User='root';
mysql> flush privileges;
mysql> quit

Step # 5: Stop the MySQL server:

# /etc/init.d/mysql stop

Output:

Stopping MySQL database server: mysqld
STOPPING server from pid file /var/run/mysqld/mysqld.pid
mysqld_safe[6186]: ended

[1]+  Done                    mysqld_safe --skip-grant-tables

Start the MySQL server and test it:

# /etc/init.d/mysql start
# mysql -u root -p

SAML2 Pluggins with Moodle Working configuration

Details are below:

Service Provider Metadata URL :

https://moodle29.mentor-global.com/auth/saml2/sp/metadata.php
Claim Values for UST Idp Server:

Edit Claim Rules \ Add UPN Rule
Add Rule --->   Transform and Incoming Claim

Configuration	Description
Claim rule name	Moodle UPN
Incoming claim type	UPN
Outgoing claim type	Name ID
Outgoing name ID format	Transient Identifier
Pass through all claim values	Ensure Enabled

Edit Claim Rules \ Metadata Claims LDAP
Add Rule  ---->  Send LDAP Attributes as Claims

Configuration	Description
Claim rule name	Metadata
Attribute store	Active Directory

Mapping of LDAP attributes to outgoing claim types

LDAP Attribute	Outgoing Claim Type
Given-Name	givenname
SAM-Account-Name	winaccount
Surname	sn
E-Mail-Addresses	mail

Thanks and Regards
Soney C George

Permanently Ban Repeat Offenders With fail2ban

If you’re reading this, you may want to take a look at the “recidive” filter, which watches the fail2ban log itself and adds a more hardcore block on repeat offenders.  It’s not the exact same solution, but may meet your needs much more easily than the setup described here.  There are notes in the comments about this filter.  I’ll leave this post intact anyway, but maybe this will save you some time.  I will not be able to reply to support requests for this functionality, as I no longer use it myself.  Further comments are disabled on this post.

The fail2ban suite is a very useful (if somewhat overcomplicated) tool in the battle against brute force login attempts.  Basically, fail2ban watches your log files, then executes specific commands (such as adding a firewall block for the offender’s IP address) when login failures cross a certain threshold, then reverses that block after a specified back-off period.  One of the servers I administer needs to run SSH on port 22, and fail2ban helped bring brute force attempts from over 70,000 per day (!!!) to around 20-30.  A dramatic decrease of 99.96% – not too shabby.

After this initial success, I expanded the use of fail2ban to other services, including POP3/IMAP, SMTP, WordPress (using a modified version of the “simple-login-log” plugin to log via syslog), and webmail.  Overall, this has been a huge help in minimizing the use of scarce human clock hours to review nuisance log entries.  If you run any authenticated service exposed to the Internet, I highly recommend deploying fail2ban or something similar as a component of your preventive/defensive measures.

Where this process broke down for me, however, was in addressing repeat offenders.  After the firewall block was removed for a given offender’s IP, it was not long before some of the IPs started brute forcing login attempts and were blocked again.  For quite a while, I was content to note the repeat offenders, add them to a permanent firewall block, and press on.  More recently, this chore became frequent enough that it made sense to build that functionality into the fail2ban configuration itself, removing the human (and my clock hours) from the loop.

I quickly found a helpful post from Lukas Camenzind that outlined the basics of what I wanted to accomplish.  His solution, however, implemented a “permanent block first” method, rather than a “repeat offender” one.  After a short bit of testing, I deployed the following solution, which fully addressed my requirements.  Of course, your experience may vary depending on configuration, but this should be enough to get a similar solution deployed in your environment.

First, create the /etc/fail2ban/action.d/iptables-repeater.conf file:

# Fail2ban configuration file
#
# Author: Phil Hagen <phil@identityvector.com>
#

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-REPEAT-<name>
              iptables -A fail2ban-REPEAT-<name> -j RETURN
              iptables -I INPUT -j fail2ban-REPEAT-<name>
              # set up from the static file
              cat /etc/fail2ban/ip.blocklist.<name> |grep -v ^\s*#|awk '{print $1}' | while read IP; do iptables -I fail2ban-REPEAT-<name> 1 -s $IP -j DROP; done

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D INPUT -j fail2ban-REPEAT-<name>
             iptables -F fail2ban-REPEAT-<name>
             iptables -X fail2ban-REPEAT-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = iptables -n -L INPUT | grep -q fail2ban-REPEAT-<name>

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionban = iptables -I fail2ban-REPEAT-<name> 1 -s <ip> -j DROP
            # also put into the static file to re-populate after a restart
            ! grep -Fq <ip> /etc/fail2ban/ip.blocklist.<name> && echo "<ip> # fail2ban/$( date '+%%Y-%%m-%%d %%T' ): auto-add for repeat offender" >> /etc/fail2ban/ip.blocklist.<name>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionunban = /bin/true

[Init]

# Defaut name of the chain
#
name = REPEAT

Note that the configuration above will block ALL traffic from offending IPs.

Next, add the appropriate stanza(s) to the /etc/fail2ban/jail.conf file:

[ssh-repeater]
enabled  = true
filter   = sshd
action   = iptables-repeater[name=ssh]
           sendmail-whois[name=SSH-repeater, dest=root, sender=root]
logpath  = /var/log/secure
maxretry = 21
findtime = 31536000
bantime  = 31536000

[wordpress-auth-repeater]
enabled  = true
port     = http,https
filter   = wordpress-auth
action   = iptables-repeater[name=wordpress]
            sendmail-whois[name=wordpress-repeater, dest=root, sender=root]
logpath  = /var/log/secure
maxretry = 35
findtime = 31536000
bantime  = 31536000

In the first jail, I’m using the existing “sshd” log watch filter, but waiting for 21 failed login attempts within a year. (This is three consecutive “basic” blocks, which trigger after seven failed attempts, per the defaults distributed with fail2ban.)  Of course, update this example to suit your distribution’s log location and your preferred service and other parameters.  The second jail uses a custom “wordpress-auth” filter and is slightly less aggressive – allowing 35 failed logins per year before invoking the ban-hammer. Duplicate the jail stanzas and adjust as needed for your systems.

After editing this file, just restart the fail2ban service and watch the contents of the/etc/fail2ban/ip.blocklist.ssh and /etc/fail2ban/ip.blocklist.wordpress files grow.

One debugging note – I found troubleshooting fail2ban quite difficult.  After a while, I found that stopping the service, then running “fail2ban-client -vvv -x start” would give me the verbosity needed to find syntax errors in the configuration files.

UPDATE (April 26, 2014): Per a great recommendation from Jan (below), added a grep to de-duplicate IPs on reboot/service restart.

UPDATE (April 28, 2013): After some great discussion below, I’ve updated the content and linked files per the following:

1. Reverted to blocking all traffic after a block, rather than just the service the brute forcer attacked.
2. The configuration now uses one ip.blocklist file and one iptables chain per jail, rather than sharing.  This prevents some duplicated rules and provides a cleaner segregation for types of blocks.
3. Renamed jail to iptables-repeater.

How to add your Logo in the Login and App window in Open Source or Network Edition

by Jorge De La Cruz on September 1, 2015 in PowerTips – Admins, Zimbra Server

A frequently asked question in our Forums is if Open Source users can re-brand the Login and App Logo. You can find more information about licensing in the next Official FAQ PDF, question 33 through 37 which contains related questions and answers about re-branding the logo, but here are some basics:

• How can I add my Logo to the Login and App window?
  • This blog entry will show you how, without complex changes in CSS or other Zimbra files.
• It is legal to re-brand the logo if I have Open Source?
  • Yes, the CPAL provides that the attribution should be prominently displayed and the size of the logo should be consistent with the size of other elements of the attribution. Therefore, the size of Zimbra’s logo should be consistent with the size of any other logos displayed in the graphical user interface.
  • If you are using Open Source Edition, per license agreement you must have the Zimbra Logo equal to, or greater, than you own Logo. Failing to have the image or an image smaller than yours will violate the license agreement.
• How many times do I need to change it?
  • Only once, and if you have your logo and the Zimbra logo in one file, and they are the same size, it should take no more than 30 seconds.
• How can I white-label the entire Zimbra Login and App window?
  • You must purchase the Network Edition version if you need to do white-labeling in the Zimbra Product.

How to White-Label Zimbra Collaboration?

Re-branding the Logo and White-labeling in Zimbra Collaboration are different things. Re-branding can be done in the Open Source Edition following the steps and the CPAL instructions described in this Post. This step is important to meet the license agreement.

White-Label is a Network Edition Feature and can be done only for our Customers. Please see the image below to understand each status.

Login Banner and Application Banner Sizing

In Zimbra, you will find two different images to re-brand: one is the image that appears in the Login window and the other is the image in the top-left corner when you are logged in. Each image has a different size, and you should constrain your Logo+Zimbra logo (in FOSS case) according to these max sizes:

Application Banner, 200px X 35px in Zimbra Collaboration 8.x

Application Banner, 170px X 42px in Zimbra Collaboration 8.0.x

Login Banner, 440px X 60px in Zimbra Collaboration 8.x

Login Banner, 450px X 36px in Zimbra Collaboration 8.0.x

How to do White-Label the Web Client using Zimbra Collaboration Network Edition

One of the benefits of using the Network Edition of Zimbra Collaboration is that you can  White Label easily. If you have Network Edition, you can remove the Zimbra Logos, change the colors of the Login and App windows, or even create your own Login page.

If you are using Zimbra Collaboration Network Edition, login in the Admin Console, go to the Domain where you want to White-Label following the next path Home > Configure > Domains, then edit the Domain.

In the Preferences of the Domain, click Themes. You will be able to select the Colors of the Theme, or you can use an HEX code. You will also be able to add your own Logos and the URL where the logos will point.

Remember that these steps, as well as the ability to White-Label your Zimbra Web Client, are available only in Network Edition.

Zimbra Official Logo to use with your own Logo in Open Source Edition

You can find the official Logos to use here:

• Color
• White
• Black

Needed commands to set the Logos in Zimbra

Since Zimbra Collaboration 5.0.7, you can set your logos per domain, and you can set the URL where you want to link the logos. Here are the three simple commands to run per domain. As the zimbra user:

Images hosted in external server (recommended)

The recommended way to present the logos is to host the images in a external server and present this public and valid URL to the Zimbra commands. In this case, even if you upgrade the Zimbra release, the logos will remain in the external server:

zmprov md example.com zimbraSkinLogoURL https://mail.example.com
zmprov md example.com zimbraSkinLogoLoginBanner https://www.example.com/MyLoginBanner.png
zmprov md example.com zimbraSkinLogoAppBanner https://www.example.com/MyAppBanner.png
zmmailboxdctl restart

Images hosted in the same Zimbra server (not recommended)

This is not recommended to host the logo files in this path inside the Zimbra server/opt/zimbra/jetty/webapps/zimbra/logos/. Be sure that you give these files the proper zimbra rights, and run the next commands as zimbra user:

mkdir /opt/zimbra/jetty/webapps/zimbra/logos/

Upload your logos to that new folder

zmprov md example.com zimbraSkinLogoURL https://mail.example.com
zmprov md example.com zimbraSkinLogoLoginBanner /logos/MyLoginBanner.png
zmprov md example.com zimbraSkinLogoAppBanner /logos/MyAppBanner.png
zmmailboxdctl restart

If you add your image as root user, you might be want to change the files privileges to Zimbra:

chown zimbra:zimbra /opt/zimbra/jetty/webapps/zimbra/logos/MyLoginBanner.png 
chown zimbra:zimbra /opt/zimbra/jetty/webapps/zimbra/logos/MyAppBanner.png

This method is easier because you don’t use an external server. However, any Zimbra upgrade will replace your Custom Logos and folders with the default versions.

Final result and examples

The final result will be something like the following. For best results, use .png images. If you are using the default template, we recommend using white logos or white stroke over your logo.

For Open Source Users that comply with the CPAL and follow the License Agreement

Login Banner

Application Banner

Let us know if you have any questions or issues using these steps.

Block WordPress xmlprc.php DDOS attacks using Fail2Ban

Block WordPress xmlprc.php DDOS attacks using Fail2Ban

Few days ago, my friend’s WordPress website went down. After investigation, I have figured out that it was receiving massive amount of posts requests to the xmlrpc.php file, which brings the apache and mysql to eat up all the system resources and the website crashed. Fortunately, I have figured out the way to mitigate this attack using Fail2Ban, which I’ll share in this post.

Install the Fail2Ban package using the following command:

apt-get install fail2ban iptables

Make a local copy of jail.conf file for configuration change:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Open up the jail.local configuration file:

vi /etc/fail2ban/jail.local

Add the following lines at the end (Change the logpath to match with yours):

[xmlrpc]
enabled = true
filter = xmlrpc
action = iptables[name=xmlrpc, port=http, protocol=tcp]
logpath = /var/log/apache2/access.log
bantime = 43600
maxretry = 2

Move to the Fail2Ban’s filter directory:

cd /etc/fail2ban/filter.d/

Here we need to create the filter to trigger an action with iptables:

vi xmlrpc.conf

Add the following lines:

[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.*
ignoreregex =

Restart the Fail2Ban service:

service fail2ban restart

Check the Fail2Ban log and there you will find that it start banning the IP address if everything went well:

tail -f /var/log/fail2ban.log

Hope this will help you!

Block WordPress xmlprc.php DDOS attacks using Fail2Ban

Block WordPress xmlprc.php DDOS attacks using Fail2Ban

Few days ago, my friend’s WordPress website went down. After investigation, I have figured out that it was receiving massive amount of posts requests to the xmlrpc.php file, which brings the apache and mysql to eat up all the system resources and the website crashed. Fortunately, I have figured out the way to mitigate this attack using Fail2Ban, which I’ll share in this post.

Install the Fail2Ban package using the following command:

apt-get install fail2ban iptables

Make a local copy of jail.conf file for configuration change:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Open up the jail.local configuration file:

vi /etc/fail2ban/jail.local

Add the following lines at the end (Change the logpath to match with yours):

[xmlrpc]
enabled = true
filter = xmlrpc
action = iptables[name=xmlrpc, port=http, protocol=tcp]
logpath = /var/log/apache2/access.log
bantime = 43600
maxretry = 2

Move to the Fail2Ban’s filter directory:

cd /etc/fail2ban/filter.d/

Here we need to create the filter to trigger an action with iptables:

vi xmlrpc.conf

Add the following lines:

[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.*
ignoreregex =

Restart the Fail2Ban service:

service fail2ban restart

Check the Fail2Ban log and there you will find that it start banning the IP address if everything went well:

tail -f /var/log/fail2ban.log

Hope this will help you!