Technical Support

Technical support is available from any of the options below. You must be logged into our client area to open a ticket with the support, billing, and licensing departments.

Fast-Track paid product support is available Monday-Friday from 8:00 am to 5:00 pm MST.
The current local date and time is Friday - 2017-12-15 10:02 pm MST.




Installation Instructions

Learn how to install Juggernaut Firewall.

First Steps After Installation

Learn how to configure Juggernaut Firewall.

Troubleshooting

Having problems? Learn how to diagnose and debug issues.

To permanently disable all low level kernel messages (iptables etc) from flooding the console do the following changes (as root):

Edit the file /etc/sysctl.conf Add the following line:
kernel.printk = 4 1 1 7 The above changes will be effective at reboot or immediately using the following command: # /sbin/sysctl -p /etc/sysctl.conf To make the changes only temporarily: # echo "4 1 1 7" > /proc/sys/kernel/printk You can check the current setting with: # cat /proc/sys/kernel/printk
View Full Article...

Yes we support blocking attacks like these very easily. See the howto for how to enable a custom login failure trigger:
https://docs.danami.com/juggernaut/how-tos/enable-login-failure-triggers
View Full Article...

Juggernaut firewall does support whitelisting fully qualified domain names. To whitelist your IP so you never get blocked by the firewall or login failure daemon:

1. Sign up to a free dynamic DNS service (most home routers support this directly though the router). eg:  http://www.noip.com/remote-access
2. To whiteist your new FQDN on the firewall:  Add your new FQDN you creaded to: Allow -> Dynamic DNS. Restart the firewall.
3. To whiteist your new FQDN on the login failure daemon: Add your new FQDN you creaded to: Ignore -> Ignore rDNS. Restart the login failure daemon.

You can set how often the login failure daemon will check the FDQN for ip address changes under Settings -> Block Lists & DynDNS -> Dynamic DNS update interval.

The login failure daemon which checks the DNS resolution of the FQDN then whitelists the ip address in the firewall and ignores any blocks detected from that ip address.
View Full Article...

The admin and pro versions of our products are limited to the number of domains you can have in your Plesk panel. If you get this error then it means that you are going over your domain limit. To fix the error you can cancel your current license though our client area then order the 30 domain or unlimited domain licenses. After your order is approved you will get a new license key that you can enter in the license area of the product.
View Full Article...

Jugggernaut 2.X
This is fixed in Juggernaut 2.0+. If using Juggernaut 1.X then we recommmend that you upgrade to version 2.

Juggernaut 1.X
1. You might have Plesk internal debugging enabled. Check that debugging is enabled in /usr/local/psa/admin/conf/panel.ini. It is not compatabile with Juggernaut 1.X debugging and should never be used in production so you must disable it.
If the panel.ini file doesn't exist then it could be that you have debugging enabled in the database. You can disable it with the command:

MYSQL_PWD=`cat /etc/psa/.psa.shadow` mysql -u admin psa -e "replace into misc(param, val) values('debug_util_exec', 'false');" 2. You are blocking Russia on the firewall which blocks Plesks license checks. Plesk changed the license server hostname so we must update it on the firewall.
Disable the firewall on the command line with the command: csf -x Force update the license key with the command: plesk bin license --retrieve Re-enable the firewall with the command: csf -e Whitelist the license check server by logging into Juggernaut and go to Allow -> Allow DynDNS -> Press the advanced button. Change the Plesk license checks entry from ka.odin.com to ka.plesk.com then save and restart the firewall and login failure daemon. Make sure the dynamic dns update interval is set to a reasonable value by going to Block Lists & DynDNS -> DynDNS update interval -> set to 3600 seconds save and restart the firewall and login failure daemon.
View Full Article...

This can usually be fixed by just restarting the Plesk interface:

/etc/init.d/psa restart
View Full Article...

You can disable and enable the firewall from the command line using the following commands:

To disable the firewall: csf -x To re-enable the firewall: csf -e
View Full Article...

View All...


Installation Instructions

Learn how to install Warden Anti-spam and Virus Protection.

First Steps After Installation

Learn how to configure Warden Anti-spam and Virus Protection.

Troubleshooting

Having problems? Learn how to diagnose and debug issues.

No you do not. Plesk already has its own daily spam traing script. The task is called "ExecuteSpamtrain".

/usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/DailyMaintainance/script.php -l
The actual script that is run:
/usr/local/psa/admin/sbin/spamtrain
View Full Article...

Zero hour (0hr) emailed malware has always been an issue. There are various ways of blocking dangerous attachments within zip files, such as Mailscanner/SpamAssassin/Postfix, however ClamAV can also be used to block these attachments which in some environments may be useful.

The sanesecurity free ClamAV rules will cover this. Take a look at the Foxhole databases specifically

http://sanesecurity.com/foxhole-databases/

How to enable free ClamAV Third Party Signatures

https://docs.danami.com/warden/basics/antivirus-hints



View Full Article...

Lots of people seem to be confused by the "autolearn=no" statement in the default X-Spam-Status header. There are usually questions regarding whether or not "no" means SpamAssassin is not autolearning at all. What it actually means is that the specific message which includes the "autolearn=no" part was not autolearned, not that autolearning is disabled or somehow broken.

The three values that can be displayed are "no" (autolearning did not occur), "ham" (the message was learned as ham), and "spam" (the message was learned as spam).

If a message has already been learned by SpamAssassin, then that message will not be learned again. Therefore, if you run a message through SpamAssassin to see why it was classified as spam or ham, and it has already been learned, you will always get the result "autolearn=no". (To see this more clearly, use the "-D" flag, and you will see debug output explaining that the message has already been learned.)

Furthermore, the score used to trigger autolearning is somewhat different than the one reported in the final score; therefore a score displayed in the headers that obstensibly should trigger autolearning will not do so. Again, use the "-D" flag to SpamAssassin, and you will see the score that is used to determine whether or not autolearning will be triggered.

Finally, SpamAssassin requires at least 3 points from the header and 3 points from the body, to auto-learn as spam. If either section contributes fewer points, the message will not be auto-learned.

Possible Autolearn States

ham: the message was learned as ham (non-spam)
spam: the message was learned as spam
no: the specific message didn't achieve the proper threshold values and requirements to be learned
disabled: the configuration specifies bayes_auto_learn 0 or use_bayes 0 and so no autolearning is attempted
failed: autolearning was attempted, but couldn't complete. This happens if SpamAssassin can't gain a lock on the Bayes database files, etc.
unavailable: autolearning not completed for any reason not covered above. It could be the message was already learned.

View Autolearn Score
Warden has a hidden column that can be added to your spam log. Click the column chooser at the bottom of the spam log grid and add the column "Alscore" which contains the actual auto learn score.
View Full Article...

Warden allows you to set the default spam actions for each mailbox to mark, move to spam folder, or delete the message. In addition to this Postfix can drop messages over a certain spam score server wide. This way you can drop messages that have a very high spam score and are certainly spam before they even make it to the users mailbox.

To enable:
postconf -e 'header_checks = regexp:/etc/postfix/header_checks'
Now create the file /etc/postfix/header_checks and put this into it:

/^X-Spam-Level: \*{20,}.*/ DISCARD
DISCARD will delete all messages with a spam score of 20 and above. You can choose another action than DISCARD, they are listed here: http://www.postfix.org/header_checks.5.html

Restart Postfix:

service postfix restart
View Full Article...

This can usually be fixed by just restarting the Plesk interface:

/etc/init.d/psa restart
View Full Article...

View All...