Unexpected firewall behavier !

Hi,

*** MY ENVIRONMENTS ***
Working (A) : remote VPS SSD 2 runs Ubuntu 18.04 to serve “alphadomain.com“
Failing (B) : remote VPS SSD 2 runs Ubuntu 18.04 to serve “betadomain.com“

Both environments were implemented exactly the same way from my client space on hosting provider platform (OVH), and websites on A and B were also created and configured the same way from ISPConfig 3 panel installed on both environments.
So, my first question herebelow is based on a test report received from a technical representative of my hosting provider, showing what follows (ports filtered on B) :

*** ENVIRONMENT A ***
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
143/tcp open imap
443/tcp open https
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql
8080/tcp open http-proxy
8081/tcp open blackice-icecap

*** ENVIRONMENT B ***
PORT STATE SERVICE
22/tcp filtered ssh
80/tcp filtered http
443/tcp filtered https
8080/tcp filtered http-proxy

Assuming that firewall gets initially set while installing ISPConfig, how can it be that it is by default deactivated on A and by default activated on B ? How to know what firewall type is set and how to deactivate it, or how open ports on B ?

Regards,

 

How did you install ispconfig? Did you use the automatic installer?

 

Have you run the htf-common issues on both servers? That shows what firewall does on the host. There may be other firewall between the host and Internet.
https://www.howtoforge.com/community/threads/please-read-before-posting.58408/

 

Hi Trimilur, Taleman

Yes, I did use the ISPConfig 3 auto installer for Ubuntu 18.04 (link below), but it is the case on both my two VPS, so this may not be a track to dig if searching why firewall is deactivated on VPS (A) and activated on B !
https://www.howtoforge.com/tutorial/ubuntu-ispconfig-automated-install-script/

• If running the “htf-common-issues“ means a ssh command line to be entered in terminal, I may give it a try and share the output here, but what is exactly the command line to be entered please ? 


• Even if that shows what the firewall does, why is the firewall behave differently while it was set the same way from end to end on two identical environments ?

 

If you read the document linked to, you will discover the needed commands verbatim. You can cut and paste them to command line.

I understood from your post #1 the open ports test was done by your service provider. It is strange two hosts installed by same script would have different configurations. So it makes sense to check the firewall configuration on the host itself, is it really the way the ISP tested. It is futile to ponder why configurations are different if they actually are not.

 

Hello,

These below are the 2 outputs for indicated command lines. Hope that these contains informations that may be related with those provided upon “port state service“ (on top of this thread), so that it allows to better track and find where the issue is. I rely on your help to achieve this.

NB : until now, I never used any of the mailserver or ftp server from the ISPConfig package (but it is upcoming...)

*** OUTPIUT FOR *********************************************
cat htf_report.txt | more
*************************************************************
##### SERVER #####
IP-address (as per hostname): ***.***.***.***
[WARN] could not determine server's ip address by ifconfig
[INFO] OS version is Ubuntu 18.04.4 LTS
[INFO] ISPConfig is installed.

##### ISPCONFIG #####
ISPConfig version is 3.1.15p3

##### VERSION CHECK #####
[INFO] php (cli) version is 7.2.24-0ubuntu***.***.***.***

##### PORT CHECK #####
[WARN] Port 465 (SMTP server SSL) seems NOT to be listening

##### MAIL SERVER CHECK #####
[WARN] I found no "submission" entry in your postfix master.cf
[INFO] this is not critical, but if you want to offer port 587 for smtp connections you have to enable this.
[WARN] I found no "smtps" entry in your postfix master.cf
[INFO] this is not critical, but if you want to offer SSL for smtp (not TLS) connections you have to enable this.

##### RUNNING SERVER PROCESSES #####
[INFO] I found the following web server(s):
Apache 2 (PID 16267)
[INFO] I found the following mail server(s):
Postfix (PID 14398)
[INFO] I found the following pop3 server(s):
Dovecot (PID 14465)
[INFO] I found the following imap server(s):
Dovecot (PID 14465)
[INFO] I found the following ftp server(s):
PureFTP (PID 14551)

