Re: Debian desktop environment

[Keith Bainbridge]

On 24/5/22 23:23, Brian wrote:

Hi,

After my surrender to Jessie I've thought of moving on with Stretch.

Careful! If you go on like this you will end up installing bullseye :).
  



Bookworm?

SID?

--
All the best

Keith Bainbridge

keithrbaugro...@gmail.com

Re: Debian desktop environment

[Thomas Schmitt]

Hi,

Brian wrote:
> > Careful! If you go on like this you will end up installing bullseye :).

Keith Bainbridge wrote:
> Bookworm?
> SID?

In any case: Not Testing !

Currently a zillion of packages get marked for autoremovial from Testing
because of
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011268


Have a nice day :)

Thomas

Re: Debian desktop environment

[Cindy Sue Causey]

On 5/28/22, Thomas Schmitt  wrote:
> Hi,
>
> Brian wrote:
>> > Careful! If you go on like this you will end up installing bullseye :).
>
> Keith Bainbridge wrote:
>> Bookworm?
>> SID?
>
> In any case: Not Testing !
>
> Currently a zillion of packages get marked for autoremovial from Testing
> because of
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011268


Yeehaw to that! About 3 mornings ago, I woke up to 71 emails
containing the "marked for autoremoval" advisement. All appear to be
tied to accessibility (A11Y). Have mercy, it's all the bigger chat
topics: edbrowse, espeakup, fenrir, *orca*. I've NEVER seen that
quantity before and especially not those packages, but that's likely
just because of which lists I follow.

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: Debian desktop environment

[Kenneth Parker]

On Sat, May 28, 2022, 11:08 AM Cindy Sue Causey 
wrote:

> On 5/28/22, Thomas Schmitt  wrote:
> > Hi,
> >
> > Brian wrote:
> >> > Careful! If you go on like this you will end up installing bullseye
> :).
> >
> > Keith Bainbridge wrote:
> >> Bookworm?
> >> SID?
> >
> > In any case: Not Testing !
> >
> > Currently a zillion of packages get marked for autoremovial from Testing
> > because of
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011268
>
>
> Yeehaw to that! About 3 mornings ago, I woke up to 71 emails
> containing the "marked for autoremoval" advisement. All appear to be
> tied to accessibility (A11Y). Have mercy, it's all the bigger chat
> topics: edbrowse, espeakup, fenrir, *orca*. I've NEVER seen that
> quantity before and especially not those packages, but that's likely
> just because of which lists I follow.
>

So *that* is what all those emails were about.

