Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

As the bare-iron server came from my long-time cloud provider (since
Debian 6), incoming ports 80 and 443 are blocked.

I ran my usual iptables command for new servers from them, but this
time the default settings were different so it didn't work.

Output from "sudo iptables -S" before my attempt:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 62.204.41.56/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.173.48/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 167.172.187.120/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.156.124.69/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.154.46.209/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.172.98/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 122.160.233.137/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN

My usual incantation and response:

# sudo iptables -A IN_public_allow -p tcp -m tcp --dport 80 -m
conntrack --ctstate NEW,UNTRACKED -j ACCEPT
iptables: No chain/target/match by that name.

Then I tried:

# sudo iptables -A INPUT -p tcp -m tcp --dport 80 -m conntrack
--ctstate NEW,UNTRACKED -j ACCEPT
# sudo iptables -A INPUT -p tcp -m tcp --dport 443 -m conntrack
--ctstate NEW,UNTRACKED -j ACCEPT

Again checking status:

# sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate
NEW,UNTRACKED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A f2b-sshd -s 62.204.41.56/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.173.48/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 167.172.187.120/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.156.124.69/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.154.46.209/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.172.98/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 122.160.233.137/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN

But no open ports in spite of the output shown.

I am considering moving to ufw but am reluctant due to the possibility
of getting locked-out of my remote server. I am used to logging in
with two separate terminals to avoid that during initial setup but
want to make sure that is safe.

Suggestions welcome!

-Tom

[Dan Ritter]

Tom Browder wrote:
> As the bare-iron server came from my long-time cloud provider (since
> Debian 6), incoming ports 80 and 443 are blocked.
>
> I ran my usual iptables command for new servers from them, but this
> time the default settings were different so it didn't work.
>
> Output from "sudo iptables -S" before my attempt:
>
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
> -A f2b-sshd -s 62.204.41.56/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 61.177.173.48/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 167.172.187.120/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 43.156.124.69/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 43.154.46.209/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 61.177.172.98/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 122.160.233.137/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -j RETURN

This is strongly suggestive of having fail2ban installed.

The -P statements set default policy for each of the default
chains: if nothing else happens to a packet, that's the policy.

> My usual incantation and response:
>
> # sudo iptables -A IN_public_allow -p tcp -m tcp --dport 80 -m
> conntrack --ctstate NEW,UNTRACKED -j ACCEPT
> iptables: No chain/target/match by that name.

IN_public_allow hasn't been created and isn't a default.

> Then I tried:
>
> # sudo iptables -A INPUT -p tcp -m tcp --dport 80 -m conntrack
> --ctstate NEW,UNTRACKED -j ACCEPT
> # sudo iptables -A INPUT -p tcp -m tcp --dport 443 -m conntrack
> --ctstate NEW,UNTRACKED -j ACCEPT

Which is fine, but remember that the default policies all the
way around are ACCEPT, so this doesn't change anything until you
change the policy.

> Again checking status:

[normal output]

> But no open ports in spite of the output shown.

1. How are you checking that?

2. Have you asked the cloud provider if they need an extra step
on their end to open up the ports? It's likely on their side.

> I am considering moving to ufw but am reluctant due to the possibility
> of getting locked-out of my remote server. I am used to logging in
> with two separate terminals to avoid that during initial setup but
> want to make sure that is safe.

The cloud provider should provide console access via emulated
serial port or similar for you to get in without going through
the VM's network.

-dsr-

[Georgi Naplatanov]

On 5/28/22 22:11, Tom Browder wrote:
> As the bare-iron server came from my long-time cloud provider (since
> Debian 6), incoming ports 80 and 443 are blocked.
>
> I ran my usual iptables command for new servers from them, but this
> time the default settings were different so it didn't work.

Try to flush the tables and (re)set default policies for the existing
chains.

> Output from "sudo iptables -S" before my attempt:
>
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
> -A f2b-sshd -s 62.204.41.56/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 61.177.173.48/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 167.172.187.120/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 43.156.124.69/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 43.154.46.209/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 61.177.172.98/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 122.160.233.137/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -j RETURN
>
> My usual incantation and response:
>
> # sudo iptables -A IN_public_allow -p tcp -m tcp --dport 80 -m
> conntrack --ctstate NEW,UNTRACKED -j ACCEPT
> iptables: No chain/target/match by that name.

