HP Server

Linux Malware Detect (LMD), also known as Maldet, is a malware scanner for Linux released under the GNU GPLv2 license. It is particularly effective for the detection of php backdoors, darkmailers and many other malicious files that can be uploaded on a compromised website. It will help you do detect infected websites and clean the infection, however securing the compromised user or website is still necessary to avoid re-infection.

If the server has cPanel , we recommend you install ClamAV first, as maldet will use the ClamAV scan engine.

You will need to be logged in as root to the server over SSH.

1 – Install maldet

cd /usr/local/src/ && wget http://www.rfxn.com/downloads/maldetect-current.tar.gz && tar -xzvf maldetect-current.tar.gz && cd maldetect-* && sh install.sh

This will automatically install a cronjob inside /etc/cron.daily/maldet so a daily scan will be run for local cPanel or Plesk accounts.
2 – Make sure to update to the latest version and virus signatures:

maldet -d && maldet -u

3 – Run the first scan manually

To scan a specific user’s home directory, run the following command:

maldet -a /home/user

To launch a background scan for all user’s public_html and public_ftp in all home directories, run the following command:

maldet -b –scan-all /home?/?/public_?

(We also recommend you to scan /tmp and /dev/shm/)

4 – Verify the scan report

We recommend you to always read the scan reports before doing a quarantine. You will also be able to identify infected websites for further actions.

List all scan reports time and SCANID:

maldet –report list

Show a specific report details :

maldet –report SCANID

Show all scan details from log file:

grep “{scan}” /usr/local/maldetect/event_log

5 – Clean the malicious files

By default the quarantine is disabled. You will have to launch it manually.

maldet -q SCANID

6 – (optional) Automatically quarantine detected malware

Please review these configuration variables in /usr/local/maldetect/conf.maldet
variable     value     description
quar_hits     number     if the number is different than 0, enables automatic quarantine

7- (optional) Configure scan reports e-mail alerts

Maldet can send you and email alert each time it detects malware. Please review these configuration variables in /usr/local/maldetect/conf.maldet
variable     value     description
email_alert     1 or 0     enable or disable e-mail alerts
email_addr      e-mail address      target e-mail for notifications, should be put in quotes like: “myuser@mydomain.com”

http://tools.kali.org/tools-listing

Enjoy!

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the
Internet Security Research Group (ISRG)

We give people the digital certificates they need in order to enable HTTPS (SSL/TLS) for websites, for free, in the most user-friendly way we can. We do this because we want to create a more secure and privacy-respecting Web.

The key principles behind Let’s Encrypt are:

• Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
• Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
• Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
• Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
• Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
• Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.

We have a page with more detailed information about
how the Let’s Encrypt CA works

Had a good external help from Eugene, I thank you for your great help!

Works with Webmin, Virtualmin,,, checking postfix!

have phun!

Install Let’s Encrypt

Run an ssh shell to your server.
Run the following command:

Now login to your webmin admin panel at:
https://siteaddress:10000/ using root username.

Webmin configuration>SSL Encryption>Let’s Encrypt

It will show you:

Click on “module configuration”
and type in the path and click Save:

To enable SSL certificate for a site, Go to:
Virtualmin>Edit Virtual Server>Enabled features

Enable “SSL website enabled”

To Manage the certificate:
Virtualmin>Server configuration>Manage SSL certificates

Click on Let’s Encrypt and generate a new certificate

NOTES:

To force http:// to https:// include a .htaccess with the following code

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Edit the following /usr/libexec/webmin/virtual-server/feature-ssl.pl lines 2148 and 2152

Save the file and then restart Webmin. I did so from the terminal with the command:

sudo service webmin restart

Source : https://www.virtualmin.com/node/48121

StarWind Virtual SAN Free targets those who need a SAN or NAS for their home lab, educational or research purposes. It is free for production use, but comes with a basic restricted set of features, compared to the full VSAN. In case a serious project is starting, StarWind Virtual SAN will come in handy. It offers a wider set of features unlocked and more usage scenarios, also being backed by StarWind support. Getting qualified assistance from expert engineers simplifies the building and maintenance of virtualization infrastructure. The complete list of differences between free and paid versions can be found here. In case there is no time for “Do-It-Yourself” tinkering, StarWind offers a turnkey solution – StarWind HyperConverged Appliance. It unifies best-of-breed software and hardware from multiple vendors and covers it with one “support umbrella”.

