Technischer Support ist unter allen folgenden Optionen verfügbar. Alle Support-Anfragen müssen in Englisch erfolgen. Sie müssen in unserem Kundenbereich eingeloggt sein, um ein Ticket mit den Support-, Abrechnungs- und Lizenzierungsabteilungen zu öffnen.

Die bevorzugte Unterstützung ist von Montag bis Freitag von 8:00 bis 17:00 Uhr verfügbar. MDT.
Das aktuelle lokale Datum und die aktuelle Uhrzeit Tuesday - 2020-09-22 07:12 am MDT.




Installationsanleitung

Erfahren Sie, wie Sie das Produkt installieren.

Erste Schritte

Erfahren Sie, wie Sie das Produkt konfigurieren.

Problembehandlung

Haben Sie Probleme? Erfahren Sie, wie Sie Probleme diagnostizieren und debuggen.

Knowledgebase

Fragen und Antworten zur Selbsthilfe für den Produktsupport, einschließlich Pre-Sales-Fragen.


1. Make sure that you are not blocking the licensing server IP addresses on the servers firewall. Imunify360 is known to block our server IPs for some reason. Our licensing server IP addresses are: IPv4: 198.27.80.6 IPv6: 2607:5300:60:2106:: You can run the following command to see if your server can connect to the licensing server. You should get a response of Verify return code: 0 (ok) if the connection was successful. openssl s_client -connect www.danami.com:443 If you get the error below that means that your server cannot connect to our licensing server (usually that means there is a firewall or connection problem): openssl s_client -connect www.danami.com:443 - returns: socket: Bad file descriptor connect:errno=9 2. Make sure that the date and time on the server is correct (The wrong time will cause the SSL certificate connection to fail). You can sync your server time using the command: /usr/sbin/ntpdate -b -s time.nist.gov 3. Many times this error can be fixed by restarting the Plesk panel: /etc/init.d/psa restart 4. Lastly make sure your openssl and curl packages are up to date: // Centos / RHEL yum update openssl curl // Debian / Ubuntu apt-get update openssl curl 5. If you have tried all of the above steps and you are still not able to connect to the licensing server please open a support ticket and include your servers IP address. The tech will run some tests on our side to see what the problem is.
Vollständiger Artikel anzeigen...

How to test SpamAssassin To test Anti-spam (SpamAssassin), it is necessary to send a Gtube test spam email using the command below (Replacing emailonserver@example.com with a real email account on the server): Centos / RHEL / CloudLinux: echo "XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X" | mail -S smtp=localhost -r sender@example.com -s "Spam test example" emailonserver@example.com Debian / Ubuntu: apt-get install s-nail echo "XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X" | s-nail -S smtp=localhost -r sender@example.com -s "Spam test example" emailonserver@example.com If the Anti-spam is working correctly you will see it listed in the Warden log under Logs -> Message Log. While testing, note that Gtube test email gives +1000 scores to spam. So, even if a mailbox is in the whitelist, mail still be detected as spam because whitelisted email gets -100 scores. How to test ClamAV To test Anti-virus(ClamAV), it is necessary to download the eicar test virus email and send it using the command below (Replacing emailonserver@example.com with a real email account on the server): Centos / RHEL / CloudLinux: wget http://www.eicar.org/download/eicar.com.txt echo "TEST MESSAGE w/ ATTACHMENT" | mail -S smtp=localhost -r sender@example.com -s "A/V test example" -a eicar.com.txt emailonserver@example.com Debian / Ubuntu: apt-get install s-nail wget http://www.eicar.org/download/eicar.com.txt echo "TEST MESSAGE w/ ATTACHMENT" | s-nail -S smtp=localhost -r sender@example.com -s "A/V test example" -a eicar.com.txt emailonserver@example.com If the Anti-virus is working correctly you will see it get blocked and it will be listed in the Warden log under Logs -> Message Log.
Vollständiger Artikel anzeigen...

