[CPANEL-28146] iptables rules automatically overwritten

CreateChange · Jun 18, 2019

Hey there, we caught this new iptables chain (cP-Firewall-1-INPUT) that was added last night, opening us up to the internet via WHM interface, SSH, etc.

Checked lastlog, bash histories, etc., but am seeing no sign of anyone changing it through a specified command.

None of our administrators added this chain - curious if this is something that cPanel would have done through a cPanel automated task?

# iptables -S cP-Firewall-1-INPUT
-N cP-Firewall-1-INPUT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 995 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2080 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2082 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 143 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 26 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2086 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2083 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 993 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8443 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2078 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2077 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2087 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 49152:65534 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2095 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 110 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 579 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 465 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2096 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2079 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A cP-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT

Thanks for any insight that can be provided.

GOT · Jun 18, 2019

I would guess that was cphulk, but someone from cpanel or elsewhere might confirm, we normally disable cphulk when usinf CSF/LFD.

CreateChange · Jun 18, 2019

GOT said:
I would guess that was cphulk, but someone from cpanel or elsewhere might confirm, we normally disable cphulk when usinf CSF/LFD.

Thanks for the response. I have been at this company for over a year, and this is the first time I have seen it happen - we do have cphulk and csf running in tandem.

We simply removed the rule that references to that chain (which was top of the iptables list of rules, so would have effectively bypassed all existing rules), but would like to avoid having to do that again in the future.

CreateChange · Jun 19, 2019

Have been digging a bit more, but not making too much progress...

Found a cronjob that updates csf daily (/usr/sbin/csf -u), but from what I can find that doesn't call any sort of standard config to be dropped in.

However, I found the following script (/scripts/configure_firewall_for_cpanel), which calls the below function from this file: /usr/local/cpanel/Cpanel/Services/Firewall.pm

Code:

