Unexpected firewall behavier !

Discussion in 'Installation/Configuration' started by Keoz, Apr 25, 2020.

  1. Keoz

    Keoz Member

    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,
     
  2. Trimilur

    Trimilur Member

    How did you install ispconfig? Did you use the automatic installer?
     
  3. Taleman

    Taleman Well-Known Member HowtoForge Supporter

  4. Keoz

    Keoz Member

    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 ?
     
  5. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     
  6. Keoz

    Keoz Member

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

    Taleman Well-Known Member HowtoForge Supporter

    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
     
  8. Keoz

    Keoz Member

    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 !
     
  9. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     
  10. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Assuming that output is from server 'B' (which is not clear, perhaps I missed where you said that), the server should be fine as far as port 80/443 firewalling is concerned; it shows both those ports listening, and you have absolutely no firewall rules, only a hook for fail2ban, with a default ACCEPT policy.

    So thoughts at this point:
    - perhaps this is server 'A', not 'B'?

    - perhaps server 'B' is fine, and the ISP's testing failed (eg. they started port scanning server 'A' and by the time they got through 'B' their scanning IP address was blocked by an external firewall/ids?). you could provide actual hostnames/ip addrs if you want someone else to confirm their results.

    - perhaps the web server is bound to only a specific ip address (the actual ip is obfuscated in the above output); what do you get from (probably it shows listening on eg. :::80):
    Code:
    netstat -tnau | grep -E ':80|:443'
    - if those find nothing the problem is likely external to the server.
     
  11. Keoz

    Keoz Member

    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

     
    Last edited: Apr 28, 2020
  12. till

    till Super Moderator Staff Member ISPConfig Developer

    No. And the default PHP version of an operating system is defined by the version of the Linux distribution that you use, it is noted as defined by ISPConfig or the auto-installer. PHP versions are maintained by the Linux Distributions, so having PHP 7.2 as default on Ubuntu is perfectly fine and as it should be.
     
  13. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     
  14. Keoz

    Keoz Member

    • 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 !
     
  15. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Yes, if the issue is outside of the server (eg. an external firewall), it won't do any good to continue troubleshooting your server.
    The VPS config would be the next place to look, starting from the path of the server to the internet. Some VPS providers block port 25 connections, it's possible (though not common) that they block port 80/443 and other ports inbound as well.
    Absolutely not.
    See my previous comment.
     
  16. Keoz

    Keoz Member

    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 ?
     
  17. till

    till Super Moderator Staff Member ISPConfig Developer

    You should question the reliability of your hosting provider instead as they caused the issue by delivering a faulty base setup.

    The ports 22, 443, 80, and 8080 are not closed in a VPS or root server by default as it makes no sense at all to close ports where no service is installed on, on a base setup and ISPConfig did not close these ports. So I have no idea how it could come to your mind to question the reliability of ISPConfig in this case. If these ports are closed, then they have been closed by your hosting provider and not ISPConfig. How shall ISPConfig be aware that your hosting provider is closing ports that are normally not closed on a server or VPS?

    So the next step is, ask your Hosting provider how they blocked the ports and ask them to give you exact instructions on how to unblock what they have locked so that this VPS behaves like any other VPS or root server that you get from other hosting providers. Or even better, ditch that hosting provider and rent a VPS or server from a more reliable source and install ISPConfig there. Personally I host my servers at hetzner.com, works perfectly and of course, no blocked ports.
     
  18. till

    till Super Moderator Staff Member ISPConfig Developer

    As a side note as this wrong assumption has not been contradicted in the thread and might be the reason for wrong assumptions in follow up posts: ISPConfig is NOT configuring the firewall during installation at all. You can add a firewall after installation in ISPConfig though under System. But at install time, no firewall rules are loaded, so any firewall rules that appear and which cause you issues are NOT from ISPConfig.
     
  19. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    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?
     
  20. till

    till Super Moderator Staff Member ISPConfig Developer

    A suggestion to get this thread to an end as I fear we will end nowhere with this: You run this as business and you struggle with the settings of your provider. Maybe it's a good idea to contact Florian from ISPConfig business support and let him check your setup and sort out the issue for you. There are several things that do not really match and if I remember correctly, we came to this thread from an LE issue and I have some doubts that this LE issue is indeed caused by a firewall problem like your provider claims and as @nhybgtvfr pointed out, the claim of your ISP that SSH access is blocked by default and ISPConfig was installed nonetheless is a bit strange too. So my suggestion as you run a business is, contact business support, it does not cost that much, and Florian can probably sort that all out within a short time period.
     

Share This Page