You have no chain "IN_public_allow". Probably you should create it.

> Then I tried:
>
> # sudo iptables -A INPUT -p tcp -m tcp --dport 80 -m conntrack
> --ctstate NEW,UNTRACKED -j ACCEPT
> # sudo iptables -A INPUT -p tcp -m tcp --dport 443 -m conntrack
> --ctstate NEW,UNTRACKED -j ACCEPT

It's a good practice to set input/output network interfaces.

> Again checking status:
>
> # sudo iptables -S
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -N f2b-sshd
> -A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
> -A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate
> NEW,UNTRACKED -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT

You have second rule for port 80/tcp, do you need it?

> -A f2b-sshd -s 62.204.41.56/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 61.177.173.48/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 167.172.187.120/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 43.156.124.69/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 43.154.46.209/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 61.177.172.98/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -s 122.160.233.137/32 -j REJECT --reject-with icmp-port-unreachable
> -A f2b-sshd -j RETURN
>
> But no open ports in spite of the output shown.
>
> I am considering moving to ufw but am reluctant due to the possibility
> of getting locked-out of my remote server. I am used to logging in
> with two separate terminals to avoid that during initial setup but
> want to make sure that is safe.
>

Kind regards
Georgi

[IL Ka]

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 62.204.41.56/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.173.48/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 167.172.187.120/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.156.124.69/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.154.46.209/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.172.98/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 122.160.233.137/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN

This is fail2ban chain to block bots, but I strongly suggest to use ipset and not to store each network as separate rule.

On my Debian server I use netfilter-persistent with ipset plugin and fail2ban.

Works like charm!

https://dhtar.com/make-ipset-and-iptables-configurations-persistent-in-debianubuntu.html

But since policy is "ACCEPT", other ports are open.

My usual incantation and response:

    # sudo iptables -A IN_public_allow -p tcp -m tcp --dport  80 -m
conntrack --ctstate NEW,UNTRACKED -j ACCEPT
    iptables: No chain/target/match by that name.

What is "IN_public_allow"

I do not see chain with this name. Do you?

 

# sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate

...

But no open ports in spite of the output shown.

Hmm, I see 80 and 443 are open here. How did you check?

(I suggest to use multiple ports rule (multiport), btw)

  

I am considering moving to ufw

It is up to you. I see no reason to use ufw. At least, it doesn't support ipset:)

Also, check (using update-alternatives) if you are using iptables of nft 

You may be interested in good iptables tutorial:

https://tldp.org/LDP/nag2/nag2.pdf

(section 9.8)

[Tom Browder]

On Sat, May 28, 2022 at 14:11 Tom Browder <tom.b...@gmail.com> wrote:

As the bare-iron server came from my long-time cloud provider (since
Debian 6), incoming ports 80 and 443 are blocked.

A little more digging shows the new server is using fail2ban and nft tables, so I

need help on how to properly allow https and http inbound.

Thanks.

-Tom

[IL Ka]

A little more digging shows the new server is using fail2ban and nft tables, so I

need help on how to properly allow https and http inbound.

I am not familiar with nft, bit you can switch to iptables using ``update-alternatives``

 

# update-alternatives --set iptables /usr/sbin/iptables-legacy
# update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
# update-alternatives --set arptables /usr/sbin/arptables-legacy
# update-alternatives --set ebtables /usr/sbin/ebtables-legacy

I am using iptables on my servers. nfs is good, but I do not have time (for now) to learn it

[Dan Ritter]

We have established that you do not have a firewall on your
machine blocking ports. iptables and nftables control the same
underlying mechanism, and you have clearly set the policy to
ACCEPT.

Therefore, something outside of your machine is blocking the
ports, or you are misreading or misusing the tools that are
telling you the ports are blocked.

Tell us how you are checking the ports.

-dsr-

[Tom Browder]

On Sat, May 28, 2022 at 17:08 Dan Ritter <d...@randomstring.org> wrote:

…

Therefore, something outside of your machine is blocking the
ports, or you are misreading or misusing the tools that are
telling you the ports are blocked.

Tell us how you are checking the ports

I am running an Apache server and using Qualys Lab’s server checker. It shows no access to the server.