This only apply after you have installed : TLS/SASL/SSL !

I am using “Virtualmin” so locate your roundcube in here:

/home/[username]/public_html/webmail/config/config.inc.php

Locate this configuration: $config[‘smtp_server’] = ‘localhost’;

Easy fix here!

Remove ‘localhost‘: $config[‘smtp_server’] = ‘ ‘;

Now roundcube will use PHP instead of SMTP

Enjoy!

This entry documents the basic process for setting up CRAM-MD5 authentication for Dovecot.

Firstly, you need to enable the mechanism and specify a passwd database file in Dovecot. The mechanism and passdb file are specified in the dovecot.conf configuration file, on a Red Hat or similar system this is located in the /usr/local/etc/ directory.

# Space separated list of wanted authentication mechanisms:
# plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi
auth_mechanisms = plain login cram-md5

# passwd-like file with specified location 
passdb { 
  driver = passwd-file
  # Path for passwd-file. Also set the default password scheme.
  args = scheme=cram-md5 /etc/cram-md5.pwd 
}

You see that I’ve added the cram-md5 mechanism to the mechanisms statement and then added a passdb file, /etc/cram-md5.pwd.

Next, you need to create this passdb file and set appropriate permissions.

# touch /etc/cram-md5.pwd 
# chmod 0600 /etc/cram-md5.pwd

After creating the file you need to add your users and hashed passwords to the passdb file. The users and passwords are added in the format:

username:passwordhash

You can generate password hashes using “doveadm pw”:

# doveadm pw
Enter new password: password
Retype new password: password
{CRAM-MD5}26b633ec8bf9dd526293c5897400bddeef9299fad

Enter the user’s password when prompted and it will be converted and outputted as a hash. The default hashed output is in the CRAM-MD5 scheme. You can change the scheme of the outputted hashes using the -s command line switch.

Now add the generated password to the passdb file, /etc/cram-md5.pwd.

username:26b633ec8bf9dd526293c5897400bddeef9299fad

Finally, restart Dovecot and test authentication by enabling the appropriate mechanism in your email client. For example, to enable CRAM-MD5 authentication in Thunderbird you need to check the “Use secure authentication” checkbox in the Account Settings page.

I recommend that you also use TLS/SSL to encrypt the authentication process as well.

I have been setting up a new mail server recently with Postfix and SMTP Auth, and got the error message “no SASL authentication mechanisms”.

If you have enabled SMTP Auth with Postfix like this:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination

and are getting messages like this (the extract below is from the mail log file):

Nov  2 15:31:09 vps131 postfix/smtpd[14007]: warning: dict_nis_init: NIS domain name not set - NIS lookups disabled
Nov  2 15:31:09 vps131 postfix/smtpd[14007]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Nov  2 15:31:09 vps131 postfix/smtpd[14007]: fatal: no SASL authentication mechanisms
Nov  2 15:31:10 vps131 postfix/master[12004]: warning: process /usr/libexec/postfix/smtpd pid 14007 exit status 1
Nov  2 15:31:10 vps131 postfix/master[12004]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling

then you need to install the cyrus-sasl-plain package like so:

yum install cyrus-sasl-plain

The above method will install the cyrus-sasl-plain packages on CentOS and other RPM/Yum based Linux distributions, so you would need to use the appropriate package manager (and software package) for other Linux distros.

• Also make sure the SASAUTHD is running on your system

# systemctl status saslauthd

# systemctl start saslauthd

# systemctl enable saslauthd

NOTES :

# SASL CONFIGURATION
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_inet_interfaces permit_sasl_authenticated
#

You may verified your email server security score here:

http://www.emailsecuritygrader.com

Here is a part of my /etc/postfix/main.cf

# Sender restrictions
smtpd_sender_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
#
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
check_policy_service unix:postgrey/socket,
permit
# Postfix AntiSpam Configuration
disable_vrfy_command = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
reject_non_fqdn_hostname,
reject_invalid_hostname,
permit
#
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
#
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_inet_interfaces permit_sasl_authenticated
#
smtpd_error_sleep_time = 1s
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20
smtpd_client_restrictions = permit_mynetworks permit_inet_interfaces
#
smtpd_enforce_tls = yes
smtpd_tls_loglevel = 1
smtpd_use_tls = yes
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
# Experimental
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtpd_sasl_security_options = noanonymous
smtpd_sasl_application_name = smtpd

