How to bounce a postfix message manually with Core-Admin

How to bounce a postfix message with Core-Admin

In the case you have a message in Postfix queue that you want to bounce without having to wait for queue max life time reached, you can use the following command provided by core-admin-tools package:


Install/update package core-admin-tools if you don’t have command crad-bounce.pyc. For that, use:

>> crad-update.pyc -u
>> crad-update.pyc -g

Command line to bounce a message from Postfix Queue with Core-Admin

>> crad-bounce.pyc -b <postfixqueueid>

In such case, find message id to bounce using mailq as usual. For example:

>> mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
6FC2068C00EF    7041 Wed Nov 29 19:11:08  soXXpeXX@josXXeasXXa.cXX

With this information, you can bounce the message by running:

>> crad-bounce.pyc -b 6FC2068C00EF

Posted in: Postfix

Leave a Comment (0) →

How to limit WordPress updates with Core-Admin

Introduction to WordPress upgrade limit with Core-Admin

The following article explains what are the different wordpress upgrades available, what they cover, if they are automatic and which don’t. Those that are not automatic are considered manual and requires user intervention.
We also explain how you can disable these upgrades totally or partially using Core-Admin #WordpressManager.

About WordPress automatic micro-updates

Before considering disabling WordPress automatic updates, first keep on reading.

Automatic upgrades that can apply WordPress are always targeted to a very reduced and located inside WordPress engine. These upgrades are considered “minor” and only adds or fixes security features.

From WordPress webpage we have the following:
Wordress Core-Admin Micro Updates.

About upgrading WordPress, plugins and themes

Besides WordPress micro-updates (which only upgrades a very small and specific portion as we have said, never all WordPress engine), we have the following 3 categories that you can upgrade and apply to your WordPress:

  1. WordPress upgrades: these updates covers all WordPress engine (including micro-updates and going further).
  2. Plugin updates: these includes upgrades that are released by plugins developers. This is not considered WordPress code covered by previous section..
  3. Theme updates: these includes all files, css, javascript and php that forms the WordPress Theme and, as it happens with plugins, they are not controlled by WordPress. Each update is released by the theme developer.

Having this classification in mind, we can visualize that in one hand we have micro-updates (which are safe) and in the other, we have general updates that might include version change and might potentially break your web (no smooth upgrade).

What updates are applied by WordPress without user intervention

As we have explained in previous sections, WordPress will never update automatically those parts that are not in WordPress’s control and that potentially might make your web stop working.

For that reason, WordPress only applies micro-updates.

For the same reason, WordPress never applies automatic updates without user intervention for WordPress engine, theme or plugins.

Those updates must be done and supervised by a specialized user, the site administrator/developer.
This way, the site developer/administrator can ensure that everything keeps working after upgrading and in such case, take actions if it stops working.

Summary for all updates available for a WordPress

Next it is shown a table that summarises all available updates, its features, etc:

Core Wordpress
Complete wordress
engine updates
plugins updates
Updates for
the theme used by Wordpress
Are automatic?
(no user intervention required)
Yes No, user must apply
them manually
No, user must apply
them manually
No, user must apply
them manually
Can be disabled? Yes Yes, using Core-Admin Wordpress Manager Yes, using Core-Admin Wordpress Manager Yes, using Core-Admin Wordpress Manager
Is recommended to
disable these updates?
No Yes, if you think it is possible
these updaets might break
current project state
Yes, if you think it is possible
these updaets might break
current project state
Yes, if you think it is possible
these updaets might break
current project state

How to limit WordPress updates using Core-Admin and #WordpressManager

Use the following steps to limit part or all WordPress updates for a given installation.

Limiting WordPress Updates with Core-Admin

Posted in: Wordpress, Wordpress Manager

Leave a Comment (0) →

Core-Admin integration for Tor Network tracking, analysis, tagging and blocking

Introduction to Core-Admin tor integration