And my server leasing company blocks no ports outside each host’s own settings.

Whatever attempt I make to change the ports disappears when I reboot.

-Tom

[IL Ka]

I am running an Apache server and using Qualys Lab’s server checker. It shows no access to the server.

Have you tried to telnet to port 80 from home? Do you see apache listening this port using ``ss``?

 

Whatever attempt I make to change the ports disappears when I reboot.

Sure, because you need netfilter-persistent (at least for iptables)

 

-Tom

[Tom Browder]

On Sat, May 28, 2022 at 17:30 IL Ka <kazakev...@gmail.com> wrote:

I am running an Apache server and using Qualys Lab’s server checker. It shows no access to the server.

Have you tried to telnet to port 80 from home? Do you see apache listening this port using ``ss``?

On the new host I did:

    $ sudo su

    # telnet 80

    Trying 0.0.0.80...

    

and gave up waiting.

[Tom Browder]

Maybe I should remove all firewall progs and start from zero.

[Greg Wooledge]

On Sat, May 28, 2022 at 05:51:38PM -0500, Tom Browder wrote:
> $ sudo su
> # telnet 80
> Trying 0.0.0.80...

... wow. Just wow. How can such a short excerpt contain so many failures?

1) "sudo su" is stupid. You don't need TWO setuid programs to get a root
shell. Either use "sudo -s" or "su". Hell, even "sudo bash" would
make more sense and would be less wasteful.

2) As you can PLAINLY SEE in the output of telnet, you messed up the
arguments. You supplied "80" as a hostname/address, instead of a
port number. If you wanted to probe port 80 of your web server, you
need to supply the web server's hostname/address as the first argument,
and 80 (the port number) as the second argument.

3) You don't need to be root to telnet to another host (or the same host,
if you're giving "localhost" as the hostname) in the first place.

[Tom Browder]

On Sat, May 28, 2022 at 19:01 Greg Wooledge <gr...@wooledge.org> wrote:

On Sat, May 28, 2022 at 05:51:38PM -0500, Tom Browder wrote:

…

... wow.  Just wow.  How can such a short excerpt contain so many failures?

Greg, calm down.  I get it, but I haven’t unlearned years of muscle memory—sorry.

And the telnet thing was something I haven’t done for MANY years and it was a “shot in the dark—again, forgive me.

[Timothy M Butterworth]

On Sat, May 28, 2022 at 7:52 PM Tom Browder <tom.b...@gmail.com> wrote:

On Sat, May 28, 2022 at 17:51 Tom Browder <tom.b...@gmail.com> wrote:

On Sat, May 28, 2022 at 17:30 IL Ka <kazakev...@gmail.com> wrote:

I am running an Apache server and using Qualys Lab’s server checker. It shows no access to the server.

Have you tried to telnet to port 80 from home? Do you see apache listening this port using ``ss``?

On the new host I did:

    $ sudo su

    # telnet 80

    Trying 0.0.0.80...

    

and gave up waiting.

 

On the local host try running `telnet 127.0.0.1 80` If you can not connect to the web server on the local host then it is likely not running. Try running `sudo service --status-all` `sudo systemctl enable apache2` and `sudo service apache2 start`

[Tom Browder]

On Sat, May 28, 2022 at 19:10 Timothy M Butterworth <timothy.m....@gmail.com> wrote:

…

On the local host try running `telnet 127.0.0.1 80`

I was able to connect, thanks, Timothy!

Now what? I would really like to use ufw.

-Tom

[IL Ka]

    $ sudo su

    # telnet 80

    Trying 0.0.0.80...

1. You are using telnet wrong: it should be "telnet [host] [port]". Please read "man telnet".

2. You do not need sudo to use telnet, do not do that

3. You should also check that Apache is running and listening to this port, use ``ss -lt``. 

For this command you _may_ use sudo to get process names (``sudo ss -ltp``). Read ``ss --help``

If you were able to connect on this host, then try to connect to this machine from outside using public IP 

 

[Tom Browder]

Thanks, I will try that tomorrow.

-Tom

[Tom Browder]

On Sat, May 28, 2022 at 20:06 IL Ka <kazakev...@gmail.com> wrote:

...

3. You should also check that Apache is running and listening to this port, use ``ss -lt``. 