Warden requires that you use the ClamAV packages from the EPEL repository. In order to prevent the wrong packages from being installed you must add the line exclude=clam* to any conflicting repositories.
For example if you have the imunify360 repo enabled . Edit the file /etc/yum.repos.d/imunify360.repo Before: [imunify360] name=EL-7 - Imunify360 baseurl=https://repo.imunify360.cloudlinux.com/defense360//el/7/updates/x86_64/ username=defense360 password=nraW!F@$x4Xd6HHQ enabled=1 gpgcheck=1 gpgkey=https://repo.imunify360.cloudlinux.com/defense360//RPM-GPG-KEY-CloudLinux After: [imunify360] name=EL-7 - Imunify360 baseurl=https://repo.imunify360.cloudlinux.com/defense360//el/7/updates/x86_64/ username=defense360 password=nraW!F@$x4Xd6HHQ enabled=1 gpgcheck=1 gpgkey=https://repo.imunify360.cloudlinux.com/defense360//RPM-GPG-KEY-CloudLinux exclude=clam* After this is done the extension installer will be able to complete successfully.
Vollständiger Artikel anzeigen...

You can change the interface language under Settings -> Application Settings -> Locale
Vollständiger Artikel anzeigen...

To remove Amavis from the postfix configuration without uninstalling Warden run the following commands: If using Plesk Obsidian (18.X) postconf -MX smtp-amavis/unix postconf -MX 127.0.0.1:10025/inet postconf -PX submission/inet/content_filter postconf -PX smtps/inet/content_filter postconf -PX pickup/fifo/content_filter postconf -X content_filter postconf -X receive_override_options service postfix restart If using Plesk Onyx (17.X) sed -i '/^smtp-amavis \|127.0.0.1:10025 /d' /etc/postfix/master.cf sed -i -e 's/ -o content_filter=smtp-amavis:\[127.0.0.1\]:10026//g' /etc/postfix/master.cf sed -i -e 's/ -o content_filter=smtp-amavis:\[127.0.0.1\]:10027//g' /etc/postfix/master.cf postconf -X content_filter postconf -X receive_override_options service postfix restart After you determine what is causing the problem with Amavis  you can add Amavis back to the postfix configuration by re-running the Warden installer from the command line. It will re-add the removed lines back to the postfix configuration: /usr/local/psa/admin/bin/modules/warden/install.sh
Vollständiger Artikel anzeigen...

By default mail with bad headers is quarantined for review but are still delivered to the users mailbox. If you would like to change this to discard mail with bad headers you can change the setting under Warden -> Settings -> Filter Settings -> Final bad header destiny from pass to discard. To disable all bad header tests: To disable all bad header tests on Centos/RHEL edit the file /etc/amavisd/warden.conf or on Debian/Ubuntu edit the file /etc/amavis/conf.d/99-warden and search for the @bypass_header_checks_maps option. Change from: @bypass_header_checks_maps = (\%bypass_header_checks, \@bypass_header_checks_acl, \$bypass_header_checks_re); Change to: @bypass_header_checks_maps = [1]; To disable all bad header tests for a specific policy bank: If we want to keep bad header tests enabled for incoming email but disable them for our own users. Edit the file /etc/amavisd/warden.conf or on Debian/Ubuntu edit the file /etc/amavis/conf.d/99-warden and add the bypass_header_checks_maps => [1] line to the SUBMISSION and SENDMAIL policy banks: ## POLICY BANKS # submission, SMTPS services $policy_bank{'SUBMISSION'} = { originating => 1, warnbadhsender => 0, terminate_dsn_on_notify_success => 0, bypass_header_checks_maps => [1], }; # sendmail, pickup services $interface_policy{'10027'} = 'SENDMAIL'; $policy_bank{'SENDMAIL'} = { originating => 1, warnbadhsender => 0, terminate_dsn_on_notify_success => 0, bypass_header_checks_maps => [1], }; To disable specific bad header tests: There is an $allowed_header_tests option by which you can define what should be looked up during the bad-header checks, and the list is as follows: other catchall for everything else - normally not used mime Bad MIME (sub)headers or bad MIME structure 8bit Invalid non-encoded 8-bit characters in header control Invalid control characters in header (CR or NUL) empty Folded header field made up entirely of whitespace long Header line longer than RFC 2822 limit of 998 characters syntax Header field syntax error missing Missing required header field multiple Duplicate or multiple occurrence of a header field To disable certain tests on Centos/RHEL edit the file /etc/amavisd/warden.conf or on Debian/Ubuntu edit the file /etc/amavis/conf.d/99-warden and search for the $allowed_header_tests option. Setting a test to 0 will disable that test: $allowed_header_tests{'multiple'} = 0; $allowed_header_tests{'missing'} = 0; After making these changes restart Amavis: // Centos/RHEL/Cloudlinux systemctl restart amavisd // Debian/Ubuntu systemctl restart amavisd-new  
Vollständiger Artikel anzeigen...