🙂

This is an optional feature you don’t need to do to get everything working but if you want a secure setup you should do this. TLS will allow you to setup an SSL encrypted connection between the server and the mail client. This means that the authentication that is used will be send encrypted over the internet while the normal authentication will be send in clear text over the internet making it possible for others to read.

First you need to buy yourself a certificate at Thawte or Verisign, but as we are building a server on the cheap we are going to create our own certificate. The only problem you will encounter when using your own certificates is that users explicitly have to accept and verify your root certificate in contrast with certificates you buy which are already accepted in most email clients by default. If they for instance try to send their email for the first time via your secure server they need to accept your certificate. When using Mail.app in OS X they will get the following warning:

They need to press continue and from then on your certificate will be accepted and they won’t be asked again.

Just open a Terminal and execute the following command in the directory /etc/postfix:

sudo openssl req -new -outform PEM -out smtpd.cert \
   -newkey rsa:2048 -nodes -keyout smtpd.key -keyform PEM \
   -days 365 -x509

This will create a 2048 bit encryption key that, for now, is secure enough for you mailserver to use. If you are paranoid and want a bigger key just increase the number after rsa:. The key will be valid for a year, if you want a longer period just increase the number after the -days option. When the key is finished you will be asked a couple of questions you need to answer. The information will be shown to people who want to see your certificate when their mail client complains. The most important one is the ‘Common Name’, make sure that that one is the same as the mail server name.

Country Name (2 letter code) [CA]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:your.mailserver.tld
Email Address []:you@yourdomain.tld

Now you have created the certificate you will have to configure Postfix to make use of it and to enforce the usage of TLS to securely communicate with the email client. You’ll have to add the following lines to the configuration file main.cf in /etc/postfix :

smtpd_enforce_tls                = no
smtpd_tls_loglevel               = 1
smtpd_use_tls                    = yes
smtpd_tls_key_file               = /etc/postfix/smtpd.key
smtpd_tls_cert_file              = /etc/postfix/smtpd.cert

Issue the command sudo postfix reload to refresh the configuration of your mail server and your ready to test it out. Start a terminal session and issue the following commands:

telnet your.mailserver.tld 25

The server will answer with:

Trying your.mailserver.tld...
Connected to your.mailserver.tld.
Escape character is ^]
220 your.mailserver.tld ESMTP Postfix

Then type in:

EHLO your.mailserver.tld

And again your server will answer it’s capabilities:

250-your.mailserver.tld
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250 8BITMIME

Now it’s time to test TLS and enter in capitals:

STARTTLS

and the server should respond with:

220 Ready to start TLS

Then you know it will work, you could give your favorite email client a try.

Restart postfix : systemctl restart postfix

NOTES:

After this fix, roundcube cannot send email anymore, investigating this!