For this command you _may_ use sudo to get process names (``sudo ss -ltp``). Read ``ss --help``

If you were able to connect on this host, then try to connect to this machine from outside using public IP

I can ssh in to the remote host. Then I tried telnet to port 80 on the same host from the outside with the public IP and got no good response:

    $ telnet x.y.z.w 80

    Trying x.y.z.w...

    telnet: Unable to connect to remote host: No route to host

-Tom

   

[Tom Browder]

On Sun, May 29, 2022 at 05:41 Tom Browder <tom.b...@gmail.com> wrote:

Does anyone have a good reason for me to NOT install and enable UFW?

-Tom

[IL Ka]

Does anyone have a good reason for me to NOT install and enable UFW?

ufw can't be used with ipset AFAIK, and I use ipset for many reasons (fail2ban, block access outside of my country etc).

But If you only SSH your host from one static IP, you probably do not need fail2ban at all.

Anyway, I am not sure that port 80 is blocked by your firewall and not your hosting firewall 

[IL Ka]

    $ telnet x.y.z.w 80

    Trying x.y.z.w...

    telnet: Unable to connect to remote host: No route to host

But you can ssh to this host, right?

Well, that means the firewall blocks your request and sends the ICMP message "no route to host".

Switch to the legacy iptables using ``update-alternatives`` and check ``iptables -L -v -n`` again.

If no rule blocks this port, ask your hosting company.

 

   

[Tom Browder]

On Sun, May 29, 2022 at 07:06 IL Ka <kazakev...@gmail.com> wrote:

Does anyone have a good reason for me to NOT install and enable UFW?

ufw can't be used with ipset AFAIK, and I use ipset for many reasons (fail2ban, block access outside of my country etc).

But If you only SSH your host from one static IP, you probably do not need fail2ban at all.

Good to know. But does fail2ban require ipset?

Anyway, I am not sure that port 80 is blocked by your firewall and not your hosting firewall 

They never have before in over 15 years, and, before I got this server started, its mate was serving fine. But if the ufw doesn't work, I'll ask them.

[IL Ka]

Good to know. But does fail2ban require ipset?

No, but having several thousand rules is not convenient, so I prefer ipset  

They never have before in over 15 years, and, before I got this server started, its mate was serving fine. But if the ufw doesn't work, I'll ask them.

I'd start by switching to legacy iptables and running ``iptables -L -v -n``. 

 

[Erwan David]

 good reason would be that thtere is obviously already something on
your server magaing the firewalling. Having 2 different systems will
lead to inconsistency and erratic behiaviour. First thing is to identify
what is putting the rules you showed us. (rules that do not block ports
80 and 443)

[IL Ka]

Do I have to switch all four *legacy *tables?

yes

[Tom Browder]

On Sat, May 28, 2022 at 17:24 IL Ka <kazakev...@gmail.com> wrote:

...

I am not familiar with nft, bit you can switch to iptables using ``update-alternatives``

 

# update-alternatives --set iptables /usr/sbin/iptables-legacy
# update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
# update-alternatives --set arptables /usr/sbin/arptables-legacy
# update-alternatives --set ebtables /usr/sbin/ebtables-legacy

Do I have to switch all four *legacy *tables?

-Tom

[Tom Browder]

On Sun, May 29, 2022 at 09:51 IL Ka <kazakev...@gmail.com> wrote:

Do I have to switch all four *legacy *tables?

yes

When running those, I'm told neither the arptablrs nor the ebtables are registered (not installed). Should I install them?

[IL Ka]

When running those, I'm told neither the arptablrs nor the ebtables are registered (not installed). Should I install them?

No.

So, you now have legacy (classic) iptables, right?

What is the output of ``iptables -L -v -n`` and ``iptables -S`` ?

 

[Tom Browder]

On Sun, May 29, 2022 at 10:33 AM IL Ka <kazakev...@gmail.com> wrote:
>
>
>> When running those, I'm told neither the arptablrs nor the ebtables are registered (not installed). Should I install them?
>
> No.
>
> So, you now have legacy (classic) iptables, right?

Yes.

> What is the output of ``iptables -L -v -n``

Chain INPUT (policy ACCEPT 279 packets, 36670 bytes)
pkts bytes target prot opt in out source
destination
1387 150K f2b-sshd tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination

Chain OUTPUT (policy ACCEPT 260 packets, 35768 bytes)
pkts bytes target prot opt in out source
destination

Chain f2b-sshd (1 references)
pkts bytes target prot opt in out source
destination
22 1768 REJECT all -- * * 43.154.179.253
0.0.0.0/0 reject-with icmp-port-unreachable
1069 126K RETURN all -- * * 0.0.0.0/0
0.0.0.0/0

> and ``iptables -S`` ?

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd

-A f2b-sshd -s 61.177.173.50/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.173.7/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.154.179.253/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN

[IL Ka]

btw, are you able to ping server?

[IL Ka]

> and ``iptables -S`` ?

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N f2b-sshd
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A f2b-sshd -s 61.177.173.50/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 61.177.173.7/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 43.154.179.253/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN

I do not see any rule that returns "no route to host". 

You can use ``tcmpdump`` to see who is answering "no route to host" for your "telnet [ip] 80" session.

I am pretty sure this is not your firewall problem

 

[to...@tuxteam.de]

I may be off, but I think a firewall shouldn't do that [1]. It can
lead to a "connection refused", which amounts to replying with a RST,
which corresponds to the REJECT treatment, and it can just not answer,
which leads to a timeout, corresponding to DROP.

What you are seeing is some router in the middle telling you it
doesn't know which way this x.y.z.w is (with an ICMP "Destination
unreachable"). Of course this can happen at your workstation, but
then it'd be quite probable you can't access x.y.z.w with ssh
either.

Firewalls can be configured to lie [2] in this way, alas. It very
much looks like your provider has a firewall between your rental
host and the rest of the world.

But take all that with a grain of salt or two.
Cheers

[1] and I believe your Linux firewall won't do that by default.
You'd have to tell it so.
[2] Now destination port unreachable would be less of a lie,
no?
--
t

[Tom Browder]

On Sun, May 29, 2022 at 11:39 IL Ka <kazakev...@gmail.com> wrote:

btw, are you able to ping server?

Yes.

[john doe]

It is always better to show the command and the output instead of saying
yes/no! :)

I must say, I can not realy understand how you can ping and not
telnet/access your web server.

--
John Doe

[IL Ka]

I must say, I can not realy understand how you can ping and not
telnet/access your web server.

Some router between OP and his server has something like

-I FORWARD -j REJECT --reject-with icmp-host-unreachable

[Greg Wooledge]

> > > btw, are you able to ping server?
> >
> > Yes.
>
> It is always better to show the command and the output instead of saying
> yes/no! :)

Except it should be abundantly clear by now that you're dealing with
someone who believes that they must hide every single detail from
the ones who would offer help.

Never mind that the details are REQUIRED to diagnose the problem.

What's important is that their WEB SERVER which is by definition supposed
to be AVAILABLE TO THE ENTIRE WORLD must remain secret and hidden from
the people trying to help.

Have fun continuing to try pulling teeth on this.

[Tom Browder]

On Sun, May 29, 2022 at 2:21 PM Greg Wooledge <gr...@wooledge.org> wrote:
>
> > > > btw, are you able to ping server?
> > >
> > > Yes.
> >
> > It is always better to show the command and the output instead of saying
> > yes/no! :)
>
> Except it should be abundantly clear by now that you're dealing with
> someone who believes that they must hide every single detail from
> the ones who would offer help.

I have not intentionally hidden anything, Greg--I just never saw the need for
mentioning it given the dialogue--x.y.z.w is just shorthand. If you
must know the exact IP address, it is 69.30.225.10. (And you could have
asked for it at any time--I don't remember anyone asking for it--but I will
do so the next time I ask for this kind of help again.)

GIven all the advice, I'm leaning towards the popular hypothesis that
my provider has somehow locked out the two ports in question (a first
for them). The machine is now inaccessible, and I have asked them to
reinstall Debian 11 on it and ENSURE that ports 80 and 443 are
accessible from the internet.

Thanks for all the help, and I consider this thread closed.

-Tom

[Greg Wooledge]

On Sun, May 29, 2022 at 03:39:05PM -0500, Tom Browder wrote:
> I have not intentionally hidden anything, Greg--I just never saw the need for
> mentioning it given the dialogue--x.y.z.w is just shorthand. If you
> must know the exact IP address, it is 69.30.225.10.