Warden makes changes to the following lines in /etc/postfix/master.cf: Before (lines may vary according to your servers operating system): # pickup pickup fifo n - n 60 1 pickup # SMTPS port (465) smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes # submission port (587) (if enabled) submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination After: # pickup pickup fifo n - n 60 1 pickup -o content_filter=smtp-amavis:[127.0.0.1]:10027 # SMTPS port (465) smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o content_filter=smtp-amavis:[127.0.0.1]:10026 # submission port (587) (if enabled) submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination -o content_filter=smtp-amavis:[127.0.0.1]:10026 # amavis smtp-amavis unix - - - - 2 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 -o smtp_tls_security_level=none # postfix-reentry 127.0.0.1:10025 inet n - - - - smtpd -o syslog_name=postfix-reentry -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks -o smtp_tls_security_level=none Warden also adds the following line in /etc/postfix/main.cf: content_filter = smtp-amavis:[127.0.0.1]:10024 If you want the Warden installer to try and repair these files you can run the Warden installer from the command line: /usr/local/psa/admin/bin/modules/warden/install.sh
Vollständiger Artikel anzeigen...

After upgrading to Warden 2.02-1 mail is stuck in the queue. You might see this in the mail log: SELECT command denied to user 'danami_warden'@'localhost' for table 'domain_aliases' at (eval 99) line 173., , Sep 19 04:05:58 mail amavis[6135]: (06135-01) (!!)TROUBLE in process_request: sql exec: err=1142, 42000, DBD::mysql::st execute failed: SELECT command denied to user 'danami_warden'@'localhost' for table 'domain_aliases' at (eval 99) line 173. at (eval 102) line 333. Sep 19 04:05:58 mail amavis[6135]: (06135-01) (!)Requesting process rundown after fatal error mailq recive 127.0.0.1[127.0.0.1] while receiving the initial server greeting Run this command to fix the error: mysql -u admin -p`cat /etc/psa/.psa.shadow` -s -N -e "GRANT SELECT ON psa.domain_aliases TO 'danami_warden'@'localhost'; FLUSH PRIVILEGES;" 2>/dev/null After you are sure that Amavis is working again you can tell postfix to retry delivery of mail in queue with the command: postqueue -f This bug is fixed in Warden 2.02-2 which was published in the Plesk extension directory on 09/21/2020.
Vollständiger Artikel anzeigen...

Alle anzeigen...


Installationsanleitung

Erfahren Sie, wie Sie das Produkt installieren.

Erste Schritte

Erfahren Sie, wie Sie das Produkt konfigurieren.

Problembehandlung

Haben Sie Probleme? Erfahren Sie, wie Sie Probleme diagnostizieren und debuggen.

Knowledgebase

Fragen und Antworten zur Selbsthilfe für den Produktsupport, einschließlich Pre-Sales-Fragen.


1. Make sure that you are not blocking the licensing server IP addresses on the servers firewall. Imunify360 is known to block our server IPs for some reason. Our licensing server IP addresses are: IPv4: 198.27.80.6 IPv6: 2607:5300:60:2106:: You can run the following command to see if your server can connect to the licensing server. You should get a response of Verify return code: 0 (ok) if the connection was successful. openssl s_client -connect www.danami.com:443 If you get the error below that means that your server cannot connect to our licensing server (usually that means there is a firewall or connection problem): openssl s_client -connect www.danami.com:443 - returns: socket: Bad file descriptor connect:errno=9 2. Make sure that the date and time on the server is correct (The wrong time will cause the SSL certificate connection to fail). You can sync your server time using the command: /usr/sbin/ntpdate -b -s time.nist.gov 3. Many times this error can be fixed by restarting the Plesk panel: /etc/init.d/psa restart 4. Lastly make sure your openssl and curl packages are up to date: // Centos / RHEL yum update openssl curl // Debian / Ubuntu apt-get update openssl curl 5. If you have tried all of the above steps and you are still not able to connect to the licensing server please open a support ticket and include your servers IP address. The tech will run some tests on our side to see what the problem is.
Vollständiger Artikel anzeigen...

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
Vollständiger Artikel anzeigen...