sub _setup_with_iptables {
    my ( $service, $cmd ) = @_;

    my $iptables_cmd = $cmd->{'iptables'};
    my $iptables_save_cmd = $cmd->{'iptables-save'};

    # TCP ports
    my @allow_tcp_ports = Cpanel::Services::Ports::Authorized::allowed_tcp_ports();

    # UDP ports
    my @allow_udp_ports = Cpanel::Services::Ports::Authorized::allowed_udp_ports();

    my ( @temp_tcp, @temp_udp );

    my @lines_to_insert = (
        "INPUT -j cP-Firewall-1-INPUT",
        "FORWARD -j cP-Firewall-1-INPUT",
    );

    # Don't save if it looks like the current ruleset hasn't been loaded.
    my @current_rules = grep { /^\-A/ } split /\n/, Cpanel::SafeRun::Simple::saferunnoerror( $iptables_cmd, '-S' );
    my $conf_file = $iptables_cmd eq 'ip6tables' ? '/etc/sysconfig/ip6tables' : '/etc/sysconfig/iptables';
    my $read_only = ( !-z $conf_file && $#current_rules == -1 ) ? 1 : 0;

    Cpanel::SafeRun::Dynamic::livesaferun(
        'prog' => [$iptables_save_cmd],
        'formatter' => sub {
            my ($line) = @_;
            chomp $line;

            return if ( $line !~ /^-A/ );
            if ( $line =~ m/-A OUTPUT -j \Q$port_authority_name\E/ ) {
                $has_port_authority_chain++;
            }

            # If we already have an entry matching this line, remove it from the # list of lines to insert so we don't insert a duplicate.
            foreach my $insert_line (@lines_to_insert) {
                if ( index( $line, "-A $insert_line" ) != -1 ) {
                    @lines_to_insert = grep { $_ ne $insert_line } @lines_to_insert;
                    return;
                }
            }

            foreach my $port (@allow_tcp_ports) {
                if ( $line =~ /^-A (?:cP-Firewall-1-)?INPUT -p tcp -m state --state NEW -m tcp --dport $port -j ACCEPT/ ) {
                    push @temp_tcp, $port;
                }
            }

            foreach my $udp_port (@allow_udp_ports) {
                if ( $line =~ /^-A (?:cP-Firewall-1-)?INPUT -p udp -m state --state NEW -m udp --dport $udp_port -j ACCEPT/ ) {
                    push @temp_udp, $udp_port;
                }
            }

            return;
        }
    );

    # Remove ports from @allow_tcp_ports that exist in @temp_tcp (ports already configured w/ iptables).
    my %tcp_diff;
    @tcp_diff{@allow_tcp_ports} = @allow_tcp_ports;
    delete @tcp_diff{@temp_tcp};
    @allow_tcp_ports = ( keys %tcp_diff );
    # Same for UDP ports.
    my %udp_diff;
    @udp_diff{@allow_udp_ports} = @allow_udp_ports;
    delete @udp_diff{@temp_udp};
    @allow_udp_ports = ( keys %udp_diff );

    # Rules for iptables
    my $iptables_rules = [
        "-N cP-Firewall-1-INPUT",
        ( map { /^(\S+)\s+(.*)$/; "-I $1 1 $2" } @lines_to_insert ),
        ( map { "-A cP-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport $_ -j ACCEPT" } @allow_tcp_ports ),
        ( map { "-A cP-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport $_ -j ACCEPT" } @allow_udp_ports ),
        _get_port_authority_rules(),
    ];

Appears that this would be the source of the rules being updated (see chain name), though I am unsure 1. how this might be invoked and 2. how to stop this without breaking something else. Any insight into how we can stop this chain from being added to the ruleset would be appreciated.

cPanelMichael · Jun 19, 2019

Hello @CreateChange,

My initial thought is the firewall rules were added as part of the Calendar and Contacts plugin installation process, however I'm not reproducing the addition of the same rules reported in your first post upon testing this on a server running cPanel & WHM version 80.0.18. Can you open a support ticket so we can take a closer look at your system to determine exactly how those rules were added? Let me know the ticket number and I'll update this thread with the outcome once the ticket is closed.

Thank you.

roliboli · Jul 2, 2019

Hi @cPanelMichael

Any news regarding this issue?

thanks

cPanelMichael · Jul 2, 2019

Hello @roliboli,

We are tracking reports of this issue as part of case CPANEL-28146.

The current case replication steps center around modifying an account's username, however we are seeking access to affected systems to confirm other potential causes. I encourage you to submit a support ticket and reference this post so we can take a look at an affected system and rule out additional causes.

I'll update this thread as soon as more information on the status of this case is available.

Thank you.

cPanelMichael · Jul 25, 2019

Hello Everyone,

This is fixed in cPanel & WHM version 82.0.4:

Fixed case CPANEL-28146: Avoid overwriting existing firewall settings.

Notes:
1. This fix only takes effect when the cPanel-Firewall-1-INPUT iptables chain is missing. It does not take effect if the cPanel-Firewall-1-INPUT iptables chain is already added. If a new iptables addition includes whitelisted cPanel ports, then those same ports must be removed from the cPanel-Firewall-1-INPUT chain.
2. This fix does not take effect if the firewalld service is active.

Long term, an internal improvement case is open to discuss refactoring /usr/local/cpanel/Cpanel/Services/Firewall.pm to better consider the use of custom firewalld and iptables rules on cPanel & WHM servers.

Thank you.

CreateChange · Jul 26, 2019

cPanelMichael said:
Hello Everyone,

This is fixed in cPanel & WHM version 82.0.4:

Notes:
1. This fix only takes effect when the cPanel-Firewall-1-INPUT iptables chain is missing. It does not take effect if the cPanel-Firewall-1-INPUT iptables chain is already added. If a new iptables addition includes whitelisted cPanel ports, then those same ports must be removed from the cPanel-Firewall-1-INPUT chain.
2. This fix does not take effect if the firewalld service is active.

Long term, an internal improvement case is open to discuss refactoring /usr/local/cpanel/Cpanel/Services/Firewall.pm to better consider the use of custom firewalld and iptables rules on cPanel & WHM servers.

Thank you.

Thank you for the update, Michael. Will start getting our servers updated to at least that release.

Appreciate the followup. Have a good weekend.

Arvy · Sep 16, 2019

Hello,

I have a cPanel VPS that I don't want my users to use IMAP, just POP3. I disabled ports 143/993 in Iptables. I created my own etc / sysconfig / iptables file.

However, every time cPanel is updated, it creates a cP-Firewall-1-INPUT chain and recreates all nonexistent rules, allowing users to access IMAP ports.

How can I disable cP-Firewall-1-INPUT creation and not let cPanel touch my Iptables file?

Thanks.

cPanelMichael · Sep 17, 2019

Hello @Arvy,

I moved your post into this thread. Can you share which cPanel & WHM version is installed on the affected server?

Thank you.

Arvy · Sep 17, 2019

Hello @cPanelMichael,

ok about the post. I'm using WHM 82.0.14. Happened in 2 servers, both VPSs with CentOS (one 6.10 and another 7.6).

I just manually removed cP-Firewall-1-INPUT references and restarted iptables. But, before some recent update, it was not in there.

Rogerio/Arvy

Arvy · Sep 17, 2019

Here is my previous file (before the update) and it's my actual config after manually removed the chain, only the "*filter" piece, for reference.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6288:4971923]
:BLACKLIST - [0:0]
-A INPUT -j BLACKLIST
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2100:2199 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2082 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2083 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2086 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2087 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2095 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 2096 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -p tcp -m multiport --dports 25,465,587 -m owner --gid-owner mailman -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 25,465,587 -m owner --gid-owner mail -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -p tcp -m multiport --dports 25,465,587 -m owner --uid-owner cpanel -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports 25,465,587 -m owner --uid-owner root -j ACCEPT
-A BLACKLIST -s 201.157.248.0/21 -j DROP
-A BLACKLIST -s 201.157.246.0/23 -j DROP
COMMIT

As you can see, I filter some non-used ports like 143, 993, and some 20XX too.

Arvy · Sep 19, 2019

Another info: cPanel appears to be running "iptables-save" because my /etc/sysconfig/iptables file had rules that I'd inserted manually (console) but not saved on it.

wrt-int · Oct 23, 2019

I am definitely still seeing this on WHM 82.0.17 as recently as today. This is a ludicrous security issue that cPanel can't seem to squash for good. I am currently running the following every 5 minutes from cron

/sbin/iptables -D INPUT -j cP-Firewall-1-INPUT 2> /dev/null && echo "cP-Firewall-1-INPUT Removed"

Norbert · Dec 9, 2019

I had the exact issue for quite a while now, and I spent quite a lot of time trying to fix my pre-firewall because I could not imagine that cPanel would do this. Upon asking for support, they had not even log in and said "After investigation, this problem does not appear to be related to or caused by cPanel or by the basic configuration of the cPanel-bundled software. However, as a courtesy, I have done some preliminary research to assist you in resolving this issue. ".

Nop, you are wrong. It is caused by cPanel, and there was no "research" made.

The chain "cP-Firewall-1-INPUT" is automatically added and opening ports to attackers thus making my server vulnerable.

Not happy with this, expecting explanation, and resolution asap.

cjacksonactx · Dec 31, 2019

Norbert said:
I had the exact issue for quite a while now, and I spent quite a lot of time trying to fix my pre-firewall because I could not imagine that cPanel would do this. Upon asking for support, they had not even log in and said "After investigation, this problem does not appear to be related to or caused by cPanel or by the basic configuration of the cPanel-bundled software. However, as a courtesy, I have done some preliminary research to assist you in resolving this issue. ".

Nop, you are wrong. It is caused by cPanel, and there was no "research" made.

The chain "cP-Firewall-1-INPUT" is automatically added and opening ports to attackers thus making my server vulnerable.

Not happy with this, expecting explanation, and resolution asap.

My Cpanel Instance just did this same thing on Sunday, 12/29. Overwrote my rules; I was trying to figure out why IP's from CHINA and Russia were trying to login to root; how did they get past my...oh I see...Cpanel Replaced my rules. This is an issue; I have half a mind to modify the /scripts/configure_firewall_for_cpanel and see if that stops it. But Cpanel is definitely modifying and changing things; despite my custom rules. It is an issue with cPanel/WHM and they need to fix it. We are using the latest version of Cpanel 84.0.18.

cjacksonactx · Dec 31, 2019

Here's a great idea. How about; unless the Administrator, root, says touch the firewall...Cpanel and it's automated scripts leave it alone. There should be nothing automated modifying the iptables or any other firewall module; or making changes that cannot be turned off or prevented from happening. This under the hood devious scripting overwriting rules and leaving a system completely wide open to a wide array of attacks is ridiculous. No Script or Service within Cpanel should touch iptables or firewalld without explicit authorization and configuration to do so within the panel; and a clear description of what said script is going to do or be doing that it has a need to touch said iptables or firewalld rules. Like CPHULK blocking at the firewall level; we know it makes specific modifications to the chain "cphulk"; leaving everything else untouched. No other script should touch any other iptable or firewalld rule without explicit say so of the admin.

Arvy · Jan 20, 2020

Happened this weekend again (January/2020):

I'm running a cron job daily: grep cP-Firewall /etc/sysconfig/iptables

Today I got an email with:

:cP-Firewall-1-INPUT - [0:0]
-A INPUT -j cP-Firewall-1-INPUT
-A FORWARD -j cP-Firewall-1-INPUT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8443 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 26 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2077 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2079 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2078 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2080 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 579 -j ACCEPT
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 49152:65534 -j ACCEPT

Ports that I don't want to be available, all others are set on INPUT chain.

garconcn · Jan 20, 2020

cPanel still hasn't fixed the issue until now. You can trigger the issue when changing cpanel ID, quota, bandwidth, plan in WHM or using API.

Thread starter	Similar threads	Forum	Replies	Date
K	In Progress CPANEL-42899 - Header Response	Security	8	Saturday at 1:18 PM
B	Server's own IP in cpHulk reporting system cpaneld auth failure?	Security	13	May 13, 2023
A	AutoSSL not generating certificate for domains with previous external certificates (cPanel or ZeroSSL), even after expiration or deletion	Security	1	Apr 27, 2023
	/usr/local/cpanel/bin/rebuild_sprites can be run as capnel user?	Security	1	Apr 24, 2023
S	Rooted Status and cPanel Washing its Hands of Us	Security	6	Apr 18, 2023

[CPANEL-28146] iptables rules automatically overwritten

Member

Get Proactive!

Member

Member

Administrator

Well-Known Member

Administrator

Administrator

Member

Well-Known Member

Administrator

Well-Known Member

Well-Known Member

Well-Known Member

Registered

Registered

Registered

Registered

Well-Known Member

Well-Known Member