OK. Now we can actually start helping.

First of all, this is a regular old routable IPv4 address. It's not one
of the non-routables, like 192.168.* or 10.*. This is good. It
eliminates a whole class of problems like "My machine's IP address says
192.168.1.2 but I can't reach it from outside my network", all of which
were still on the table until now.

Second, I cannot ping this IP address, nor can I telnet to port 80 of it.
(Nor port 22.)

I don't get an error, though -- just a hang/timeout.

If you can ping this, or ssh to it, or reach it on ANY port at all,
from the public Internet, then that's a huge red flag pointing to a
firewall that filters incoming connections based on source IP. Such
a firewall could be on the host itself, or on a router which protects
the host.

If you can't do any of those things, then we don't get as much information
out of it. It could simply be the wrong IP address for all we know
at that point. Or it could be a misconfigured firewall, or the machine
could be crashed, or the network cable fell out, or any number of other
issues.

[Tom Browder]

On Sun, May 29, 2022 at 15:55 Greg Wooledge <gr...@wooledge.org> wrote:

...

Thanks, Greg. It looks like my server was blocked from ports 80 and 443 upstream from it (as you and others suspected), so I asked my provider to reinstall the OS and ensure it has public access to ports 80 and 443.

Best regards,

-Tom

[Lee]

On 5/29/22, Greg Wooledge <gr...@wooledge.org> wrote:
> On Sun, May 29, 2022 at 03:39:05PM -0500, Tom Browder wrote:
>> I have not intentionally hidden anything, Greg--I just never saw the need
>> for
>> mentioning it given the dialogue--x.y.z.w is just shorthand. If you
>> must know the exact IP address, it is 69.30.225.10.
>
> OK. Now we can actually start helping.
>
> First of all, this is a regular old routable IPv4 address. It's not one
> of the non-routables, like 192.168.* or 10.*. This is good. It
> eliminates a whole class of problems like "My machine's IP address says
> 192.168.1.2 but I can't reach it from outside my network", all of which
> were still on the table until now.
>
> Second, I cannot ping this IP address, nor can I telnet to port 80 of it.

For whatever it's worth..

Pinging 69.30.225.10 with 32 bytes of data:
Reply from 69.30.225.10: bytes=32 time=43ms TTL=53
Reply from 69.30.225.10: bytes=32 time=42ms TTL=53
Reply from 69.30.225.10: bytes=32 time=43ms TTL=53
Reply from 69.30.225.10: bytes=32 time=42ms TTL=53

I had wireshark running while trying to telnet there and I get a RST ~
45ms after sending the SYN

ssh gives me a login prompt

Lee

[Greg Wooledge]

On Sun, May 29, 2022 at 11:50:44PM +0000, Lee wrote:
> On 5/29/22, Greg Wooledge <gr...@wooledge.org> wrote:
> > Second, I cannot ping this IP address, nor can I telnet to port 80 of it.
>
> For whatever it's worth..
>
> Pinging 69.30.225.10 with 32 bytes of data:
> Reply from 69.30.225.10: bytes=32 time=43ms TTL=53
> Reply from 69.30.225.10: bytes=32 time=42ms TTL=53
> Reply from 69.30.225.10: bytes=32 time=43ms TTL=53
> Reply from 69.30.225.10: bytes=32 time=42ms TTL=53

Yes, it's working from here now, too. Changes definitely happened
on the OP's server's side.

[IL Ka]

ssh gives me a login prompt

Btw, I highly recommend:

* Block SSH access from any IP except one you are going to use to manage this server