To verify ClamAV is working properly, let’s download a test virus (which we can get from http://www.eicar.org/download/eicar.com) to the Maildir

# cd /home/[username]/Maildir
# wget http://www.eicar.org/download/eicar.com

And then scan the /home/[username]/Maildir directory recursively:

# clamscan --infected --remove --recursive /home/[username]/Maildir

Now, feel free to set up this scan to run through a cronjob. Create a file named /etc/cron.daily/dailyclamscan, insert the following lines:

#!/bin/bash
SCAN_DIR="/home/[username]/Maildir"
LOG_FILE="/var/log/clamav/dailyclamscan.log"
touch $LOG_FILE
/usr/bin/clamscan --infected --remove --recursive $SCAN_DIR >> $LOG_FILE

and grant execute permissions:

# chmod +x /etc/cron.daily/dailyclamscan

The above cronjob will scan the mail server directory recursively and leave a log of its operation in /var/log/clamav/dailyclamscan.log (make sure the /var/log/clamav directory exists).

NOTES:
# man clamscan
# clamscan -r -i /home

In the process of receiving email, spamassassin will stand between the outside world and the email services running on your server itself. If it finds, according to its definition rules and configuration, that an incoming message is spam, it will rewrite the subject line to clearly identify it as such. Let’s see how.

The main configuration file is /etc/mail/spamassassin/local.cf, and we should make sure the following options are available (add them if they are not present or uncomment if necessary):

report_safe 0
required_score 8.0
rewrite_header Subject [SPAM]

1. When report_safe is set to 0 (recommended value), incoming spam is only modified by modifying the email headers as per rewrite_header. If it is set to 1, the message will be deleted.
2. To set the aggressivity of the spam filter, required_score must be followed by an integer or decimal number. The lesser the number, the more sensitive the filter becomes. Setting required_score to a value somewhere between 8.0 and 10.0 is recommended for a large system serving many (~100s) email accounts.

Once you’ve saved those changes, enable and start the spam filter service, and then update the spam rules:

# systemctl enable spamassassin
# systemctl start spamassassin
# sa-update

Integrating Postfix and SpamAssassin

In order to efficiently integrate Postfix and spamassassin, we will need to create a dedicated user and group to run the spam filter daemon:

# useradd spamd -s /bin/false -d /var/log/spamassassin

Next, add the following line at the bottom of /etc/postfix/master.cf:

spamassassin unix - n n - - pipe flags=R user=spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

And indicate (at the top) that spamassassin will serve as content_filter:

Finally, restart Postfix to apply changes:

# systemctl restart postfix

To verify that SpamAssassin is working properly and detecting incoming spam, a test known as GTUBE (Generic Test for Unsolicited Bulk Email) is provided.

To perform this test, send an email from a domain outside your network (such as Yahoo!, Hotmail, or Gmail) to an account residing in your email server. Set the Subject line to whatever you want and include the following text in the message body:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

And shows the corresponding notice in the logs:

Additionally, you can test spamassassin right from the command line:

# spamassassin -D < /usr/share/doc/spamassassin-3.4.0/sample-spam.txt

What is chkrootkit and the steps to Install chkrootkit

The chkrootkit is a security scanner to check if the system is infected with the ‘rootkit’. A rootkit is a malicious software which is capable of having administrator-level access to a computer or network. The rootkit allows the hackers to take the control of a system without the user knowing it. This means that the rootkit is capable of executing files and changing system configurations on the target machine and many more which can be done only as the super user of the Linux machine.

Please note that scanning for rootkits will not stop all attacks, it is not an active defense. If your server has been compromised then a scan will not stop the rootkit.

Install chkrootkit

The following steps will help you to install chkrootkit on CentOS.

 
cd /usr/local/src
wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz
tar xvf chkrootkit.tar.gz
cd chkrootkit-*
make sense

Now, you can run the chkrootkit to scan the server. Please note that the present working directory should be “/usr/local/src/chkrootkit-0.50”.

 
./chkrootkit

Daily scan report script

Create a file named scan.sh

 
vim /etc/cron.daily/chkrootkit.sh

 
#!/bin/bash
cd /usr/local/src/chkrootkit-*/ ; ./chkrootkit |grep -v not| /bin/mail -s 'CHROOTKIT Scan Result' your@email.com

Make it executable

 
chmod +x /etc/cron.daily/chkrootkit.sh

The script will email your daily scan report. Also the above steps can also be used to install chkrootkit on cPanel server. Also, please keep this in mind that, using chkrootkit, you can’t remove and found 100% rootkits. You can secure your server from rootkits by ensuring that all applications and softwares are up-to-date and the system kept patched against all known vulnerabilities.

ISPProtect is a Malware and Antivirus scanner for web servers. It contains a signature based scan engine and a heuristic scan engine to detect Malware in websites, CMS- and shop systems like WordPress, Joomla, Drupal, Magentocommerce etc. A third scan level in ISPProtect detects outdated installations of e. g. WordPress, Joomla, Drupal, … and shows their location on the web server. ISPProtect is developed by the ISPConfig developer team. ISPConfig is a widely used OpenSource Webhosting Control Panel.

ISPProtect use cases

Do I need ISPProtect on my server? Yes, when you run your own web server, are a hosting company or provide support for web servers.

• Your web server started to send out spam emails? ISPProtect can help you to find the malicious software.
• You recognize a high load on your web server that does not correlate with the website access statistics? Use ISPProtect to find malware that uses your server to attack other systems and IRC bots.
• You are a hosting company and like to keep your server safe and warn your customers when a site got infected? Use ISPProtect to get a detailed Malware report by email daily, weekly, monthly or in the interval you want.
• Do your clients miss to install Updates of their WordPress, Joomla and Mediawiki sites or store copies of their old and vulnerable sites in folders like „old_site“ on the server that get never removed and are a target for hackers? Use ISPProtect to get a report on outdated CMS versions that are installed on your server.
• You are a Linux support company and get contacted by clients with their web server issues? Add ISPProtect to your tool set and use it to scan the systems of your clients and detect malware easily.

Try ISPProtect for free
https://ispprotect.com

Try ISPProtect for free on your server now, no registration required. Just download it and start the scan, enter the word „trial“ when the scanner asks for the license key.

cd /tmp
wget http://www.ispprotect.com/download/ispp_scan.tar.gz
tar xzf ispp_scan.tar.gz
./ispp_scan

systemd: Cannot add dependency job for unit microcode.service, ignoring: Unit is not loaded properly: Invalid argument.

# systemctl is-enabled microcode.service
enabled
# systemctl disable microcode.service
Removed symlink /etc/systemd/system/basic.target.wants/microcode.service.
# reboot

Check this out ~

http://www.linuxquestions.org/questions/centos-111/centos-yum-update-depency-problem-4175541770/

https://www.centos.org/forums/viewtopic.php?f=19&t=14128&sid=f0771137550b57aab58066711d223c78&start=10

Yum commands :

# yum repolist all         [verifie the installed repos]
# rm -rf /var/cache/yum/*  [clear yum cache]
# rpm -Va                  [check all packages]
# yum clean all            [clean yum]
# rpm --rebuilddb          [rebuild database]
# yum update -d6           [yum update]
# yum check-update -d6 --noplugins
# rpm -qa yum \*           [output yum infos]


,,,…maybe,,, the Time Protocol? 😉 and more to this…,,,,,

have a FUN_YUM!

FIXED on a live server, Thanks to a wizard of OZ!!! Don’t ask me how!

Cheers!

P.S Do not do complex commands on a live server ,,, or just have fun, in the learning 😉

# rm -rf /var/cache/yum/*

Guide to install FREE SSL certificate from Letsencrypt on Virtualmin & Webmin. 100% working.

The issue isn’t with postgrey or postfix, but with milter-greylist.

What you may want to do is edit /etc/postfix/main.cf, and comment out the lines beginning with “smtpd_milters” and “non_smtpd_milters”. After that, restart Postfix.

not working,,,, hummm 😉

NOTE: http://unix.stackexchange.com/questions/74477/postfix-smtpd-warning-connect-to-milter-service-unix-var-run-opendkim-opendki

warning: connect to Milter service local:/run/milter-greylist/milter-greylist.sock: Connection refused

http://unix.stackexchange.com/questions/74477/postfix-smtpd-warning-connect-to-milter-service-unix-var-run-opendkim-opendki

To enable DKIM signing of outgoing email messages, follow these steps :

1. Login to Virutalmin as root and go to Email Messages -> DomainKeys Identified Mail
2. Change Signing of outgoing mail enabled? to Yes.
3. In the Selector for DKIM record name field enter a short name that you will use to identify the signing key. This is typically just the current year, like 2010. Do NOT enter default, as this can trigger a bug in the current Virtualmin release which deletes the /etc/default directory!
4. Click the Save button.

Assuming all goes well, Virtualmin will report the steps taken to configure and enable DKIM.

Only virtual servers that have both the DNS and email features enabled will have DKIM activated, as the mail server needs to be setup to use a private signing key whose corresponding public key is added to DNS.

By default, Virtualmin will also configure the DKIM milter to verify incoming email that has the proper signatures. DKIM-signed messages where the signature is incorrect or cannot be checked with a DNS lookup will be bounced or delayed. If you want to disable verification, set the Verify DKIM signatures on incoming email? option to No.

To turn off DKIM signing completely, just do the following :

1. Login to Virutalmin as root and go to Email Messages -> DomainKeys Identified Mail
2. Change Signing of outgoing mail enabled? to No.
3. Click Save.

This will remove the public key from all domains, and stop your mail server from signing messages with the DKIM milter.

NOTES:
Common problems:

1. Check if you have SPF, DKIM and DMARC records and if they are properly set
2. Check if you have rDNS
   
3. Check if your domain or IP is blacklisted
4. From 1 to 3 plus several other settings can be checked with:
   http://mxtoolbox.com/SuperTool.aspx
5. Check what services are active and their ports especially dovecot: http://www.cyberciti.biz/faq/how-do-i-find-out-what-ports-are-listeningo…

NOTES:
For rDNS should be easy to sort. Best and easiest solution would be to use the hostname (either way it should be FQDN), so if your hostname is “myserver.domain.tld” then check if you have in your DNS records “myserver.domain.tld. IN A your.server.IP.address”. If you are missing this record be sure to add it before you proceed to set rDNS. Once done go to your host control panel and set rDNS to “myserver.domain.tld”.

ANVIL(8)                                                              ANVIL(8)

NAME
       anvil - Postfix session count and request rate control

SYNOPSIS
       anvil [generic Postfix daemon options]

DESCRIPTION
       The  Postfix  anvil(8) server maintains statistics about client connec-
       tion counts or client request rates. This information can  be  used  to
       defend against clients that hammer a server with either too many simul-
       taneous sessions, or with too many successive requests within a config-
       urable  time interval.  This server is designed to run under control by
       the Postfix master(8) server.

       In the following text, ident specifies a (service, client) combination.
       The  exact  syntax  of  that  information is application-dependent; the
       anvil(8) server does not care.

CONNECTION COUNT/RATE CONTROL
       To register a new connection send the following request to the anvil(8)
       server:

           request=connect
           ident=string

       The anvil(8) server answers with the number of simultaneous connections
       and the number of connections per unit time for the  (service,  client)
       combination specified with ident:

           status=0
           count=number
           rate=number

       To  register  a  disconnect  event  send  the  following request to the
       anvil(8) server:

           request=disconnect
           ident=string

       The anvil(8) server replies with:

           status=0

MESSAGE RATE CONTROL
       To register a message delivery request send the  following  request  to
       the anvil(8) server:

           request=message
           ident=string

       The  anvil(8)  server  answers  with  the  number  of  message delivery
       requests per unit time for the (service, client) combination  specified
       with ident:

           status=0
           rate=number

RECIPIENT RATE CONTROL
       To  register  a  recipient  request  send  the following request to the
       anvil(8) server:

           request=recipient
           ident=string

       The anvil(8) server answers with the number of recipient addresses  per
       unit time for the (service, client) combination specified with ident:

           status=0
           rate=number

TLS SESSION NEGOTIATION RATE CONTROL
       The  features  described in this section are available with Postfix 2.3
       and later.

       To register a request for a new (i.e. not cached) TLS session send  the
       following request to the anvil(8) server:

           request=newtls
           ident=string

       The anvil(8) server answers with the number of new TLS session requests
       per unit time for the  (service,  client)  combination  specified  with
       ident:

           status=0
           rate=number

       To  retrieve  new TLS session request rate information without updating
       the counter information, send:

           request=newtls_report
           ident=string

       The anvil(8) server answers with the number of new TLS session requests
       per  unit  time  for  the  (service, client) combination specified with
       ident:

           status=0
           rate=number

AUTH RATE CONTROL
       To register an AUTH request send the following request to the  anvil(8)
       server:

           request=auth
           ident=string

       The  anvil(8)  server answers with the number of auth requests per unit
       time for the (service, client) combination specified with ident:

           status=0
           rate=number

SECURITY
       The anvil(8) server does not talk to the network or to local users, and
       can run chrooted at fixed low privilege.

       The anvil(8) server maintains an in-memory table with information about
       recent clients requests.  No persistent state is kept because  standard
       system  library  routines are not sufficiently robust for update-inten-
       sive applications.

       Although the in-memory state is kept only temporarily, this may require
       a  lot  of  memory  on systems that handle connections from many remote
       clients.  To reduce memory usage, reduce the time unit over which state
       is kept.

DIAGNOSTICS
       Problems and transactions are logged to syslogd(8).

       Upon  exit, and every anvil_status_update_time seconds, the server logs
       the maximal count and rate values  measured,  together  with  (service,
       client)  information  and the time of day associated with those events.
       In order to avoid unnecessary overhead, no measurements  are  done  for
       activity that isn't concurrency limited or rate limited.

BUGS
       Systems behind network address translating routers or proxies appear to
       have the same client address and can run into connection  count  and/or
       rate limits falsely.

       In  this  preliminary  implementation, a count (or rate) limited server
       process can have only one remote client at a time. If a server  process
       reports  multiple simultaneous clients, state is kept only for the last
       reported client.

       The anvil(8) server automatically discards client  request  information
       after  it  expires.   To  prevent  the  anvil(8) server from discarding
       client request rate information too early or too late, a  rate  limited
       service  should  always register connect/disconnect events even when it
       does not explicitly limit them.

CONFIGURATION PARAMETERS
       On low-traffic mail systems, changes to main.cf are picked up automati-
       cally  as  anvil(8) processes run for only a limited amount of time. On
       other mail systems, use the command "postfix  reload"  to  speed  up  a
       change.

       The  text  below provides only a parameter summary. See postconf(5) for
       more details including examples.

       anvil_rate_time_unit (60s)
              The time unit over which client connection rates and other rates
              are calculated.

       anvil_status_update_time (600s)
              How  frequently the anvil(8) connection and rate limiting server
              logs peak usage information.

       config_directory (see 'postconf -d' output)
              The default location of the Postfix main.cf and  master.cf  con-
              figuration files.

       daemon_timeout (18000s)
              How  much  time  a  Postfix  daemon process may take to handle a
              request before it is terminated by a built-in watchdog timer.

       ipc_timeout (3600s)
              The time limit for sending  or  receiving  information  over  an
              internal communication channel.

       max_idle (100s)
              The  maximum  amount of time that an idle Postfix daemon process
              waits for an incoming connection before terminating voluntarily.

       max_use (100)
              The maximal number of incoming connections that a Postfix daemon
              process will service before terminating voluntarily.

       process_id (read-only)
              The process ID of a Postfix command or daemon process.

       process_name (read-only)
              The process name of a Postfix command or daemon process.

       syslog_facility (mail)
              The syslog facility of Postfix logging.

       syslog_name (see 'postconf -d' output)
              A prefix that  is  prepended  to  the  process  name  in  syslog
              records, so that, for example, "smtpd" becomes "prefix/smtpd".

SEE ALSO
       smtpd(8), Postfix SMTP server
       postconf(5), configuration parameters
       master(5), generic daemon options

README FILES
       TUNING_README, performance tuning

LICENSE
       The Secure Mailer license must be distributed with this software.

HISTORY
       The anvil service is available in Postfix 2.2 and later.

AUTHOR(S)
       Wietse Venema
       IBM T.J. Watson Research
       P.O. Box 704
       Yorktown Heights, NY 10598, USA

       Wietse Venema
       Google, Inc.
       111 8th Avenue
       New York, NY 10011, USA

The icons – including submenu indicator arrows – for example in UberMenu are font icons. Some browsers – most commonly Firefox – enforce a Cross-origin resource sharing (CORS) restriction policy for fonts. As a result, if you serve the Font Awesome fonts from a separate domain, Firefox (and depending on your server configuration, other browsers as well), will not load the fonts due to this policy, so the icons are not displayed.

CDN (Content Delivery Network)

The most common occurrence is using a CDN. For example, if your site is mydomain.com, but your stylesheets are served from cdn.mydomain.com, or cdn.someotherdomain.com, the browser will not load the fonts because they are served from another domain.

The Solution

There are two options to resolve the issue: either serve your fonts from the same domain as your site, or configure the fonts on your secondary domain to be served with the appropriate headers to allow cross-origin resource sharing.

Serve the files from the same domain

This generally means that you would exclude the Font Awesome files from your CDN, and link the files on your main server instead. The font file itself is the important resource, but generally this would come down to excluding the Font Awesome stylesheet. If you’re using UberMenu’s copy, it is found at

/wp-content/plugins/ubermenu/assets/css/fontawesome/css/font-awesome.min.css

This solution will work, but you won’t be able to take advantage of your CDN for these files.

Set the font headers to allow cross-origin resource sharing

This means that you would configure your server to tell the browser that it’s okay to load these resources from a different domain.

What you’ll need to do is set the Access-Control-Allow-Origin header to * for the fonts. If your server is running apache, this generally just means dropping an .htaccess file into the directory containing the font with the following configuration

<FilesMatch “.(eot|ttf|otf|woff)”>
Header set Access-Control-Allow-Origin “*”
</FilesMatch>

You may have to check your Theme directory if you are not using UberMenu’s Font Awesone…

wp-content/themes/theme_name/fonts and simply add the file
.htaccess in the directory!

UberMenu’s Font Awesome assets are located in /wp-content/plugins/ubermenu/assets/css/fontawesome/fonts/

[Experimental] for SSL website

Header add Access-Control-Allow-Origin “https://www.domain.com”
#Header add Access-Control-Allow-Origin “https://domain.com”
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]