##### LISTENING PORTS #####
(only ()
Local (Address)
[localhost]:953 (14558/named)
[anywhere]:25 (14398/master)
[anywhere]:993 (14465/dovecot)
[anywhere]:995 (14465/dovecot)
[localhost]:10023 (30728/postgrey)
[localhost]:10024 (14442/amavisd-new)
[localhost]:10025 (14398/master)
[localhost]:10026 (14442/amavisd-new)
[localhost]:10027 (14398/master)
[localhost]:11211 (31579/memcached)
[anywhere]:110 (14465/dovecot)
[anywhere]:143 (14465/dovecot)
***.***.***.***:53 (14558/named)
[localhost]:53 (14558/named)
[anywhere]:21 (14551/pure-ftpd)
***.***.***.***:53 (868/systemd-resolve)
[anywhere]:22 (1047/sshd)
*:*:*:*::*:953 (14558/named)
*:*:*:*::*:25 (14398/master)
*:*:*:*::*:443 (16267/apache2)
*:*:*:*::*:993 (14465/dovecot)
*:*:*:*::*:995 (14465/dovecot)
*:*:*:*::*:10024 (14442/amavisd-new)
*:*:*:*::*:10026 (14442/amavisd-new)
*:*:*:*::*:3306 (14150/mysqld)
[localhost]10 (14465/dovecot)
[localhost]43 (14465/dovecot)
*:*:*:*::*:8080 (16267/apache2)
*:*:*:*::*:80 (16267/apache2)
*:*:*:*::*:8081 (16267/apache2)
*:*:*:*::*:53 (14558/named)
*:*:*:*::*:21 (14551/pure-ftpd)
*:*:*:*::*:22 (1047/sshd)

##### IPTABLES #####
Chain INPUT (policy ACCEPT)
target prot opt source destination
f2b-sshd tcp -- [anywhere]/0 [anywhere]/0 multiport dports 22

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain f2b-sshd (1 references)
target prot opt source destination
REJECT all -- ***.***.***.*** [anywhere]/0 reject-with icmp-port-unreachable
REJECT all -- ***.***.***.*** [anywhere]/0 reject-with icmp-port-unreachable
REJECT all -- ***.***.***.*** [anywhere]/0 reject-with icmp-port-unreachable
REJECT all -- ***.***.***.*** [anywhere]/0 reject-with icmp-port-unreachable
RETURN all -- [anywhere]/0 [anywhere]/0


*** OUTPIUT FOR **********************************************
dig @localhost mydomain.com
***************************************************************
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @localhost mydomain.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1579
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 177df92250c9c384f001ab135ea5def175bb72d2e765bbc4 (good)
;; QUESTION SECTION:
;mydomain.com. IN A

;; AUTHORITY SECTION:
info. 900 IN SOA a0.info.afilias-nst.info. noc.afilias-nst.info. 2012565878 3600 1800 604800 3600

;; Query time: 210 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 26 21:20:17 CEST 2020
;; MSG SIZE rcvd: 136

 

I am confused now. Do you have only one host? I got the impression that you have two hosts and they behave differently. Yet you post the output of that test script from one host only.
You show the output of dig @localhost. Do you run name service on that host? The dig command is to be run iff

 

Hi,

Considering that the above outputs only concern environment B (top of thread), and as I did not get things done differently from the past (see below), I do not understand what your question is based upon !
I was expecting a reply upon firewall and what to do with it so necessary ports can be open….

I wish to stay focus on environment B (top of the thread), in which I can’t keep Let’s Encrypt check box checked in ISPConfig panel. This means that only one VPS (B) is in concern, and its setup including Ubuntu 18.04 LTS installation, and completed with the installation of ISPConfig, were processed as I always have done it on other VPSs that are still in function and works fine (see below) :

I hope that the following back to basic considerations can help to track and solve what is defective.

*** TO BE CONSIDERED ***

• Server DNS are correctly set and propagated since over 72 hours

• Even if environnement A is OK (top of the thread), I reinstalled the corresponding VPS, Ubuntu, and ISPConfig (automated) several times before I could keep checked both “Let’s Encrypt SSL“ and “SSL“ check boxes : it's still not the case for environment B !.

• I did process to recently implement environments A or B (top of the thread) like I have always done it for other environments (C, D, E) during past years : these implemented in 2019, 2018…, do have check boxes for “Let’s Encrypt SSL“ and “SSL“ checked, are regularly updated, and are still allowing to access websites….

All this is getting me confused and prevents me to prepare the very next future of my business.
The lack of response/solution that may help me, leads me to think that it becomes difficult to rely on ISPConfig, unless the issues have to get solved on side of Ubuntu, or on side of my hosting provider : but how to know ?

Awaiting for some more help and/or guidance please !

 

Could you run the htf-common-issues test script on both of your hosts and post the result? Or put the outputs on two different files and use some diff tool like meld for example to see differences in the outputs. Install meld on your workstation, it needs a GUI to work.
https://packages.ubuntu.com/bionic/meld
https://meldmerge.org/

What I am trying to verify is if the firewall settings on those to hosts really are different.

 

Hi Taleman

*** ENVIRONMENTS REMINDER ***
Working (A) : remote VPS SSD 2 runs Ubuntu 18.04 to serve “alphadomain.com“
Failing (B) : remote VPS SSD 2 runs Ubuntu 18.04 to serve “betadomain.com“

Working means that “Let's encrypyt SSL“ check box keeps beeing checked and that connection to website(s) works, whie Failing means all inversally : reason why, on base of the ports test report from my hosting provider (very top of this thread)…, the goal of this thread is to find what makes firewall blocking the server B connection to necessary ports.

I have found “DIFFCHECKER“ that allows to share diff text files online !
Please open the link below to access a page presenting requested outputs of command lines you provided above :

• Left pane (red) contains the outputs related to environment-VPS B (failing)
• Right pane (green) contains the outputs related to environment-VPS A (working)
https://www.diffchecker.com/7CQpCUPy

If it make sens to you or to any one who wants to help, let me know if it may be usefull to post the link to a page comparing outputs related to environment B, and outputs related to environment C : meaning an environment in which I have never faced any “SSL“ or “Let’s encrypt SSL“ check boxes issues.

I observed that the last PHP version (20th February) is PHP 7.4 and that the ISPConfig automated installer comes with version PHP 7.2. Could this be part of the reasons why “firewall“ is blocking ports, or why “Let's encryp SSLt“ check box is defective ?

Regards

 

It looks to me the firewall configuration is the same on both hosts, except the host on right pane has blocked some IP-numbers. perhaps fail2ban running on that host.
So the problem is not firewall configuration on the host. If the ISP says firewall blocks, that firewall is outside of your host.

 

• Fail2ban should be running on both the two hosts (ISPConfig automated install on both…)

• If you’re right thinking that the firewall blocking is outside of the host, does it mean that I should skip searching tracks of the issue on side of ISPConfig, as well as on side of VPSs ?

• Should I then expose the issue to the Ubuntu Community ?

I have been implementing test and production environments with remote VPSs and ISPConfig 3 since years, and at a time to think of developing a business I can’t do it anymore…!

If anyone has wise advice, I’m more than interested !

 

Hi,

This morning I talked with a technical representative of my hosting provider, this is what he explained to me :

It is normal that on a fresh VPS installation, ports 22, 443, 80, and 8080 are closed.
He also told me that I should search why the installation of ISPConfig does not lead to open these ports (as it should). To be more precise, after that ISPConfig has been installed on this new environment-VPS B, these ports status is not shown as closed, but as “filtered“ (see test report at the very top of the thread).

Based on these informations, what can I do else than to question the reliability of ISPConfig ?

 

another, probably quite pertinent question to ask here ( or rather, ask your hosting provider) is, if by default on their hosting service port 22 is closed on a new vps, how the hell do you connect to it to install/configure anything in the first place?