Tor Network is an anonymizer network infrastructure, opened for everyone for use, that allows users to hide their location (mostly IP) or make it difficult to track ( As its function implies, it can be used to protect users from abuse and tracking.

However, you might be interested in have additional information about how Tor is used to access your services to implement analysis, apply policy or maybe blocking all traffic that might come from Tor (legitimate or not).

Due to the way Tor Network works, all exit nodes are public and can be downloaded. Combined with some tracking functions, it is possible to know if an IP belongs to Tor Network (as an exit node) or was part of it in the past.

Core-Admin provides an integration option that allows having all this information in an usable form so you can integrate it with your infrastructure:


How to enable Tor Network Integration with Core-Admin

For that, open #IpBlocker application as shown:


and then, click to configure:


After that, click to enable Tor Integration as shown:


After enabling it, you will have in your system, an up to database information about Tor Exit-Nodes that are active or were active in the past.

How to use this information about Tor Exit-Nodes with Core-Admin

By enabling this basic integration you have different indications out of the box that can be used. Some of then are the following.

Support to get an indication if a Tor node is detected when checking #IpBlocker tool. That way you will be able to get additional information when checking attacks:


Also, you will also get additional information when requesting for a report about certain ip:


How to integrate Tor Network information provided by Core-Admin with MySQL

To start doing more advanced things, you might be interested in having all this information in a MySQL table (two tables) so you can implement your own queries.

This way, you can not only check, you can also make your application to tag, do quick searches or implement resource policy control and protection.
For example, you might want to deny or allow login if source connection is inside or not Tor Network.

To enable Tor Network integration with MySQL, follow next steps as shown, and input the database were you what the information to be exported and updated. You can configure several MySQL databases.

Core-Admin will keep that MySQL information updated, leaving the rest of the tables untouched. This can be used for empty dedicated MySQL or existing MySQL databases, with working data where a couple of tables will appear and keep updated so your application can access this information using current MySQL API.


How to block Tor Network with Core-Admin

In the case you don’t want any of your services to be available/reachable to any Tor Exit-Node, then use the following option. It will create automatically IP firewall blocking for all exit nodes found. These rules will be updated regularly removing old exit nodes, and adding new active exit nodes.


Command line options to manage Tor Network integration with Core-Admin

There are different options available through crad-ip-blocker.pyc tool. Run the following command to get information about them:

>> crad-ip-blocker.pyc  --help | grep tor
                        also removes old blocking history (retaining last
                        in tor (active,historic) network or not.
  --dump-tor-tracking   Allows to dump all tor tracking information current
                        Allows to block all tor actives nodes currently found.
                        /crad-ip-blocker.pyc --update-tor-exit-nodes-list to
                        active-tor-nodes. Use this option to remove all rules
                        created by --block-active-tor-nodes options.

Something missing or have a doubt? We want to hear your opinion!

Please, if you have a question or a comment, contact us at (

Posted in: Blacklist, Firewall, Tor

Leave a Comment (0) →

How to activate ssh access for a hosting with Core-Admin

Introduction to activate ssh access for a hosting with Core-Admin

By default, all hostings created with Core-Admin will have an individual user to ensure each hosting runs with isolated permissions.
This hosting user has no way to access through ssh, even it if opened ssh port and a password is configured.

This article, explain how to enable or disable ssh access for a given hosting using Core-Admin.


Be sure you have a firewall controlling SSH port (usually 22/tcp) to avoid leaving it open for everyone. It should be limited.
If you don’t have a firewall installed, use #Firewall manager. See the following manual to know how to configure it.

How to activate ssh access to a hosting for Core-Admin

Use the following steps. You will need Administrator rights to complete these steps.
First, open #WebHostingManagement application like this:


Then, open available option to manage SSH access:


After that, select the right hosting to configure and if you want to enable or disable SSH access like this:


Once the process is completed, the system will present you a set of configuration notes ready to use:


How to disable SSH access for particular hosting with Core-Admin

In the case you want to disable SSH access, just follow same steps as described before but selecting “disable” inside “Ssh access”.

How to list hostings with SSH access with Core-Admin

Use available option located at the top level tree:


Posted in: #WebhostingManagement, Administration, Core-Admin, Core-Admin Web Edition, SSH, Web hosting

Leave a Comment (0) →

How to use ipset to block large set of IPs with Core-Admin and #IPBlocker efficiently

Introduction to ipset with Core-Admin

In the case you want to block a large amount of IPs (more that 500 ips/networks), then you might notice that default block-by-iptables setting is not fast enough, and it tends to create a large iptables rule set with a bad performance.


If this is your case, here is how to configure your #IpBlocker tool to use linux kernel ipset.

Prerequisites for ipset with Core-Admin

This option is not available for Debian Lenny, Debian Squeeze and Centos 6 due to poor or missing ipset support.

How to enable it ipset with Core-Admin

#IpBlocker is prepared to switch to block-by-ipset from block-by-iptables and viceversa anytime you need it. This includes cases where the firewall is already enabled and working with a working set of blocking rules.

To enable it, just follow next steps. Open #IpBlocker tool as shown (it needs administrator permissions):


Then, open configuration:


Then, select block-by-ipset in block mode and then save. If it is not available, please, update your core-admin installation. Depending on the number of rules your machine has, it might take a few minutes to switch to ipset:


Operation enabled

If everything went ok, you will use #IpBlocker as usual (and the rest of the system too). No additional step is required because once it is done, it is transparent to the user and system.

Some internal details on how is used ipset with Core-Admin

Under ipset mode, core-admin install only a few rules inside iptables and ip6tables chain to link ipsets created.

>> iptables -S | grep set
-A INPUT -m set --match-set core_admin_blacklist_ipv4_net src -j DROP
-A INPUT -m set --match-set core_admin_blacklist_ipv4 src -j DROP
-A FORWARD -m set --match-set core_admin_blacklist_ipv4_net src -j DROP
-A FORWARD -m set --match-set core_admin_blacklist_ipv4 src -j DROP
-A OUTPUT -m set --match-set core_admin_blacklist_ipv4_net src -j DROP
-A OUTPUT -m set --match-set core_admin_blacklist_ipv4 src -j DROP

These “sets” are accesible running common ipset commands (do not minipulate them directly, use #IpBlocker application or crad-ip-blocker.pyc command line tool):

>> ipset list

Posted in: Blacklist, Security

Leave a Comment (0) →

Integrating with Crad-Log-Watcher to block IPs due login failures for your custom web/server app


    In order to integrate your login failures with crad-log-watcher, to have remote IP blocked automatically when some number of login failures are reached, follow the next guide.

    Next steps will help you to create a login failure handler that will track and manage login failures for any given application, to block source IP in the case a configurable threshold is reached.

    1. First, you have to make your web or server application to generate a log indication about the IP that is going to be blocked.

      We recommend sending this log to syslog because it is accesible to all system users and requires no special privileges. That will simply next steps. If you decide to send this information to another log, just adapt everything as needed.

      With PHP, generating such log will be:

      // in case of login failure ::
              $remoteAddr = $_SERVER['REMOTE_ADDR'];
              $currentWeb   = $_SERVER['SERVER_NAME'];
              $loginAttempted = // point this variable to the login that was attempted and failed
              syslog (LOG_INFO, "Login failure from [$remoteAddr] access denied to [$currentWeb] with user [$loginAttempted]");

      This will make record a log to syslog everytime a login failure happens.
      This change will be required for every web page or server to be protected.

    2. Now, you have to create a custom handler for crad-log-watcher that reads these logs, keep track about login failures and block IPs reaching a threshold:

      For that, create a file called with the following content (adapt as needed):

      from core_admin_common import support
      from core_admin_agent  import checker, watcher
      # database for tracking login failures
      database_path = "/etc/core-admin/client/my.watcher.sql"
      def init ():
          # notify this is child for checker notification
          checker.is_child = True
          # track and lock login failures
          (status, info) = watcher.create_track_login_failure_tables (database_path)
          if not status:
              return (False, "Unable to create ip_registry table, error was: %s" % info)
          return (True, None) # return ok init
      def handle_line (line, source_log):
          # only process log failures to block
          if "login failure from [" in line.lower () and "access denied to [" in line.lower ():
              # assuming log error format:
              # Jul  7 16:15:29 node04-grupodw python: Login failure from [] access denied to [] with user [userAccess1]
              source_ip_to_block    = line.lower ().split ("login failure from [")[1].split ("]")[0]
              login_failure_because = line.lower ().split ("access denied to [")[1].split ("]")[0]
              user_login            = line.lower ().split ("with user [")[1].split ("]")[0]
              # configure notification
              reason                   = "Access failure to %s" % login_failure_because
              fail_logins_before_block = 10
              # call to track user and ip
              watcher.track_and_report_login_failure (user_login, source_ip_to_block, reason, database_path, fail_logins_before_block, source_log)
          # end if
    3. Now, place these file into /var/beep/core-admin/client-agent/log-handlers

    4. Now, inside /etc/core-admin/client/log-watcher.d, create a file that links your /var/log/syslog with the handler you have just created. For example, make that file have the following path: /etc/core-admin/client/log-watcher.d/custom-login-failures-blocker

      <log src="/var/log/syslog" handler="login_failure_handler" />
    5. After that, just restart crad-log-watcher to have it loading your login_failure_handler and configuration created with:
      /etc/init.d/crad-log-watcher restart
    6. Supervise crad-log-watcher execution to ensure everything is working with:
      # tail -f /var/log/syslog | grep crad-log-watcher
    7. Now, test your development by causing login failures to protected system. You should see logs created at /var/log/syslog.
      If you do not see login failure logs, it will not work. Review your code to ensure these logs are created.

    8. If login failure logs are created, then run the following command just to show if login failure tracking is happening:

      # sqlite3 -column -header /etc/core-admin/client/syslog.watcher.sql "select * from login_failure"

    Have any questions? Contact us at (

    Posted in: Blacklist, Firewall, Security

    Leave a Comment (0) →

    Fixing Dovecot panic mail-index-sync-keywords.c, broken dovecot indexes

    Keyword index

    • Dovecot broken indexes
    • Panic: file mail-index-sync-keywords.c:
    • dovecot_mailbox_broken_indexes


    If you have problems while accessing to a mailbox and after reviewing logs you find something like:

    Jul  4 10:44:22 claudia dovecot: imap( Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
    Jul  4 10:44:31 claudia dovecot: imap( Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
    Jul  4 10:45:04 claudia dovecot: imap( Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
    Jul  4 10:45:23 claudia dovecot: imap( Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
    Jul  4 10:45:34 claudia dovecot: imap( Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
    Jul  4 10:46:40 claudia dovecot: imap( Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))
    Jul  4 10:48:45 claudia dovecot: imap( Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record))

    Then, one or more dovecot index and/or cache files are broken. This happens due to moving a mailbox from different dovecot versions. It can also happens with
    outdated dovecot servers.


    Core-Admin will detect these errors automatically and will report a: dovecot_mailbox_broken_indexes

    Click on it and then click on “Reset dovecot indexes”.

    That will clear all dovecot indexes at the destination machine, for the failing mailbox.

    If you want to fix it manually, locate mailbox associated to the user and run the following command
    (update it accordingly to the user mailbox failing):

    >> find /var/spool/dovecot/mail/  -name 'dovecot*' -type f -delete" 

    After that, you should have fixed the problem. No dovecot restart required.

    Posted in: Core-Admin, Dovecot

    Leave a Comment (0) →

    Amavis failing reporting “TROUBLE in child_init_hook: BDB can’t connect db env. at /var/lib/amavis/db”

    Keyword index

    • Amavis trouble in child_init_hook
    • Amavis not processing mails, consuming 100% cpu


    If you find next logs repeatedly and at the same time amavis is not working properly:

    Apr 25 11:40:17 node01[30000]: (!!)TROUBLE in child_init_hook: BDB can't connect db env. at /var/lib/amavis/db: File or directory does not exists. at (eval 94) line 342.
    Apr 25 11:40:17 node01[30001]: (!!)TROUBLE in child_init_hook: BDB can't connect db env. at /var/lib/amavis/db: File or directory does not exists. at (eval 94) line 342.

    Follow next steps to recover service and to stop old notifications:


    This error is detected and automatically recovered by Core-Admin. If you already have Core-Admin, you might have an old version. Upgrade it:

    # crad-update.pyc  -u
    # crad-update.pyc  -g

    Then, manually recover by running the command (or just wait core-admin to do it for you in a few minutes):

    # /usr/share/core-admin/tools/mail_admin/amavis-watcher.pyc --verbose

    After that, you should have service recovered. Restart agent and log-watcher to discard old notifications:

    # /etc/init.d/crad-log-watcher  restart
    # /etc/init.d/crad-agent  restart

    Posted in: Administrador de Correo, Amavis, Mail Admin

    Leave a Comment (0) →

    Postfix reports “Connection timed out” but telnet works

    Keyword index

    • Postfix connection cache
    • Postfix caching connection timeout
    • Postfix keeps reporting “Connection timed out”


    If you happen to find connection timeout reports from Mail delivery reports or directly from log, having a similar information like follows:

    Jan 11 07:32:14 server-smtp-01 postfix/error[11965]: 62E6DEBAD: to=&lt;;, relay=none, delay=17159, delays=17159/0.04/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to[194.X.187.X]:25: Connection timed out)

    ..but at the same time, if you run a telnet operation it works without any problem:

    telnet 194.X.187.X 25
    Trying 194.X.187.X...
    Connected to 194.X.187.X.
    Escape character is '^]'.
    220 ESMTP

    In such context, even if you restart postfix you still find out that it keeps reporting “Connection timed out”.

    At the same time, you already checked that no firewall is blocking that connection: for example, root might be allowed to run telnet over such port but not “postfix” user.

    Why Postfix keep on reporting “Connection timed out”

    All these “Connection timed out” reported by Postfix are usually caused by the postfix connection cache state code:

    That caching code is used by Postfix to speed up operations and avoid keep on talking with slow or failing hosts. It is a performance improvement that, in some cases, might cause problems to you.

    At some point in the past, the destination SMTP server started failing with a timeout. Then, that state was cached by postfix causing this problem.

    How to solve “Connection timed out” when telnet works

    First, try to review configuration parameter “smtp_connect_timeout” to increase it. By default 30 seconds is configured. Do not increase it more than 90 because it might cause you other problems.

    After that, run the following commands to requeue and restart postfix. Remember, this will retry everything:

    postsuper -r ALL
    /etc/init.d/postfix restart

    Posted in: Postfix

    Leave a Comment (0) →

    Controlling postfix content filter Amavis with Valvula (access policy delegation protocol)

    Key index


    Controlling mails checked or produced by Content Filter server (Amavis) by the access policy delegation protocol (Valvula) configured at Postfix.


    Due to the way Postfix works when you configure the parameter “content filter =”, where you configure Amavis or any other Content Filter service, this makes all mail that comes in into Postfix queue, to be then sent to Amavis (or the content filter server you might have) so that mail is processed and, in turn, if everything is fine, that mail comes back to Postfix through a different internal port (typically 10025/tcp).

    From here, we will assume your Content Filter service is Amavis and Valvula your policy delegation server. If it is not the case, this article is still relevant for your configuration.

    Once Amavis have decided that everything is correct, that mail is sent back to postfix in a dedicated port usually declared as follow at /etc/postfix/

    # amavis connection, messages received from amavis inet n - y - - smtpd
     -o content_filter=
     -o local_recipient_maps=
     -o relay_recipient_maps=
     -o smtpd_restriction_classes=
     -o smtpd_client_restrictions=
     -o smtpd_helo_restrictions=
     -o smtpd_sender_restrictions=
     -o smtpd_recipient_restrictions=permit_mynetworks,reject 
     -o mynetworks=
     -o strict_rfc821_envelopes=yes
     -o receive_override_options=no_address_mappings

    As you can see, any mail will be accepted on that port (10025) as long as it comes from localhost (total trust).

    However, the problem we want to solve is how to deal with mails originated from within the server itself (submitted by mail/maildrop) or because a mailman installed (or some configuration produced by the Content Filter server that might produce mails by itself) to make them be also limited by your policy server (Valvula).

    In that case, given the configuration above,  all mails that comes in into Amavis, are not controlled by the policy server you might have installed (in this article Valvula).

    What to change to make policy server be called so your policy is applied

    With this information identified, in the case it is required to filter mails sent back to postfix by the Content Filter server, you can update the following parameter:

            -o smtpd_recipient_restrictions=permit_mynetworks,reject the following:

            -o smtpd_recipient_restrictions=check_policy_service,inet:,permit_mynetworks,reject

    This is the recommended setting with Core-Admin, where the relevant part is “″ and has to be updated with your local settings.

    This way when Amavis finishes, that mail will have to go through Valvula when it goes back to postfix.

    Interactions that might cause this configuration

    This change might make Valvula (or the policy server configured) to be called twice for every mail received. First when it is received and second after Amavis finishes processing mail.

    Why not configure this by default

    This configuration here described might be interesting in some scenarios.

    For the case of dedicated mail servers this configuration is not useful/needed. We mean “dedicated mail servers” those that do not have mailing list software, web pages or any other software that might produce mail internally that might be needed to be limited, blocked or discarded.

    In the other hand, this configuration might not be interesting in all those cases where this limitation can be done in origin (updating the configuration of the service producing those mails to limit) or even using postfix’s authorized_submit_users.

    In short, this is not the only configuration available to limit/control mails from inside the server using policy delegation protocol.

    Posted in: Administrador de Correo, Amavis, Postfix, Security, Valvula

    Leave a Comment (0) →
    Page 1 of 5 12345