I had to use Bullseye as Testing for, over a month, due to the level of the
qemu package (as Buster's was lower than Mint).  I am *sure* glad I didn't
try that with Bookworm!  (Yes, I had a major issue with Mint 20 and won't
use Mint anymore).

>
> Cindy :)
> --
> Talking Rock, Pickens County, Georgia, USA
> * runs with birdseed *
>

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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[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-

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[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

grep: show matching line from pattern file

[Jim Popovitch]

Not exactly Debian specific, but hoping that someone here can help.

I have a file of regex patterns and I use grep like so:

   ~$ grep -f patterns.txt /var/log/syslog 

What I'd like to get is a listing of all lines, specifically the line
numbers of the regexps in patterns.txt, that match entries in
/var/log/syslog.   Is there a way to do this?

-Jim P.

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[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)

Re: grep: show matching line from pattern file

[The Wanderer]

On 2022-05-28 at 15:40, Jim Popovitch wrote:

> Not exactly Debian specific, but hoping that someone here can help.
> 
> I have a file of regex patterns and I use grep like so:
> 
>~$ grep -f patterns.txt /var/log/syslog 
> 
> What I'd like to get is a listing of all lines, specifically the line
> numbers of the regexps in patterns.txt, that match entries in
> /var/log/syslog.   Is there a way to do this?

I don't know of a standardized way to do that (if anyone else wants to
suggest one, I'm open to learn), but of course it *can* be done, via
scripting. Off the top of my head, I came up with the following

for line in $(seq 1 $(wc -l patterns.txt | cut -d ' ' -f 1)) ; do
  if grep $(head -n $line patterns.txt | tail -n 1) /var/log/syslog >
/dev/null ; then
echo $line ;
  fi
done

I just tested that on my own system, with a different file (since I'm
not root right now) and a couple of exact-string patterns found by
examining that file, and it seems to work as intended. YMMV.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

On Sat, May 28, 2022 at 14: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.


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

Re: grep: show matching line from pattern file

[Greg Wooledge]

On Sat, May 28, 2022 at 04:02:39PM -0400, The Wanderer wrote:
> On 2022-05-28 at 15:40, Jim Popovitch wrote:
> > I have a file of regex patterns and I use grep like so:
> > 
> >~$ grep -f patterns.txt /var/log/syslog 
> > 
> > What I'd like to get is a listing of all lines, specifically the line
> > numbers of the regexps in patterns.txt, that match entries in
> > /var/log/syslog.   Is there a way to do this?
> 
> I don't know of a standardized way to do that (if anyone else wants to
> suggest one, I'm open to learn), but of course it *can* be done, via
> scripting. Off the top of my head, I came up with the following
> 
> for line in $(seq 1 $(wc -l patterns.txt | cut -d ' ' -f 1)) ; do
>   if grep $(head -n $line patterns.txt | tail -n 1) /var/log/syslog >
> /dev/null ; then
> echo $line ;
>   fi
> done

The quoting here is... completely absent (and that's extremely bad), but
also importantly, one would ideally like to avoid running grep a thousand
times, especially if the target logfile is large.

I believe this is the kind of job for which perl is well-suited.  I'm not
great at perl, but I'll give it a shot.

Here's a version with some extra information as output, so I can verify
that it's doing something reasonably close to correct:


#!/usr/bin/perl
use strict; use warnings;

my @patlist;
open PATS, ");
close PATS;

while (<>) {
chomp;
for (my $i = 0; $i <= $#patlist; $i++) {
print "$i|$patlist[$i]|$_\n" if /$patlist[$i]/;
}
}


Now, to test it, we need a patterns.txt file:


unicorn:~$ cat patterns.txt 
PATH
HOME|~
a...e


And an input (log) file:


unicorn:~$ cat file
zebra
Home, home on the range.
Oops, I meant HOME on the range.

applesauce


And here's what it does:


unicorn:~$ ./foo file
1|HOME|~|Oops, I meant HOME on the range.
2|a...e|applesauce


Pattern numbers 1 and 2 (the second and third, since it starts at 0) were
matched, so we have a line for each of those.

If that's kinda what you wanted, then you can adjust this to do precisely
what you wanted.  It shouldn't take a lot of work, I hope.  Well, I guess
that depends on what you really want.

Bash is not well-suited to this task, and even if we were to take The
Wanderer's script and fix all the issues in it, it would still be a
vastly inferior solution.  Some tools are just not meant for some jobs.

Re: grep: show matching line from pattern file

[The Wanderer]

On 2022-05-28 at 17:11, Greg Wooledge wrote:

> On Sat, May 28, 2022 at 04:02:39PM -0400, The Wanderer wrote:
>
>> On 2022-05-28 at 15:40, Jim Popovitch wrote:
>> > I have a file of regex patterns and I use grep like so:
>> > 
>> >~$ grep -f patterns.txt /var/log/syslog 
>> > 
>> > What I'd like to get is a listing of all lines, specifically the line
>> > numbers of the regexps in patterns.txt, that match entries in
>> > /var/log/syslog.   Is there a way to do this?
>> 
>> I don't know of a standardized way to do that (if anyone else wants to
>> suggest one, I'm open to learn), but of course it *can* be done, via
>> scripting. Off the top of my head, I came up with the following
>> 
>> for line in $(seq 1 $(wc -l patterns.txt | cut -d ' ' -f 1)) ; do
>>   if grep $(head -n $line patterns.txt | tail -n 1) /var/log/syslog >
>> /dev/null ; then
>> echo $line ;
>>   fi
>> done
> 
> The quoting here is... completely absent (and that's extremely bad), but
> also importantly, one would ideally like to avoid running grep a thousand
> times, especially if the target logfile is large.

A brother of mine has schooled me on several things I did wrong here
already, and I am now going over my long-tail stockpile of scripts with
shellcheck, seeing what I can learn. (I normally do quote variables, but
for some reason it slipped my mind this time until after I'd already hit
Send. Some of these are known-safe values which won't need quoting, but
others aren't, so the principle remains valid to cite.)

This wasn't especially intended as a great solution, in any case; it
started out as me trying to write shell-like pseudocode, but then I
couldn't see any obvious reason why it wouldn't work, and when I tried
it out I only needed a few tweaks before it did. There's a *reason* I
had the "YMMV" on that message.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

On Sat, May 28, 2022 at 17:08 Dan Ritter  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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Dan Ritter]

Tom Browder wrote: 
> On Sat, May 28, 2022 at 14: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.
> 
> 
> 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.

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-

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[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
>

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

On Sat, May 28, 2022 at 17:30 IL Ka  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.

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

On Sat, May 28, 2022 at 17:51 Tom Browder  wrote:

> On Sat, May 28, 2022 at 17:30 IL Ka  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.
>

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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Timothy M Butterworth]

On Sat, May 28, 2022 at 7:52 PM Tom Browder  wrote:

>
>
> On Sat, May 28, 2022 at 17:51 Tom Browder  wrote:
>
>> On Sat, May 28, 2022 at 17:30 IL Ka  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`




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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

On Sat, May 28, 2022 at 19:01 Greg Wooledge  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.

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

On Sat, May 28, 2022 at 19:10 Timothy M Butterworth <
timothy.m.butterwo...@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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[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

Re: Firewall blocking my new Debian 11 server ports 80 and 443

[Tom Browder]

On Sat, May 28, 2022 at 20:06 IL Ka  wrote:

>
>> $ 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
>

Thanks, I will try that tomorrow.

-Tom