* If you have dynamic IP, you can add all your ISP network, or, at least, your country: (list can be downloaded here https://blog.ip2location.com/knowledge-base/how-to-block-ip-addresses-from-a-country-using-ipset/)

* Deny password access and use keys only (use EdDSA, not RSA if possible). Passwords should never be used

* Disable root access

* Get rid of SHA-1 and other weak things: https://sshcheck.com/server/69.30.225.10/

You have your ssh server opened to the whole world and there are zillions of bots trying to guess your password now.

 

[Timothy M Butterworth]

I did a TCPTraceRoute to your server on port 80 it makes it across all hops but says the port is closed on the server.

tcptraceroute 69.30.225.10
Selected device wlo1, address 192.168.105.250, port 38109 for outgoing packets
Tracing the path to 69.30.225.10 on TCP port 80 (http), 30 hops max
1  192.168.105.156  7.422 ms  3.828 ms  3.985 ms
2  17.sub-66-174-63.myvzw.com (66.174.63.17)  340.678 ms  692.027 ms  185.134 ms
3  194.sub-69-83-70.myvzw.com (69.83.70.194)  107.194 ms  596.305 ms  257.465 ms
4  * * *
5  242.sub-69-83-70.myvzw.com (69.83.70.242)  556.143 ms  57.157 ms  47.478 ms
6  * * *
7  * * *
8  * * *
9  153.sub-69-83-66.myvzw.com (69.83.66.153)  184.145 ms  61.027 ms  48.539 ms
10  * * *
11  * * *
12  * be3083.ccr41.dca01.atlas.cogentco.com (154.54.30.53) 445.471 ms  97.201 ms
13  be2891.ccr21.cle04.atlas.cogentco.com (154.54.82.249)  106.103 ms * *
14  * * *
15  * * be2831.ccr21.mci01.atlas.cogentco.com (154.54.42.165) 96.672 ms
16  be2546.rcr01.b073673-0.mci01.atlas.cogentco.com (154.54.30.242)  97.542 ms  89.655 ms *
17  * * *
18  * * *
19  100ge13-1.edge-a.clay.as33387.net (69.30.209.195)  725.149 ms  578.818 ms  414.786 ms
20  * * *
21  * * *
22  * server.pcstar1.com (69.30.225.10) [closed] 379.939 ms  413.809 ms

 

[Charles Kroeger]

> Maybe I should remove all firewall progs and start from zero.

I would suggest you install Shorewall. it is not the pain in the arse that's
been the theme of this thread so far.

[john doe]

If I may, looks like this is over your head and I would suggest you to
do the following:
- Understand what is done on this server (installed pkgs, config ...)
- Start by securing remote access (see this thread on to do that for SSH)
- Get all of your set up working offline/locally
- Document yourself on how to do what you want (when exposing services
publically you can not guess/try)


In other words, familiorise yourself with what you have.

--
John Doe

[Curt]

On 2022-05-29, Greg Wooledge <gr...@wooledge.org> wrote:
>
> Second, I cannot ping this IP address, nor can I telnet to port 80 of it.
> (Nor port 22.)
>

That's strange; I can ping it (I'm not in Kansas anymore):

curty@einstein:~$ ping 69.30.225.10
PING 69.30.225.10 (69.30.225.10) 56(84) bytes of data.
64 bytes from 69.30.225.10: icmp_seq=1 ttl=51 time=110 ms
64 bytes from 69.30.225.10: icmp_seq=2 ttl=51 time=109 ms
64 bytes from 69.30.225.10: icmp_seq=3 ttl=51 time=110 ms
64 bytes from 69.30.225.10: icmp_seq=4 ttl=51 time=110 ms
64 bytes from 69.30.225.10: icmp_seq=5 ttl=51 time=109 ms
64 bytes from 69.30.225.10: icmp_seq=6 ttl=51 time=109 ms
^C
--- 69.30.225.10 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 109.920/110.172/110.613/0.511 ms

[Tom Browder]

On Mon, May 30, 2022 at 02:13 john doe <johndo...@mail.com> wrote:

On 5/30/2022 12:26 AM, Tom Browder wrote:
> On Sun, May 29, 2022 at 15:55 Greg Wooledge <gr...@wooledge.org> wrote:

No worries. All those responses about the subject IP now are the norm for a bare-iron server ready for use by a customer, yours truly. It is the same server I messed up the firewall with and locked myself out of. The OS has been reinstalled and is ready for me to use again.

If all is set as expected, I should be able to get http and https working on it.

And I will certainly try to take care of most of the security concerns expressed here.

For those of you with forensic curiosity so recently demonstrated, the new server we are discussing is to replace mine currently operating at IP 173.208.182.170. It has been online for over two years. I believe it is locked down pretty well.

Some websites there are:

    novco1968tbs.com       # my Marine brother's TBS  class

    usafa-1965.org             # my college class

    moody67a.org               # my pilot training class

    nwflug.org

    computertechnwf.org

