Netino

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 ApplicationsA 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 IPIf 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 ConfigurationThe 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 JobsA 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 AccessThe 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 ConfigurationIf 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 MonitoringAnalyze 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:Check Network Configuration: Verify the IP addresses assigned to the network interface. Ensure no services are bound to the secondary IP. Analyze Traffic: Use tools like tcpdump or iftop to capture and analyze traffic on the secondary IP. Review DNS Settings: Ensure no DNS records point to the secondary IP. Inspect Running Processes: Identify any processes generating traffic on the secondary IP. Check for Malware: Run a malware scan and investigate suspicious activity. 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.

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.

What webserver(s) you use?

To check it against PCRE, could you post just one line from your logs not being catched..?! Regards, 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

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.

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. "

Unfortunately, apache does not work with 3.0.x version. Do you use just nginx? In the same way, I have installed in cwpsrv server. I can share the (long) command sequence with you, if would be useful.

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.

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

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.

Before running this script, I just would run: sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-* sed -i 's|#\s*baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-* Regards, Netino

Ok, thanks. I posted the problem there, but could not show the results of my screen to them, because the system seems to block the message. But I could posted the URL attack. Thanks!

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.

The solution is here: https://www.roundcubeforum.net/index.php?topic=29678.0 Regards, Netino