Maxmind pulled public access to the GeoLite2 databases as of Dec 31/2019. You can read about the changes here: https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ For now you will have to register on the Maxmind site and setup a free license key: Signup
https://www.maxmind.com/en/geolite2/signup Create a free license key (When asked - Will this key be used for geoipupdate? Choose: no)
https://www.maxmind.com/en/accounts/current/license-key Then in Juggernaut go to Settings -> Geolocation Settings -> enter the MaxMind license key option.
Vollständiger Artikel anzeigen...

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
Vollständiger Artikel anzeigen...

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 created to: Allow -> Dynamic DNS. Restart the firewall.
3. To whiteist your new FQDN on the login failure daemon: Add your new FQDN you created 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.
Vollständiger Artikel anzeigen...

This error means that your service provider is limiting the amount if iptables rules (numiptent)  that your VPS is allowed to create. Your provider can easily raise this limit using the command below on the hardware note (it can't be run inside your VPS). If your provider refuses to raise this limit then it's time to look for a new service provider as they do not really care about your security. vzctl set CID --numiptent 5000 --save Users using Virtuozzo with a limit set will not be able to use the country or blocklists as they will usually put them over their limit. Users can limit the amount of rules that Juggernaut will create by setting the deny permanently limit and deny temporarily limit under Juggernaut -> Settings -> General Settings. Juggernaut will rotate out older entries to stay under the limit set unless the entry is marked with "do not delete". You can also try to limit the number of iptables rules used for country block lists under Juggernaut -> Settings -> Country Settings -> Ignore CIDR blocks smaller than (set it to something like /24). This will allow you to still block the majority of the country while ignoring the smaller networks. Note
Virtuozzo is not the ideal VPS because it does not support ipset for high performance firewall blocking. Most of the larger VPS providers like OVH, Digital Ocean, and Linode have long switched away from using Virtuozzo and now use KVM which fully supports ipset. Even Virtuozzo themselves have switched over to using KVM in Virtuozzo 7.
Vollständiger Artikel anzeigen...

Plesk recently updated the PHP encoder that they use to protect Plesk extensions and you will get this error if your panel is not fully updated. To fix the error you need to update Plesk to the latest microupdate: To update Plesk though the Plesk Interface  1. In Plesk, go to Tools & Settings and click Updates and Upgrades.
 2. On the Updates and Upgrades page, click Update Components. To update Plesk from the command line (run as root) plesk installer update More information on how to update Plesk
https://support.plesk.com/hc/en-us/articles/213385609-How-to-install-Plesk-updates What Plesk update is currently installed on the system? You can view what version your panel is on the "System Overview" section of your home screen after logging in.  Alternatively, execute the following command in a command-line interface: plesk version At the time this article was written here are the latest updates for each branch:

Plesk Onyx 17.0.17 - Update 76
Plesk Onyx 17.5.3 - Update 83
Plesk Onyx 17.8.11 - Update 68

Plesk Changelog
https://docs.plesk.com/release-notes/onyx/change-log/    
Vollständiger Artikel anzeigen...

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
Vollständiger Artikel anzeigen...

Alle anzeigen...


Installationsanleitung

Erfahren Sie, wie Sie das Produkt installieren.

Erste Schritte

Erfahren Sie, wie Sie das Produkt konfigurieren.

Problembehandlung

Haben Sie Probleme? Erfahren Sie, wie Sie Probleme diagnostizieren und debuggen.

Knowledgebase

Fragen und Antworten zur Selbsthilfe für den Produktsupport, einschließlich Pre-Sales-Fragen.


1. Double check that the default_monitor_mode is set: Edit /usr/local/maldetect/conf.maldet and find and set: default_monitor_mode="users" 2. Some users may also need to increase their inotify file watch limit on their systems before the maldet monitoring daemon will start. To view your current limit: cat /proc/sys/fs/inotify/max_user_watches To raise your limit: echo fs.inotify.max_user_watches=524288 > /etc/sysctl.d/sentinel.conf
sysctl -p /etc/sysctl.d/sentinel.conf Start the service:

service maldet restart
Vollständiger Artikel anzeigen...

Plesk recently updated the PHP encoder that they use to protect Plesk extensions and you will get this error if your panel is not fully updated. To fix the error you need to update Plesk to the latest microupdate: To update Plesk though the Plesk Interface  1. In Plesk, go to Tools & Settings and click Updates and Upgrades.
 2. On the Updates and Upgrades page, click Update Components. To update Plesk from the command line (run as root) plesk installer update More information on how to update Plesk
https://support.plesk.com/hc/en-us/articles/213385609-How-to-install-Plesk-updates What Plesk update is currently installed on the system? You can view what version your panel is on the "System Overview" section of your home screen after logging in.  Alternatively, execute the following command in a command-line interface: plesk version At the time this article was written here are the latest updates for each branch:

Plesk Onyx 17.0.17 - Update 76
Plesk Onyx 17.5.3 - Update 83
Plesk Onyx 17.8.11 - Update 68

Plesk Changelog
https://docs.plesk.com/release-notes/onyx/change-log/    
Vollständiger Artikel anzeigen...

Maxmind pulled public access to the GeoLite2 databases as of Dec 30/2019. You now need a free license key before you can download them. You can read about the changes here:

https://blog.maxmind.com/2019/12/18/significant-changes-to-accessing-and-using-geolite2-databases/ Instructions for how to sign up for the free license key can be found below: Warden Anti-spam and Virus Protection
https://docs.danami.com/warden/settings/panel-application/geolocation-settings#how-to-get-a-maxmind-license-key Juggernaut Firewall
https://docs.danami.com/juggernaut/settings/panel-application/geolocation-settings#how-to-get-a-maxmind-license-key Sentinel Anti-malware
https://docs.danami.com/sentinel/settings/panel-application/geolocation-settings#how-to-get-a-maxmind-license-key
Vollständiger Artikel anzeigen...

There is a bug in the Linux Malware Detect v1.6.4 daily cron script. You can fix the error by changing line 69 in /etc/cron.daily/maldet From: elif [ $cron_daily_scan == "1" ]; then To: elif [ "$cron_daily_scan" == "1" ]; then
Vollständiger Artikel anzeigen...

No Sentinel Anti-malware is not designed to be an email scanner. Sentinel Anti-malware is designed to scan and monitor your clients web files. The threat landscape in shared hosted environments is unique from that of the standard AV products detection suite in that they are detecting primarily OS level trojans, rootkits and traditional file-infecting viruses but missing the ever increasing variety of malware on the user account level which serves as an attack platform.
Vollständiger Artikel anzeigen...

Warden requires that you use the ClamAV packages from the EPEL repository. In order to prevent the wrong packages from being installed you must add the line exclude=clam* to any conflicting repositories.
For example if you have the imunify360 repo enabled . Edit the file /etc/yum.repos.d/imunify360.repo Before: [imunify360] name=EL-7 - Imunify360 baseurl=https://repo.imunify360.cloudlinux.com/defense360//el/7/updates/x86_64/ username=defense360 password=nraW!F@$x4Xd6HHQ enabled=1 gpgcheck=1 gpgkey=https://repo.imunify360.cloudlinux.com/defense360//RPM-GPG-KEY-CloudLinux After: [imunify360] name=EL-7 - Imunify360 baseurl=https://repo.imunify360.cloudlinux.com/defense360//el/7/updates/x86_64/ username=defense360 password=nraW!F@$x4Xd6HHQ enabled=1 gpgcheck=1 gpgkey=https://repo.imunify360.cloudlinux.com/defense360//RPM-GPG-KEY-CloudLinux exclude=clam* After this is done the extension installer will be able to complete successfully.
Vollständiger Artikel anzeigen...

You can change the interface language under Settings -> Application Settings -> Locale
Vollständiger Artikel anzeigen...

Normally running nightly scans should not be necessary after doing your first full scan because all changed files in your vhosts tree are scanned automatically when the anti-malware monitor is enabled. If you would like to switch to nightly scans instead you should disable the real-time monitoring. When the anti-malware monitoring is disabled Sentinel will run the nightly cron /etc/cron.daily/maldet which will scan the entire vhosts tree nightly. To disable the anti-malware monitoring and switch to nightly scans: systemctl disable maldet systemctl stop maldet After the anti-malware monitoring is disabled you will see it marked as "Inactive" in the Sentinel dashboard: To re-enable the anti-malware monitoring and switch back to real-time monitoring: systemctl enable maldet systemctl start maldet After the anti-malware monitoring is enabled you will see it marked as "Active" in the Sentinel dashboard:  
Vollständiger Artikel anzeigen...

Alle anzeigen...