The first three sites have entries very appropriate for US Memorial Day: noting men who sacrificed their lives fighting for us.

-Tom

[Greg Wooledge]

On Mon, May 30, 2022 at 07:13:54AM -0500, Tom Browder wrote:
> No worries. All those responses about the subject IP now are the norm for a
> bare-iron server ready for use by a customer, yours truly. It is the same
> server I messed up the firewall with and locked myself out of. The OS has
> been reinstalled and is ready for me to use again.

Why are you installing a firewall on a web server *at all*?

The only thing you need to secure is your ssh access, and that's
usually done in the /etc/ssh/sshd_config file, either by setting
up key access only, or by restricting the source IPs who can connect.

The web service is supposed to be open to the whole world. That's
why it's called the World Wide Web.

Unless this machine is more than just a web server...?

[IL Ka]

IMHO: It is better to have a firewall and block (policy -- drop) INPUT and FORWARD by default.

And open only ports that must be opened.

This will help if you install some software that listens for 0.0.0.0 by accident 

[Tom Browder]

On Mon, May 30, 2022 at 08:42 Greg Wooledge <gr...@wooledge.org> wrote:

.. 

Unless this machine is more than just a web server...?

It does serve other purposes.

[Tom Browder]

On Mon, May 30, 2022 at 09:03 IL Ka <kazakev...@gmail.com> wrote:

IMHO: It is better to have a firewall and block (policy -- drop) INPUT and FORWARD by default.

And open only ports that must be opened.

This will help if you install some software that listens for 0.0.0.0 by accident 

From my limited research, that seems to be the prevailing view.

-Tom

[Timothy M Butterworth]

If you have firewalld try running:

`firewall-cmd --permanent --add-service=http`

`firewall-cmd --reload`

 

[Edwin Zimmerman]

On 5/30/22 09:41, Greg Wooledge wrote:
> On Mon, May 30, 2022 at 07:13:54AM -0500, Tom Browder wrote:
>> No worries. All those responses about the subject IP now are the norm for a
>> bare-iron server ready for use by a customer, yours truly. It is the same
>> server I messed up the firewall with and locked myself out of. The OS has
>> been reinstalled and is ready for me to use again.
> Why are you installing a firewall on a web server *at all*?

Because it prevents accidental port exposure.  It's not uncommon to be running some other service other than the web server, and accidental configurations happen all the time.  A firewall is a simple security measure to contain such problems.

[Tom Browder]

On Mon, May 30, 2022 at 19:46 Edwin Zimmerman <ed...@plainemail.net> wrote:

On 5/30/22 09:41, Greg Wooledge wrote:
> On Mon, May 30, 2022 at 07:13:54AM -0500, Tom Browder wrote:
>> No worries. All those responses about the subject IP now are the norm for a
>> bare-iron server ready for use by a customer, yours truly. It is the same
>> server I messed up the firewall with and locked myself out of. The OS has
>> been reinstalled and is ready for me to use again.

On that note, for my next try with the server, I will definitely use UFW with the legacy uptables that was suggested.

But a question: it is clear that it must be enabled to go into effect, but when does it actually start operating? Does it do so then, or does it take a reboot?

-Tom

[john doe]

Apparently, if you 'enable' 'ufw', it will start and be enabled at boot.

According to (1), ufw should work with nftables, I did not follow the
reasoning on why to use iptables but only if you have issues use legacy
iptables.

1) https://wiki.archlinux.org/title/Uncomplicated_Firewall

--
John Doe

[Tom Browder]

On Wed, Jun 1, 2022 at 11:21 john doe <johndo...@mail.com> wrote:

> when does it actually start operating? Does it do so then, or does it take

> a reboot?

Apparently, if you 'enable' 'ufw', it will start and be enabled at boot.

Good, thanks.

According to (1), ufw should work with nftables, I did not follow the
reasoning on why to use iptables but only if you have issues use legacy
iptables.

Well, the guidance I got was varying. In my mind, Il Ka seemed to be the most well-informed and understanding of my specific needs, and I went with his recommendations. He was upfront about why he stayed with iptables, and I also favor that view. Based on my experience upgrading Debian since version 4, I know I don't like to jump on new stuff right away, but expect to have to eventually.

-Tom