Re: nftables firewall question: matching udp in ipv6

[Michel Verdier]

On 2024-01-12, Ralph Aichinger wrote:

> I "only" have to find out what mechanism adds the lower, en2 default
> route within a few minutes, once I delete it. I ran "radvdump", but
> that only dumped the correct announcement my provider sends for the
> net over the PPPoE connection. Hm.
>
> Thanks everybody, of course hints on how to find out what's adding
> default routes would also be appreciated ;)

It depends on how you setup your network. If you only use ifupdown (and
it is better for a server) look in /etc/network/interfaces and
/etc/network/interfaces.d/* for "gateway" stances

Re: nftables firewall question: matching udp in ipv6

[Ralph Aichinger]

On Fri, Jan 12, 2024 at 07:35:14PM +0100, Michel Verdier wrote:
>   meta l4proto udp log level info prefix "udp" accept

Thanks for that, and thanks to Michael Kjörling, your replies really
helped.

I found log lines similar to:

2024-01-12T19:51:32.999346+01:00 pi kernel: [3401524.305759] 
ralphfilterudpIN=en2 OUT=en2 MAC=08:00:1e:02:00:02:6c:cf:39:00:42:f4:86:dd 
SRC=2a02:0ab8:redacted DST=2a00:63c1:redacted LEN=96 TC=0 HOPLIMIT=63 
FLOWLBL=279176 PROTO=UDP SPT=40840 DPT=123 LEN=56 

with interestingly IN and OUT interfaces the same en2 (=dmz). And to my 
surprise, I
found a double IPv6 default route:

default via fe80::e25f:b9ff:fe1e:a100 dev ppp0 proto ra metric 1024 expires 
1791sec hoplimit 64 pref medium
default via fe80::a00:1eff:fe01:0 dev en2 proto ra metric 1024 expires 1588sec 
hoplimit 64 pref medium

Now I don't understand why pings/ICMP and tcp traffic seem to decide for
the correct route via ppp0 and only udp sems to prefer the one via en2,
but when I delete it, everything works. So while nftables might still 
contain some problematic stuff, at the core of my problem seems to be
routing.

I "only" have to find out what mechanism adds the lower, en2 default
route within a few minutes, once I delete it. I ran "radvdump", but
that only dumped the correct announcement my provider sends for the
net over the PPPoE connection. Hm.

Thanks everybody, of course hints on how to find out what's adding
default routes would also be appreciated ;)

Ralph

Re: nftables firewall question: matching udp in ipv6

[Michel Verdier]

On 2024-01-12, Ralph Aichinger wrote:

> If I insert the following rule at the bottom, everything starts to
> work:
>
> meta l4proto  udp  accept

Add log to see what would be dropped:

  meta l4proto udp log level info prefix "udp" accept

Provide "nft list ruleset" to better see what nft understands.

I suppose your udp is not "established" to not be accepted. Perhaps
something in your nat that breaks "established" ?

Re: nftables firewall question: matching udp in ipv6

[Ralph Aichinger]

On Fri, Jan 12, 2024 at 05:26:57PM +, Michael Kjörling wrote:
> My suggestion would be to insert a "udp log" rule. (Pretty sure you
> only need "udp", not "meta l4proto udp".)
  
Thanks,  I will try that. Yes "meta l4proto udp" might be cargo 
cult configuration ;)

> That will give you a firehose of information which will include ports,
> interfaces and other relevant information. You can then narrow it down
> until it logs the traffic you want to accept, at which point you can
> change the "log" action into an "accept" action.
> 
> Note that forwarding and filtering can interact in non-intuitive ways.
> You may need to add corresponding log rules to each relevant chain,
> maybe with a prefix to tell them apart.
  
Thanks a lot!

Ralph

Re: nftables firewall question: matching udp in ipv6

[Michael Kjörling]

On 12 Jan 2024 16:19 +0100, from r...@h5.or.at (Ralph Aichinger):
> If I insert the following rule at the bottom, everything starts to
> work:
> 
> meta l4proto  udp  accept
> 
> but I don't know how to limit this over broad rule (so it does not
> forward UDP to the internal network on en0, which I do not want). 

My suggestion would be to insert a "udp log" rule. (Pretty sure you
only need "udp", not "meta l4proto udp".)

That will give you a firehose of information which will include ports,
interfaces and other relevant information. You can then narrow it down
until it logs the traffic you want to accept, at which point you can
change the "log" action into an "accept" action.

Note that forwarding and filtering can interact in non-intuitive ways.
You may need to add corresponding log rules to each relevant chain,
maybe with a prefix to tell them apart.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: nftables firewall question: matching udp in ipv6

[Ralph Aichinger]

On Fri, Jan 12, 2024 at 03:52:46PM +, Tom Furie wrote:
> other input/output rules that are interfering, but since you've abridged
> your ruleset we have no way of knowing.

Sorry, wanted to include the full rulest an forgot. I've still have left
off the "table ip nat" and "table ip filter" chains, I hope this is OK.


#!/usr/sbin/nft -f

flush ruleset

table ip nat {
...
}

table ip filter {
...
}

table ip6 filter {
chain input {
type filter hook input priority 0; policy drop;
ct state invalid counter drop comment "early drop of invalid 
packets"
ct state {established, related} counter accept comment "accept 
all connections related to connections made by us"
iif lo accept comment "accept loopback"
iif != lo ip6 daddr ::1/128 counter drop comment "drop 
connections to loopback not coming from loopback"
meta l4proto ipv6-icmp counter accept comment "accept all ICMP 
types"
tcp dport 22 counter accept comment "accept SSH"
tcp dport 25 counter accept comment "accept SMTP"
tcp dport 53 counter accept comment "accept DNS"
udp dport 53 counter accept comment "accept DNS"
tcp dport 80 counter accept comment "accept HTTP"
tcp dport 443 counter accept comment "accept HTTPS"
counter comment "count dropped packets"
}


chain forward {
type filter hook forward priority 0; policy drop;

iifname ppp0 oifname en0 ct state established,related accept
iifname en0 oifname ppp0 accept

iifname en2 oifname ppp0 accept
iifname ppp0 oifname en2 accept

iifname en0 oifname en2 accept
iifname en2 oifname en0 ct state established,related accept

meta l4proto ipv6-icmp accept

}
}

Re: nftables firewall question: matching udp in ipv6

[Ralph Aichinger]

On Fri, Jan 12, 2024 at 03:52:46PM +, Tom Furie wrote:
> Where is the DNS server the dmz host is resolving against? In your dmz,
> your internal network, on the firewall machine, outside? You may have
> other input/output rules that are interfering, but since you've abridged
> your ruleset we have no way of knowing.

 
I've tried this with the public Gooogle DNS 2001:4860:4860::. The
behaviour seems consistent: If I try to resolve names over UDP with the
first ruleset I posted, it fails. If I try DNS over TCP (by using 
nslookup with the "-vc" option, it works.

Thanks,
Ralph

Re: nftables firewall question: matching udp in ipv6

[Tom Furie]

Ralph Aichinger  writes:

> I am currently fighting with the following problem: I've got a system
> that has 3 relevant interfaces: ppp0, en0 and en2, for external,
> internal and dmz respectively. 
>
> The dmz is IPv6 only, a homelab testbed more or less.
>
> I've got the follwing rules in /etc/nftables.conf for ipv6 (i am
> abreviating the chain input, because i am only fighting with
> forwarding):
>
> table ip6 filter {
> chain input {
> ...
> }
>
> 
> chain forward {
>   type filter hook forward priority 0; policy drop;
>
>   iifname ppp0 oifname en0 ct state established,related accept
>   iifname en0 oifname ppp0 accept
> 
>   iifname en2 oifname ppp0 accept
>   iifname ppp0 oifname en2 accept
>
>   iifname en0 oifname en2 accept
>   iifname en2 oifname en0 ct state established,related accept
>
>   meta l4proto ipv6-icmp accept
>  
>
> }
> }
>
> What does not work, and this puzzles me, is that UDP does not work. 
> E.g. if I lookup a DNS name in my dmz (connected to en2), I see no
> udp packets if i start tcpdump on the external interface ppp0. I see
> them entering on en2. 
>
Where is the DNS server the dmz host is resolving against? In your dmz,
your internal network, on the firewall machine, outside? You may have
other input/output rules that are interfering, but since you've abridged
your ruleset we have no way of knowing.

nftables firewall question: matching udp in ipv6

[Ralph Aichinger]

Hello!

I am currently fighting with the following problem: I've got a system
that has 3 relevant interfaces: ppp0, en0 and en2, for external,
internal and dmz respectively. 

The dmz is IPv6 only, a homelab testbed more or less.

I've got the follwing rules in /etc/nftables.conf for ipv6 (i am
abreviating the chain input, because i am only fighting with
forwarding):

table ip6 filter {
chain input {
...
}


chain forward {
  type filter hook forward priority 0; policy drop;

  iifname ppp0 oifname en0 ct state established,related accept
  iifname en0 oifname ppp0 accept

  iifname en2 oifname ppp0 accept
  iifname ppp0 oifname en2 accept

  iifname en0 oifname en2 accept
  iifname en2 oifname en0 ct state established,related accept

  meta l4proto ipv6-icmp accept
 

}
}

This "almost" works: I can do everything I want from my internal
network (connected to en0) towards the outside, and tcp connections
from and to the dmz also work. Ping works everywhere.

What does not work, and this puzzles me, is that UDP does not work. 
E.g. if I lookup a DNS name in my dmz (connected to en2), I see no
udp packets if i start tcpdump on the external interface ppp0. I see
them entering on en2. 

Why does UDP bevave differently from TCP here? Is this an nftables or
ipv6 specific gotcha?

If I insert the following rule at the bottom, everything starts to
work:

meta l4proto  udp  accept

but I don't know how to limit this over broad rule (so it does not
forward UDP to the internal network on en0, which I do not want). 
trying e.g. 

iifname en2 oifname ppp0 meta l4proto  udp  accept
iifname ppp0 oifname en0 meta l4proto  udp  accept

did not work either, ad behaved like my initial setup described on top.

Any hints for me?
TIA
Ralph 

Re: Trou dans un firewall (iptables nftable)

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 03/07/2023 à 15:12, BERTRAND Joël a écrit :
>> NoSpam a écrit :
>>> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
>>> nat et filter
>> D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
> Tout comme iptables et tcpdump, les paquets sont capturés dès leur
> arrivée. sngrep sait lire du pcap. Si tu regardes les trames INVITE tu
> ne devrais voir aucune réponse de ton asterisk

Effectivement, il n'y a aucune réponse.

Merci pour tout,

JB

Re: Trou dans un firewall (iptables nftable)

[NoSpam]

Le 03/07/2023 à 15:12, BERTRAND Joël a écrit :

NoSpam a écrit :

Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
nat et filter

D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?
Tout comme iptables et tcpdump, les paquets sont capturés dès leur 
arrivée. sngrep sait lire du pcap. Si tu regardes les trames INVITE tu 
ne devrais voir aucune réponse de ton asterisk

Re: Trou dans un firewall (iptables nftable)

[BERTRAND Joël]

NoSpam a écrit :
> Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table
> nat et filter

D'accord. Mais dans ce cas, pourquoi sngrep les intercepte ?

JB

Re: Trou dans un firewall (iptables nftable)

[NoSpam]

Ils n'arrivent jamais plus loin que mangle INPUT qui est avant la table 
nat et filter


Le 03/07/2023 à 15:00, BERTRAND Joël a écrit :

Thomas Trupel a écrit :

C'est un comportement normal à mes yeux.

L'ajout d'une règle avec la target TRACE devrait te confirmer que les
paquets sont bloqués par le firewall.

J'obtiens ceci :

2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE:
raw:PREROUTING:policy:2 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
2023-07-03T14:37:45.868494+02:00 rayleigh kernel: [705875.039009] TRACE:
mangle:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
2023-07-03T14:37:45.868497+02:00 rayleigh kernel: [705875.039019] TRACE:
nat:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
2023-07-03T14:37:45.868498+02:00 rayleigh kernel: [705875.039035] TRACE:
mangle:INPUT:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
raw:PREROUTING:policy:2 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:51:17.795018+02:00 rayleigh kernel: [706686.983258] TRACE:
mangle:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:51:17.795021+02:00 rayleigh kernel: [706686.983268] TRACE:
nat:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:51:17.795022+02:00 rayleigh kernel: [706686.983282] TRACE:
mangle:INPUT:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:56:40.474426+02:00 rayleigh kernel: [707009.669233] TRACE:
raw:PREROUTING:policy:2 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)
2023-07-03T14:56:40.474447+02:00 rayleigh kernel: [707009.669262] TRACE:
mangle:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)
2023-07-03T14:56:40.474452+02:00 rayleigh kernel: [707009.669274] TRACE:
nat:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)
2023-07-03T14:56:40.474454+02:00 rayleigh kernel: [707009.669289] TRACE:
mangle:INPUT:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)

Où voit-on que ces paquets sont bloqués ?

Bien cordialement,

JKB

Re: Trou dans un firewall (iptables nftable)

[BERTRAND Joël]

Thomas Trupel a écrit :
> C'est un comportement normal à mes yeux.
> 
> L'ajout d'une règle avec la target TRACE devrait te confirmer que les
> paquets sont bloqués par le firewall.

J'obtiens ceci :

2023-07-03T14:37:45.868470+02:00 rayleigh kernel: [705875.038988] TRACE:
raw:PREROUTING:policy:2 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
2023-07-03T14:37:45.868494+02:00 rayleigh kernel: [705875.039009] TRACE:
mangle:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
2023-07-03T14:37:45.868497+02:00 rayleigh kernel: [705875.039019] TRACE:
nat:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
2023-07-03T14:37:45.868498+02:00 rayleigh kernel: [705875.039035] TRACE:
mangle:INPUT:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=109.248.149.209
DST=192.168.15.18 LEN=442 TOS=0x00 PREC=0x00 TTL=45 ID=10988 DF
PROTO=UDP SPT=5256 DPT=5060 LEN=422
raw:PREROUTING:policy:2 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:51:17.795018+02:00 rayleigh kernel: [706686.983258] TRACE:
mangle:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:51:17.795021+02:00 rayleigh kernel: [706686.983268] TRACE:
nat:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:51:17.795022+02:00 rayleigh kernel: [706686.983282] TRACE:
mangle:INPUT:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=94.102.61.29
DST=192.168.15.18 LEN=279 TOS=0x00 PREC=0x00 TTL=239 ID=54321 PROTO=UDP
SPT=38996 DPT=5060 LEN=259
2023-07-03T14:56:40.474426+02:00 rayleigh kernel: [707009.669233] TRACE:
raw:PREROUTING:policy:2 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)
2023-07-03T14:56:40.474447+02:00 rayleigh kernel: [707009.669262] TRACE:
mangle:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)
2023-07-03T14:56:40.474452+02:00 rayleigh kernel: [707009.669274] TRACE:
nat:PREROUTING:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)
2023-07-03T14:56:40.474454+02:00 rayleigh kernel: [707009.669289] TRACE:
mangle:INPUT:policy:1 IN=wan0 OUT=
MAC=50:46:5d:72:ef:a2:60:a4:b7:73:c9:26:08:00 SRC=45.155.91.23
DST=192.168.15.18 LEN=44 TOS=0x00 PREC=0x00 TTL=236 ID=29434 PROTO=TCP
SPT=47506 DPT=5060 SEQ=68748134 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
OPT (020405A0)

Où voit-on que ces paquets sont bloqués ?

Bien cordialement,

JKB

Re: Trou dans un firewall (iptables nftable)

[BERTRAND Joël]

Thomas Trupel a écrit :
> C'est un comportement normal à mes yeux.
> 
> L'ajout d'une règle avec la target TRACE devrait te confirmer que les
> paquets sont bloqués par le firewall.

Dans le cas de SIP, ils sont tout de même récupérés par sngrep :

[ ] 359  INVITE 100@1.1.1.1   100@1.1.1.1
1 64.31.63.27:5166   192.168.15.18:5060 CALL SETUP

donc pas si bloqués que cela ;-)

Bien cordialement,

JKB

Re: Trou dans un firewall (iptables nftable)

[Thomas Trupel]

C'est un comportement normal à mes yeux.

L'ajout d'une règle avec la target TRACE devrait te confirmer que les 
paquets sont bloqués par le firewall.


|Cordialement, Thomas|


On 7/3/23 14:14, BERTRAND Joël wrote:

C'est même pire que ça !

Si je fais un nmap depuis l'extérieur sur le serveur en question,
j'obtiens bien :

legendre# nmap 192.168.15.18
Starting Nmap 7.93 (https://nmap.org  ) at 2023-07-03 14:09 CEST
Nmap scan report for 192.168.15.18
Host is up (0.00078s latency).
Not shown: 987 filtered tcp ports (no-response)
PORT STATE  SERVICE
22/tcp   open   ssh
25/tcp   open   smtp
53/tcp   open   domain
80/tcp   open   http
443/tcp  open   https
465/tcp  closed smtps
587/tcp  open   submission
993/tcp  open   imaps
995/tcp  open   pop3s
2401/tcp closed cvspserver
4443/tcp closed pharos
5222/tcp open   xmpp-client
9418/tcp open   git
MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds
legendre#

ce qui semble correspondre aux ports effectivement ouverts. Mais un
tcpdump sur l'interface publique de la machine testée voit bien passer
tous les paquets (pas seulement ceux correspondant ax ports ouverts).

Idem en UDP :
legendre# nmap -sU 192.168.15.18
Starting Nmap 7.93 (https://nmap.org  ) at 2023-07-03 14:11 CEST
Nmap scan report for 192.168.15.18
Host is up (0.00053s latency).
Not shown: 997 open|filtered udp ports (no-response)
PORT  STATE  SERVICE
53/udpopen   domain
123/udp   open   ntp
1/udp closed ndmp
MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds
legendre#

Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par
ailleurs, ça n'explique pas que des paquets à destination d'un port
fermé aboutissent bien à mon serveur asterisk...

Bien cordialement,

JKB

Re: Trou dans un firewall (iptables nftable)

[BERTRAND Joël]

C'est même pire que ça !

Si je fais un nmap depuis l'extérieur sur le serveur en question,
j'obtiens bien :

legendre# nmap 192.168.15.18
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:09 CEST
Nmap scan report for 192.168.15.18
Host is up (0.00078s latency).
Not shown: 987 filtered tcp ports (no-response)
PORT STATE  SERVICE
22/tcp   open   ssh
25/tcp   open   smtp
53/tcp   open   domain
80/tcp   open   http
443/tcp  open   https
465/tcp  closed smtps
587/tcp  open   submission
993/tcp  open   imaps
995/tcp  open   pop3s
2401/tcp closed cvspserver
4443/tcp closed pharos
5222/tcp open   xmpp-client
9418/tcp open   git
MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 5.01 seconds
legendre#

ce qui semble correspondre aux ports effectivement ouverts. Mais un
tcpdump sur l'interface publique de la machine testée voit bien passer
tous les paquets (pas seulement ceux correspondant ax ports ouverts).

Idem en UDP :
legendre# nmap -sU 192.168.15.18
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-03 14:11 CEST
Nmap scan report for 192.168.15.18
Host is up (0.00053s latency).
Not shown: 997 open|filtered udp ports (no-response)
PORT  STATE  SERVICE
53/udpopen   domain
123/udp   open   ntp
1/udp closed ndmp
MAC Address: 50:46:5D:72:EF:A2 (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 5.81 seconds
legendre#

Lorsque j'utilisais iptables-legacy, je n'ai jamais observé cela. Par
ailleurs, ça n'explique pas que des paquets à destination d'un port
fermé aboutissent bien à mon serveur asterisk...

Bien cordialement,

JKB

Re: Trou dans un firewall (iptables nftable)

[Thomas Trupel]

Bonjour Joël,

As-tu essayé d'approfondir l'analyse avec la target TRACE ?

|iptables -t raw -A PREROUTING -p udp --dport 5060 -j TRACE Par 
ailleurs, tcpdump semble indiquer que le serveur reçoit un paquet sur le 
port TCP/5060 et non UDP/5060. Cordialement, Thomas |


On 7/3/23 12:41, BERTRAND Joël wrote:

Bonjour à tous,

Je suis en train de configurer (péniblement) un serveur asterisk qui
est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce
serveur, protégé par un firewall iptables et fail2ban. Il s'agit
d'iptables et non d'iptables-legacy.

Cette machine est connectée à deux réseaux : wan0 d'un côté et lan0 de
l'autre.

Ce qui m'inquiète :

Root rayleigh:[/etc/asterisk] > tcpdump -i wan0 -p port 5060
...
12:26:54.145136 IP patient.census.internet-measurement.com.38253 >
rayleigh.systella.fr.sip: Flags [S], seq 3922597779, win 14600, options
[mss 1440], length 0

Là, je ne saisis pas puisque j'ai dans le fichier
/var/lib/iptables/active :

*filter
:INPUT DROP [28:3300]
:FORWARD DROP [0:0]
:OUTPUT DROP [27:3120]
[0:0] -A INPUT -i lo -j ACCEPT
[0:0] -A INPUT -i lan0 -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssh -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport smtp -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport domain -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport domain -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport http -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport ntp -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport https -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssmtp -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport submission -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport imaps -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport pop3s -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport openvpn -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport openvpn -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport cvspserver -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport jabber-client -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport git -j ACCEPT
[0:0] -A INPUT -i wan0 -p icmp -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport 1 -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport 4443 -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp -s 37.97.65.0/24 -j ACCEPT
[0:0] -A INPUT -i wan0 -s ns6-axfr.gandi.net -j ACCEPT
[0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -m state --state INVALID -j DROP
[0:0] -A OUTPUT -o lo -j ACCEPT
[0:0] -A OUTPUT -o lan0 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ftp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ssh -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport telnet -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport smtp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport whois -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport domain -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport domain -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport gopher -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport nntp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport ntp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp-trap -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp-trap -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport https -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport rtsp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3s -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport openvpn -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1195 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport cvspserver -j ACCEPT
[1:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport 3128 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport mysql -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport subversion -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport postgresql -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http-alt -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport git -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p icmp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp -d 37.97.65.186 --dport 5070 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp -d 37.97.65.0/24 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -d ns6-axfr.gandi.net -j ACCEPT
[0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A OUTPUT -m state --state INVALID -j DROP

La table mangle est utilisée pour la QoS. Comment se fait-il qu'un
paquet sur l

Trou dans un firewall (iptables nftable)

[BERTRAND Joël]

Bonjour à tous,

Je suis en train de configurer (péniblement) un serveur asterisk qui
est dans un DMZ. Tout le flux entrant sur l'IP publique est naté vers ce
serveur, protégé par un firewall iptables et fail2ban. Il s'agit
d'iptables et non d'iptables-legacy.

Cette machine est connectée à deux réseaux : wan0 d'un côté et lan0 de
l'autre.

Ce qui m'inquiète :

Root rayleigh:[/etc/asterisk] > tcpdump -i wan0 -p port 5060
...
12:26:54.145136 IP patient.census.internet-measurement.com.38253 >
rayleigh.systella.fr.sip: Flags [S], seq 3922597779, win 14600, options
[mss 1440], length 0

Là, je ne saisis pas puisque j'ai dans le fichier
/var/lib/iptables/active :

*filter
:INPUT DROP [28:3300]
:FORWARD DROP [0:0]
:OUTPUT DROP [27:3120]
[0:0] -A INPUT -i lo -j ACCEPT
[0:0] -A INPUT -i lan0 -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssh -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport smtp -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport domain -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport domain -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport http -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport ntp -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport https -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport ssmtp -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport submission -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport imaps -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport pop3s -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport openvpn -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport openvpn -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport cvspserver -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport jabber-client -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport git -j ACCEPT
[0:0] -A INPUT -i wan0 -p icmp -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp --dport 1 -j ACCEPT
[0:0] -A INPUT -i wan0 -p tcp -m tcp --dport 4443 -j ACCEPT
[0:0] -A INPUT -i wan0 -p udp -m udp -s 37.97.65.0/24 -j ACCEPT
[0:0] -A INPUT -i wan0 -s ns6-axfr.gandi.net -j ACCEPT
[0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -m state --state INVALID -j DROP
[0:0] -A OUTPUT -o lo -j ACCEPT
[0:0] -A OUTPUT -o lan0 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ftp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport ssh -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport telnet -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport smtp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport whois -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport domain -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport domain -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport gopher -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport nntp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport ntp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport snmp-trap -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport snmp-trap -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport https -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport rtsp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport pop3s -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport openvpn -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1195 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport cvspserver -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --dport cvspserver -j ACCEPT
[1:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport 3128 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport mysql -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport subversion -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport postgresql -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport http-alt -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp --dport git -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p icmp -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp --sport 1 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p tcp -m tcp -d 37.97.65.186 --dport 5070 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -p udp -m udp -d 37.97.65.0/24 -j ACCEPT
[0:0] -A OUTPUT -o wan0 -d ns6-axfr.gandi.net -j ACCEPT
[0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A OUTPUT -m state --state INVALID -j DROP

La table mangle est utilisée pour la QoS. Comment se fait-il qu'un
paquet sur le port 5060/UDP puisse être envoyé à mon serveur sans qu'il
ne soit jeté ? Il n'y a pas de conntrack-sip chargé...

Bien cordialement,

JKB

Re: Debian Bridge + firewall

[Helio Loureiro]

Já fiz, mas faz muito tempo atrás.  Com iptables.

./helio

On Thu, Nov 17, 2022, 13:32 Marcelo  wrote:

> Bom dia pessoal,
>
> Alguém utiliza o Debian no modo Bridge + firewall?
>
> Estou com algumas dúvidas para habilitar o firewall...
>
> Obrigado!
>

Debian Bridge + firewall

[Marcelo]

Bom dia pessoal,

Alguém utiliza o Debian no modo Bridge + firewall?

Estou com algumas dúvidas para habilitar o firewall...

Obrigado!

I have finally figured out how to export Private Key from Fortigate firewall and successfully install Godaddy Wildcard SSL certificate in UniFi Cloud Key Gen 2 Plus Network Controller

[Turritopsis Dohrnii Teo En Ming]

Subject: I have finally figured out how to export Private Key from
Fortigate firewall and successfully install Godaddy Wildcard SSL
certificate in UniFi Cloud Key Gen 2 Plus Network Controller

Good day from Singapore,

Author: Mr. Turritopsis Dohrnii Teo En Ming
Country: Singapore
Date: 26 Oct 2022 Wednesday

I have finally figured out how to export Private Key from Fortigate
firewall and successfully install Godaddy Wildcard SSL certificate in UniFi
Cloud Key Gen 2 Plus Network Controller because I have finally found the
correct reference guides! Please refer to the following list.

Reference Guides
=

Youtube video: Ubiquiti Networks UniFi OS SSL Certificate Installation
Link: https://www.youtube.com/watch?v=WxhY71ebc9o

Guide: Extracting Private Key from FortiGate Firewall
Link:
https://infosecmonkey.com/extracting-private-key-from-fortigate-firewall/

Guide: Extracting private key from FortiGate SSL Certificates
Link:
https://www.linkedin.com/pulse/extracting-private-key-from-fortigate-ssl-kuganesan-srijeyanthan

Guide: How to decrypt an RSA private key and then use it in kyrtool to
merge the SSL certificates.
Link:
https://support.hcltechsw.com/csm?id=kb_article_article=KB0098900

Guide: How to Fix an Encrypted SSL Private Key
Link: https://serverpilot.io/docs/how-to-fix-an-encrypted-ssl-private-key/

DETAILED INSTRUCTIONS FROM TEO EN MING
===

Login to the Fortigate 201F firewall and run the following commands using
CLI.

config vpn certificate local

edit 

show full

You will see something like:

-BEGIN ENCRYPTED PRIVATE KEY-
<---snipped--->
-END ENCRYPTED PRIVATE KEY-

Save the above encrypted private key as encrypted.txt in notepad or
notepad++ in Windows Server.

Then decrypt the encrypted private key using the openssl linux command.

openssl rsa -in encrypted.txt -out plain.txt

Download and install Keystore Explorer in Windows Server.

Launch KeyStore Explorer 5.5.1.

Click Create a new KeyStore.

Click JKS.

Click OK.

Click Import Key Pair.

Click OpenSSL.

Click OK.

Uncheck Encrypted Private Key.

Browse OpenSSL Private Key File. (plain.txt)

Browse Certificate(s) File. (chain.crt generated from Godaddy Wildcard SSL
certificate)

Click Import.

Enter Alias: unifi

Click OK.

Enter New Password: aircontrolenterprise

Confirm New Password: aircontrolenterprise

Click OK.

Click OK.

Click Save.

Enter New Password: aircontrolenterprise

Confirm New Password: aircontrolenterprise

Save KeyStore As: keystore (filename without extension)

Click Save.

Launch WinSCP in Windows Server.

Transfer keystore file to /srv/unifi/data.

Browse to /data/unifi-core/config. Create backup folder.

Move default/original unifi-core.crt and unifi-core.key to above backup
folder.

Upload plain.txt to /data/unifi-core/config as unifi-core.key.

Upload chain.crt (generated from Godaddy Wildcard SSL certificate) to
/data/unifi-core/config as unifi-core.crt

Reboot UniFi Cloud Key Gen 2 Plus network controller. You MUST reboot for
it to take effect!

SUCCESS!

Browse to https://cloudkey.teo-en-ming-corp.com on your favorite web
browser. You should see a padlock icon on the browser address bar. This
means that the Wildcard SSL certificate was installed correctly.

I started doing it at 5.00 PM and completed doing it at 6.00 PM Singapore
time on 26 Oct 2022 Wednesday.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
Blogs:
https://tdtemcerts.blogspot.com
https://tdtemcerts.wordpress.com

Re: regarding firewall discussion

[Richard Hector]

On 2/06/22 05:26, Joe wrote:

On Tue, 31 May 2022 03:17:52 +0100
mick crane  wrote:


regarding firewall discussion I'm uncertain how firewalls are
supposed to work.
I think the idea is that nothing is accepted unless it is in response
to a request.
What's to stop some spurious instructions being sent in response to
genuine request?


Nothing really, but the reply can only come from the site you made the
request to.


A source IP address can be faked.

Richard

Re: regarding firewall discussion

[mick crane]

On 2022-06-01 18:26, Joe wrote:

On Tue, 31 May 2022 03:17:52 +0100
mick crane  wrote:


regarding firewall discussion I'm uncertain how firewalls are
supposed to work.
I think the idea is that nothing is accepted unless it is in response
to a request.
What's to stop some spurious instructions being sent in response to
genuine request?



Nothing really, but the reply can only come from the site you made the
request to.

Don't connect to untrustworthy sites.

It is of course possible for a legitimate site to get hacked and some
malware embedded in its pages or linked from them, but that will
normally require JavaScript to run, and many people run browsers with 
JS

disabled. It's quite rare for a professionally-run site to get defaced,
as the terminology has it, but there's no way I would run a
public-facing website, as I don't know enough to secure it (and I know
that I don't know enough).

There are other defences: use a proxy server which blocks anything
suspicious, and so on. We're into application-level firewalls here,
that actually parse the returned packets, beyond the scope of iptables
and the like.

Browsers usually have a number of configurations concerning third-party
content, as well as plugins such as No-Script for Firefox. But a
blanket ban on JS will result in many (most?) websites today not
working. I despair of the 'web designers' who cannot display a single
character on a user's browser without using JS.


I have pfsense between me and the big bad world and I got some OINK code 
which I think is community based Snort list of undesirable addresses.
It is described as "Legacy" so I don't know if there is something newer 
I should be doing.


mick
--
Key ID4BFEBB31

Re: regarding firewall discussion

[Joe]

On Wed, 1 Jun 2022 15:02:10 -0400
rhkra...@gmail.com wrote:

> > mick crane  wrote:  
> > > regarding firewall discussion I'm uncertain how firewalls are
> > > supposed to work.
> > > I think the idea is that nothing is accepted unless it is in
> > > response to a request.
> > > What's to stop some spurious instructions being sent in response
> > > to genuine request?  
> 
> Just for the record, what you described (nothing is accepted unless
> it is in response to a request) is more like the way that NAT worked
> (at least in its original incarnations).  (I say it that way because
> I haven't kept up with NAT, so don't know how it may have changed).
> 

It still should, with exceptions for certain special cases that use a
second (usually data) channel that has to be associated with the
request. FTP and many older VPNs are of this kind.

An iptables-based firewall does the same (it can also do NAT) if a
RELATED rule exists. If there is no such rule, only packets explicitly
listed in the firewall code will be allowed in. This is necessary with
unsolicited packets i.e. the protocols allowed to bypass the firewall
e.g. ssh.

But the OP asked about malicious reply data, and neither iptables nor
NAT are equipped to detect this. Either a filtering proxy server (e.g.
http://e2guardian.org/cms/index.php) or the original requesting
application must deal with this.

-- 
Joe

Re: regarding firewall discussion

[rhkramer]

> mick crane  wrote:
> > regarding firewall discussion I'm uncertain how firewalls are
> > supposed to work.
> > I think the idea is that nothing is accepted unless it is in response
> > to a request.
> > What's to stop some spurious instructions being sent in response to
> > genuine request?

Just for the record, what you described (nothing is accepted unless it is in 
response to a request) is more like the way that NAT worked (at least in its 
original incarnations).  (I say it that way because I haven't kept up with 
NAT, so don't know how it may have changed).

Re: regarding firewall discussion

[Joe]

On Tue, 31 May 2022 03:17:52 +0100
mick crane  wrote:

> regarding firewall discussion I'm uncertain how firewalls are
> supposed to work.
> I think the idea is that nothing is accepted unless it is in response
> to a request.
> What's to stop some spurious instructions being sent in response to 
> genuine request?
> 

Nothing really, but the reply can only come from the site you made the
request to.

Don't connect to untrustworthy sites.

It is of course possible for a legitimate site to get hacked and some
malware embedded in its pages or linked from them, but that will
normally require JavaScript to run, and many people run browsers with JS
disabled. It's quite rare for a professionally-run site to get defaced,
as the terminology has it, but there's no way I would run a
public-facing website, as I don't know enough to secure it (and I know
that I don't know enough).

There are other defences: use a proxy server which blocks anything
suspicious, and so on. We're into application-level firewalls here,
that actually parse the returned packets, beyond the scope of iptables
and the like. 

Browsers usually have a number of configurations concerning third-party
content, as well as plugins such as No-Script for Firefox. But a
blanket ban on JS will result in many (most?) websites today not
working. I despair of the 'web designers' who cannot display a single
character on a user's browser without using JS.

-- 
Joe

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

[Tom Browder]

On Wed, Jun 1, 2022 at 11:21 john doe  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

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

[john doe]

On 6/1/2022 1:45 PM, Tom Browder wrote:

On Mon, May 30, 2022 at 19:46 Edwin Zimmerman  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?



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

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

[Tom Browder]

On Mon, May 30, 2022 at 19:46 Edwin Zimmerman  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

Re: regarding firewall discussion

[mick crane]

On 2022-05-31 12:21, IL Ka wrote:


What's to stop some spurious instructions being sent in response to
genuine request?



Packets do not contain instructions, only data. If your TCP/IP
implementation doesn't have vulnerabilities any packet shouldn't be a
problem.
Firewall prevents technically legal packets from reaching software that
shouldn't  be accessible from the Internet.

In most cases a hacker finds an opened port (port listened to by some
daemon) and connects to it.
Firewall prevents hacker from doing it.


I have wondered since ages ago, likely on windows, I wanted to know 
about something, I forget what, and there was one result in Alta Vista 
or something.

Go to website there is a message "GO AWAY".
I go away but then curious go back and my computer crashes.

mick

--
Key ID4BFEBB31

Re: regarding firewall discussion

[IL Ka]

>
>
> I think the idea is that nothing is accepted

it depends on policy (-P): either ACCEPT, REJECT or DROP


> unless it is in response to
> a request.
>
You must enable it explicitly, i.e.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


> What's to stop some spurious instructions being sent in response to
> genuine request?


Packets do not contain instructions, only data. If your TCP/IP
implementation doesn't have vulnerabilities any packet shouldn't be a
problem.
Firewall prevents technically legal packets from reaching software that
shouldn't  be accessible from the Internet.

In most cases a hacker finds an opened port (port listened to by some
daemon) and connects to it.
Firewall prevents hacker from doing it.

Re: regarding firewall discussion

[Jeremy Ardley]

On 31/5/22 10:17 am, mick crane wrote:
regarding firewall discussion I'm uncertain how firewalls are supposed 
to work.
I think the idea is that nothing is accepted unless it is in response 
to a request.
What's to stop some spurious instructions being sent in response to 
genuine request?


regards
mick



In the usual firewall tool iptables, you can tell it to accept related 
connections.
That is it remembers the host you just sent a request to and will let in 
new connections from that host on some other port


--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: regarding firewall discussion

[Emanuel Berg]

mick crane wrote:

> regarding firewall discussion I'm uncertain how firewalls
> are supposed to work. I think the idea is that nothing is
> accepted unless it is in response to a request. What's to
> stop some spurious instructions being sent in response to
> genuine request?

Firewalls can have whitelists, blocklists, employ various
algorithms to determine what should pass and what should not
based on characteristics of the material but also factors such
as time, recent activity and so on - you can think of a lot of
things to do and try ...

-- 
underground experts united
https://dataswamp.org/~incal

regarding firewall discussion

[mick crane]

regarding firewall discussion I'm uncertain how firewalls are supposed 
to work.
I think the idea is that nothing is accepted unless it is in response to 
a request.
What's to stop some spurious instructions being sent in response to 
genuine request?


regards
mick

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

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

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

[Timothy M Butterworth]

On Mon, May 30, 2022 at 1:24 PM Tom Browder  wrote:

> On Mon, May 30, 2022 at 09:03 IL Ka  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
>

If you have firewalld try running:
`firewall-cmd --permanent --add-service=http`
`firewall-cmd --reload`

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

[Tom Browder]

On Mon, May 30, 2022 at 09:03 IL Ka  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

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

[Tom Browder]

On Mon, May 30, 2022 at 08:42 Greg Wooledge  wrote:
..

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


It does serve other purposes.

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

[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

On Mon, May 30, 2022 at 4:42 PM 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*?
>
> 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...?
>
>

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

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

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

[Tom Browder]

On Mon, May 30, 2022 at 02:13 john doe  wrote:

> On 5/30/2022 12:26 AM, Tom Browder wrote:
> > On Sun, May 29, 2022 at 15:55 Greg Wooledge  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

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

[Curt]

On 2022-05-29, Greg Wooledge  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

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

[john doe]

On 5/30/2022 12:26 AM, Tom Browder wrote:

On Sun, May 29, 2022 at 15:55 Greg Wooledge  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.



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

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

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

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

[Timothy M Butterworth]

On Sun, May 29, 2022 at 8:13 PM Greg Wooledge  wrote:

> On Sun, May 29, 2022 at 11:50:44PM +, Lee wrote:
> > On 5/29/22, Greg Wooledge  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.
>
> 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

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

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

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

[Greg Wooledge]

On Sun, May 29, 2022 at 11:50:44PM +, Lee wrote:
> On 5/29/22, Greg Wooledge  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.

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

[Lee]

On 5/29/22, Greg Wooledge  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

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

[Tom Browder]

On Sun, May 29, 2022 at 15:55 Greg Wooledge  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

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

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

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

[Tom Browder]

On Sun, May 29, 2022 at 2:21 PM Greg Wooledge  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

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

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

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

[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

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

[john doe]

On 5/29/2022 7:20 PM, Tom Browder wrote:

On Sun, May 29, 2022 at 11:39 IL Ka  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! :)

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

--
John Doe

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

[Tom Browder]

On Sun, May 29, 2022 at 11:39 IL Ka  wrote:

> btw, are you able to ping server?
>

Yes.

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

[tomas]

On Sun, May 29, 2022 at 05:41:59AM -0500, Tom Browder wrote:
> On Sat, May 28, 2022 at 20:06 IL Ka  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

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


signature.asc
Description: PGP signature

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

[IL Ka]

btw, are you able to ping server?

On Sun, May 29, 2022 at 7:26 PM Tom Browder  wrote:

> On Sun, May 29, 2022 at 10:33 AM IL Ka  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/0multiport 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/0reject-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
>

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

[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

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

[Tom Browder]

On Sun, May 29, 2022 at 10:33 AM IL Ka  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/0multiport 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/0reject-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

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

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

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

[Tom Browder]

On Sun, May 29, 2022 at 09:51 IL Ka  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?

>

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

[IL Ka]

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

yes

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

[Tom Browder]

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

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

[Erwan David]

Le 29/05/2022 à 13:22, Tom Browder a écrit :

On Sun, May 29, 2022 at 05:41 Tom Browder  wrote:

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

-Tom


 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)

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

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

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

[Tom Browder]

On Sun, May 29, 2022 at 07:06 IL Ka  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.

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

[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

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

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



>
>
>
>

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

[Tom Browder]

On Sun, May 29, 2022 at 05:41 Tom Browder  wrote:

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

-Tom

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

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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

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

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-

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 iptables qui ne bloque pas le port 53

[Bernard Schoenacker]

- Mail original - 

> De: "JUPIN Alain" 
> À: "Liste Debian" 
> Envoyé: Jeudi 21 Avril 2022 09:26:49
> Objet: Firewall iptables qui ne bloque pas le port 53

> Bonjour,

> Je vous soumet un petit problème ... sur une install Debian 11, j'ai
> installé pi-hole (pour bloquer les pubs)

> Pihole fonctionne, mais (il y a toujours un mais), je cherche a
> bloquer son usage que pour quelques IP (vu qu'il est sur une IP
> publique).
> Voici donc les règles de mon firewall

> # Politique par defaut
> iptables -t filter -P INPUT DROP
> iptables -t filter -P FORWARD DROP
> iptables -t filter -P OUTPUT ACCEPT
> ip6tables -t filter -P INPUT DROP
> ip6tables -t filter -P FORWARD DROP
> ip6tables -t filter -P OUTPUT ACCEPT

> # Autoriser le Loopback
> iptables -t filter -A INPUT -i lo -j ACCEPT
> iptables -t filter -A OUTPUT -o lo -j ACCEPT
> ip6tables -t filter -A INPUT -i lo -j ACCEPT
> ip6tables -t filter -A OUTPUT -o lo -j ACCEPT

> ###
> # INBOUND TRAFIC #
> ###

> # On accepte les paquets déjà établis
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

> # PING (ICMP)
> iptables -A INPUT -p icmp -j ACCEPT
> ip6tables -A INPUT -p ipv6-icmp -j ACCEPT

> # SSH
> iptables -A INPUT -p tcp --dport 22 -j ACCEPT
> ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

> # DNS
> iptables -A INPUT -p tcp -s monIPv4 --dport 53 -j ACCEPT
> iptables -A INPUT -p udp -s monIPv4 --dport 53 -j ACCEPT
> ip6tables -A INPUT -p tcp -s monIPv6 --dport 53 -j ACCEPT
> ip6tables -A INPUT -p udp -s monIPv6 --dport 53 -j ACCEPT

> # HTTP(S)
> iptables -A INPUT -p tcp --dport 80 -j ACCEPT
> ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
> iptables -A INPUT -p tcp --dport 443 -j ACCEPT
> ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

> # On bloque tout le reste
> iptables -A INPUT -p tcp -j DROP
> ip6tables -A INPUT -p tcp -j DROP
> iptables -A INPUT -p udp -j DROP
> ip6tables -A INPUT -p udp -j DROP

> Le problème est que même activé, le port 53 n'est pas "bloqué" et
> tout le monde peut accéder à mon pi-hole !
> J'ai ajouté les 4 dernière lignes, mais sans effet !

> Bref, je dois bien passer a coté de quelques choses mais je ne vois
> pas quoi !

> Merci d'avance pour votre aide.

> --
> Alain JUPIN

Bonjour Alain,

Pour ton problème de port DNS, je t'invite à simplement consulter les pages 
sur le site du sieur Bortzmeyer et tu trouveras ton bonheur...

Et je n'ai pas compris la raison pour laquelle tu souhaites 
bloquer ce port, la seule chose intelligente serait de rediriger 
le trafic tcp 53 sur la partie udp 53 et de consulter la doc
pour DNSSEC

Merci pour ton aimable attention

Bien à toi

Bernard

Firewall iptables qui ne bloque pas le port 53

[JUPIN Alain]

  
  
Bonjour,

Je vous soumet un petit problème ... sur une install Debian 11, j'ai
installé pi-hole (pour bloquer les pubs)

Pihole fonctionne, mais (il y a toujours un mais), je cherche a
bloquer son usage que pour quelques IP (vu qu'il est sur une IP
publique).
Voici donc les règles de mon firewall

# Politique par defaut
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
ip6tables -t filter -P INPUT DROP
ip6tables -t filter -P FORWARD DROP
ip6tables -t filter -P OUTPUT ACCEPT

# Autoriser le Loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
ip6tables -t filter -A INPUT -i lo -j ACCEPT
ip6tables -t filter -A OUTPUT -o lo -j ACCEPT


###
#   INBOUND
TRAFIC    #
###

# On accepte les paquets déjà établis
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# PING (ICMP)
iptables -A INPUT -p icmp -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT

# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

# DNS
iptables -A INPUT -p tcp -s monIPv4 --dport 53 -j ACCEPT
iptables -A INPUT -p udp -s monIPv4 --dport 53 -j ACCEPT
ip6tables -A INPUT -p tcp -s monIPv6 --dport 53 -j ACCEPT
ip6tables -A INPUT -p udp -s monIPv6 --dport 53 -j ACCEPT

# HTTP(S)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

# On bloque tout le reste
iptables -A INPUT -p tcp -j DROP
ip6tables -A INPUT -p tcp -j DROP
iptables -A INPUT -p udp -j DROP
ip6tables -A INPUT -p udp -j DROP

Le problème est que même activé, le port 53 n'est pas "bloqué" et
tout le monde peut accéder à mon pi-hole !
J'ai ajouté les 4 dernière lignes, mais sans effet !

Bref, je dois bien passer a coté de quelques choses mais je ne vois
pas quoi !

Merci d'avance pour votre aide.

-- 
  Alain JUPIN

  

Re: Problème IPv6 et firewall avec Buster

[JUPIN Alain]

Bonsoir,

Je pense avoir résolu mon souci, non pas avec la MTU mais en redémarrant 
la VM.
J'ai l'impression que la prise en compte de la config réseau, notamment 
de la désactivation de l'autoconf de l'IPv6, n'a pas été totale la 
première fois?


Car maintenant, même avec le firewall actif, tout fonctionne nickel chrome !

Alain JUPIN

Le 15/09/2021 à 11:19, NoSpam a écrit :

Bonjour

essaye en passant la mtu ipv6 en 1496 ou 1492

Le 15/09/2021 à 10:11, JUPIN Alain a écrit :

Bonjour,

Sur une machine virtuelle fraîchement installée avec Buster en 
version 10.10, l'IPv6 a été configuré de la même manière que les 
autres VM.
La connexion IPv6 fonctionne très bien sauf qu'au bout d'un moment 
assez aléatoire (de quelques minutes à quelques dizaine de minutes), 
la connexion tombe !
Sous SSH, plus de réponse puis : "client_loop: send disconnect: 
Broken pipe", les autres service aussi ne répondent plus en IPv6
Fait "intriguant", la connexion IPv4 fonctionne parfaitement. Si je 
désactive le firewall, tout rentre dans l'ordre. Si je le réactive, 
tout fonctionne jusqu'à ce que ... patatrac !
Si je désactive le firewall, aucun soucis, je reste connecté en IPv6 
sans limitations de durée (au moins pendant plusieurs heures).


L'hôte de la machine virtuelle est un serveur dédié SoYouStart (de 
chez OVH), lui aussi sous Debian 10 faisant tourner Proxmox.
Quand j'ai le soucis d'IPv6 avec cette machine virtuelle, toutes les 
autres VM du même serveur fonctionnent encore parfaitement en IPv6, 
et même en dehors du serveur, le ping6 vers ipv6.ggogle.com, le surf 
etc en IPv6 fonctionne parfaitement.
Par contre en SSH (en IPv4), depuis le serveur en question, 
impossible de pinguer en IPv6 par ipv6.google.com : "connect: Le 
réseau n'est pas accessible"
J'écarte donc momentanément le soucis de config IPv6 chez moi, mais 
plutôt celui d'un problème de firewall probablement avec l'autoconfig 
d'IPv6 ou d'IPv6 lui-même ?


Enfin, le script du firewall (qui est le même que sur toute les 
autres VM dans son concept, car sur d'autres VM, d'autres ports comme 
le HTTP⋅S sont ouverts) :

# Politique par défaut IN/FWD est DROP, OUT en ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT

# Autoriser le Loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT

### 

#   INBOUND 
TRAFIC    #
### 



# On accepte tout le trafic des paquets déjà établis
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

# ICECAST
iptables -A INPUT -p tcp --dport 8000 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 8000 -j ACCEPT

# On accepte les requetes ICMP
iptables -A INPUT -p icmp -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m 
hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m 
hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl 
--hl-eq 255 -j ACCEPT

ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT

Pour vous aider (on sait jamais), voici la table de routage (route -A 
inet6)

Table de routage IPv6 du noyau
Destination    Next Hop   Flag Met  
Ref Use If
localhost/128  [::]   U 256 2 
0 lo
2001:41d0:2:5fdd::/64  [::]   U 256 2 
0 ens18
vss-2-6k.fr.eu/128 [::]   U 1024 2  
   0 ens18
2001:41d0:2:5f00::/56  [::]   UAe 256 
1 0 ens18
fe80::/64  [::]   U 256 1 
0 ens18
[::]/0 [::]   !n -1 1 
0 lo
localhost/128  [::]   Un 0 5 
0 lo
2001:41d0:2:5fdd::199:1/128    [::]   Un 0 3 
0 ens18
fe80::ff:fe5d:1c39/128 [::]   Un 0 3 
0 ens18
ff00::/8   [::]   U 256 3 
0 ens18
[::]/0 [::]   !n -1 1 
0 lo



Merci à vous pour votre aide, et petite précision, je suis pas un 
"pro" de l'IPv6 ! J'ai donc peut être zappé des points essentiels.

Problème IPv6 et firewall avec Buster

[JUPIN Alain]

Bonjour,

Sur une machine virtuelle fraîchement installée avec Buster en version 
10.10, l'IPv6 a été configuré de la même manière que les autres VM.
La connexion IPv6 fonctionne très bien sauf qu'au bout d'un moment assez 
aléatoire (de quelques minutes à quelques dizaine de minutes), la 
connexion tombe !
Sous SSH, plus de réponse puis : "client_loop: send disconnect: Broken 
pipe", les autres service aussi ne répondent plus en IPv6
Fait "intriguant", la connexion IPv4 fonctionne parfaitement. Si je 
désactive le firewall, tout rentre dans l'ordre. Si je le réactive, tout 
fonctionne jusqu'à ce que ... patatrac !
Si je désactive le firewall, aucun soucis, je reste connecté en IPv6 
sans limitations de durée (au moins pendant plusieurs heures).


L'hôte de la machine virtuelle est un serveur dédié SoYouStart (de chez 
OVH), lui aussi sous Debian 10 faisant tourner Proxmox.
Quand j'ai le soucis d'IPv6 avec cette machine virtuelle, toutes les 
autres VM du même serveur fonctionnent encore parfaitement en IPv6, et 
même en dehors du serveur, le ping6 vers ipv6.ggogle.com, le surf etc en 
IPv6 fonctionne parfaitement.
Par contre en SSH (en IPv4), depuis le serveur en question, impossible 
de pinguer en IPv6 par ipv6.google.com : "connect: Le réseau n'est pas 
accessible"
J'écarte donc momentanément le soucis de config IPv6 chez moi, mais 
plutôt celui d'un problème de firewall probablement avec l'autoconfig 
d'IPv6 ou d'IPv6 lui-même ?


Enfin, le script du firewall (qui est le même que sur toute les autres 
VM dans son concept, car sur d'autres VM, d'autres ports comme le HTTP⋅S 
sont ouverts) :

# Politique par défaut IN/FWD est DROP, OUT en ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT

# Autoriser le Loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT

###
#   INBOUND 
TRAFIC    #

###

# On accepte tout le trafic des paquets déjà établis
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

# ICECAST
iptables -A INPUT -p tcp --dport 8000 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 8000 -j ACCEPT

# On accepte les requetes ICMP
iptables -A INPUT -p icmp -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl 
--hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl 
--hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl 
--hl-eq 255 -j ACCEPT

ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT

Pour vous aider (on sait jamais), voici la table de routage (route -A 
inet6)

Table de routage IPv6 du noyau
Destination    Next Hop   Flag Met  Ref 
Use If

localhost/128  [::]   U 256  2 0 lo
2001:41d0:2:5fdd::/64  [::]   U 256  2 0 
ens18
vss-2-6k.fr.eu/128 [::]   U 1024 2     0 
ens18
2001:41d0:2:5f00::/56  [::]   UAe 256  1 
0 ens18
fe80::/64  [::]   U 256  1 0 
ens18

[::]/0 [::]   !n -1   1 0 lo
localhost/128  [::]   Un 0    5 0 lo
2001:41d0:2:5fdd::199:1/128    [::]   Un 0    3 
0 ens18
fe80::ff:fe5d:1c39/128 [::]   Un 0    3 
0 ens18
ff00::/8   [::]   U 256  3 0 
ens18

[::]/0 [::]   !n -1   1 0 lo


Merci à vous pour votre aide, et petite précision, je suis pas un "pro" 
de l'IPv6 ! J'ai donc peut être zappé des points essentiels.


--
Alain JUPIN

Re: Problème IPv6 et firewall avec Buster

[NoSpam]

Bonjour

essaye en passant la mtu ipv6 en 1496 ou 1492

Le 15/09/2021 à 10:11, JUPIN Alain a écrit :

Bonjour,

Sur une machine virtuelle fraîchement installée avec Buster en version 
10.10, l'IPv6 a été configuré de la même manière que les autres VM.
La connexion IPv6 fonctionne très bien sauf qu'au bout d'un moment 
assez aléatoire (de quelques minutes à quelques dizaine de minutes), 
la connexion tombe !
Sous SSH, plus de réponse puis : "client_loop: send disconnect: Broken 
pipe", les autres service aussi ne répondent plus en IPv6
Fait "intriguant", la connexion IPv4 fonctionne parfaitement. Si je 
désactive le firewall, tout rentre dans l'ordre. Si je le réactive, 
tout fonctionne jusqu'à ce que ... patatrac !
Si je désactive le firewall, aucun soucis, je reste connecté en IPv6 
sans limitations de durée (au moins pendant plusieurs heures).


L'hôte de la machine virtuelle est un serveur dédié SoYouStart (de 
chez OVH), lui aussi sous Debian 10 faisant tourner Proxmox.
Quand j'ai le soucis d'IPv6 avec cette machine virtuelle, toutes les 
autres VM du même serveur fonctionnent encore parfaitement en IPv6, et 
même en dehors du serveur, le ping6 vers ipv6.ggogle.com, le surf etc 
en IPv6 fonctionne parfaitement.
Par contre en SSH (en IPv4), depuis le serveur en question, impossible 
de pinguer en IPv6 par ipv6.google.com : "connect: Le réseau n'est pas 
accessible"
J'écarte donc momentanément le soucis de config IPv6 chez moi, mais 
plutôt celui d'un problème de firewall probablement avec l'autoconfig 
d'IPv6 ou d'IPv6 lui-même ?


Enfin, le script du firewall (qui est le même que sur toute les autres 
VM dans son concept, car sur d'autres VM, d'autres ports comme le 
HTTP⋅S sont ouverts) :

# Politique par défaut IN/FWD est DROP, OUT en ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT ACCEPT

# Autoriser le Loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT

### 

#   INBOUND 
TRAFIC    #
### 



# On accepte tout le trafic des paquets déjà établis
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

# ICECAST
iptables -A INPUT -p tcp --dport 8000 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 8000 -j ACCEPT

# On accepte les requetes ICMP
iptables -A INPUT -p icmp -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m 
hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m 
hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl 
--hl-eq 255 -j ACCEPT

ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT

Pour vous aider (on sait jamais), voici la table de routage (route -A 
inet6)

Table de routage IPv6 du noyau
Destination    Next Hop   Flag Met  
Ref Use If
localhost/128  [::]   U 256 2 
0 lo
2001:41d0:2:5fdd::/64  [::]   U 256 2 
0 ens18
vss-2-6k.fr.eu/128 [::]   U 1024 2     
0 ens18
2001:41d0:2:5f00::/56  [::]   UAe 256 
1 0 ens18
fe80::/64  [::]   U 256 1 
0 ens18
[::]/0 [::]   !n -1 1 
0 lo

localhost/128  [::]   Un 0 5 0 lo
2001:41d0:2:5fdd::199:1/128    [::]   Un 0 3 0 
ens18
fe80::ff:fe5d:1c39/128 [::]   Un 0 3 0 
ens18
ff00::/8   [::]   U 256 3 
0 ens18
[::]/0 [::]   !n -1 1 
0 lo



Merci à vous pour votre aide, et petite précision, je suis pas un 
"pro" de l'IPv6 ! J'ai donc peut être zappé des points essentiels.

Re: Firewall POSTROUTING problem

[Lucas Castro]

On 8/11/21 7:01 PM, Alain D D Williams wrote:

On Wed, Aug 11, 2021 at 11:50:30PM +0200, deloptes wrote:

Alain D D Williams wrote:


iptables -A FORWARD -j ACCEPT


and the OUTPUT?

OUTOUT is also ACCEPT, however this is not, I think, important as the packets
come from 10.239.239.23 (via br0) and go to the Internet - thus FORWARD is what
is important. Anyway: I see (on the modem) the packets with source 10.239.239.23


and this is not a problem ... evidence is outgoing packets with source
address 10.239.239.23

ah, ok, I misinterpreted it.

The important stuff from ifconfig is:

br0: flags=4163  mtu 1500
 inet 10.239.239.254  netmask 255.255.255.0  broadcast 10.239.239.255
 inet6 fe80::7ca1:36ff:fe12:7402  prefixlen 64  scopeid 0x20
 ether ee:3c:27:eb:c0:4f  txqueuelen 1000  (Ethernet)
 RX packets 31632  bytes 2596968 (2.4 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 2065  bytes 374487 (365.7 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163  mtu 1500
 inet 192.168.108.2  netmask 255.255.255.0  broadcast 192.168.108.255
 inet6 2001:4d48:ad51:2f00::2:2  prefixlen 112  scopeid 0x0
 inet6 fe80::922b:34ff:fe12:6470  prefixlen 64  scopeid 0x20
 ether 90:2b:34:12:64:70  txqueuelen 1000  (Ethernet)
 RX packets 922014  bytes 240006341 (228.8 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 562616  bytes 80027668 (76.3 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


The steps to get routing working on GNU/Linux


check ip_forward is enabled

cat /proc/sys/net/ipv4/ip_forward - it must be 1


In your case, your outgoing is 192.168.108.2 on enp3s0

and your lan network is 10.239.239.254

so the forwarding nat rule should be

iptables -t nat -A POSTROUTING  -s 10.239.239.0/24 -o enp3s0 -j SNAT 
--to  192.168.108.2


No need for INPUT/OUTPUT rules to forward packts, only FORWARD rules


iptables -A FORWARD -s 10.239.239.0/24 -i br0 -o  enp3s0 -m state 
--state NEW -j ACCEPT


To accept the incoming packts for related connections.

iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT


you need to be sure there is default route on the router, or trick the 
route using 'ip rule'


but check if the router is set any default route

'ip route list' or 'ip route list table default'

---
Lucas Castro

Re: Firewall POSTROUTING problem

[Alain D D Williams]

On Thu, Aug 12, 2021 at 01:28:57AM +0300, IL Ka wrote:
> >
> >
> >
> > > > iptables -A FORWARD -j ACCEPT
> >
> 
> Are you sure your packets are forwarded via netfilter?
> Try to disable forwarding (with sysctl) or change rulte to -j DROP and
> check traffic with sniffer (no packet should be forwarded from virt machine
> to the Internet)

It now works all of a sudden  I am scratching my head to see what I have
changed. The only thing is rebooting the virtual machine that I was testing
from. I cannot see that that should have made a difference. I was changing the
firewall ...

Anyway: thanks for now, I am sorry if I have wasted anyone's time :-(

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Firewall POSTROUTING problem

[IL Ka]

>
>
>
> > > iptables -A FORWARD -j ACCEPT
>

Are you sure your packets are forwarded via netfilter?
Try to disable forwarding (with sysctl) or change rulte to -j DROP and
check traffic with sniffer (no packet should be forwarded from virt machine
to the Internet)

Re: Firewall POSTROUTING problem

[Alain D D Williams]

On Wed, Aug 11, 2021 at 11:50:30PM +0200, deloptes wrote:
> Alain D D Williams wrote:
> 
> > iptables -A FORWARD -j ACCEPT
> > 
> 
> and the OUTPUT?

OUTOUT is also ACCEPT, however this is not, I think, important as the packets
come from 10.239.239.23 (via br0) and go to the Internet - thus FORWARD is what
is important. Anyway: I see (on the modem) the packets with source 10.239.239.23

> > and this is not a problem ... evidence is outgoing packets with source
> > address 10.239.239.23
> 
> ah, ok, I misinterpreted it.

The important stuff from ifconfig is:

br0: flags=4163  mtu 1500
inet 10.239.239.254  netmask 255.255.255.0  broadcast 10.239.239.255
inet6 fe80::7ca1:36ff:fe12:7402  prefixlen 64  scopeid 0x20
ether ee:3c:27:eb:c0:4f  txqueuelen 1000  (Ethernet)
RX packets 31632  bytes 2596968 (2.4 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2065  bytes 374487 (365.7 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163  mtu 1500
inet 192.168.108.2  netmask 255.255.255.0  broadcast 192.168.108.255
inet6 2001:4d48:ad51:2f00::2:2  prefixlen 112  scopeid 0x0
inet6 fe80::922b:34ff:fe12:6470  prefixlen 64  scopeid 0x20
ether 90:2b:34:12:64:70  txqueuelen 1000  (Ethernet)
RX packets 922014  bytes 240006341 (228.8 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 562616  bytes 80027668 (76.3 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Firewall POSTROUTING problem

[deloptes]

Alain D D Williams wrote:

> iptables -A FORWARD -j ACCEPT
> 

and the OUTPUT?

> and this is not a problem ... evidence is outgoing packets with source
> address 10.239.239.23

ah, ok, I misinterpreted it.

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

Re: Firewall POSTROUTING problem

[Alain D D Williams]

On Wed, Aug 11, 2021 at 11:32:51PM +0200, deloptes wrote:

> I remember it was not only the POSTROUTING. May be I am wrong, but I think
> FORWARD and OUTPUT is important.
> I also wonder why you are mixing up the -s and --to-source. You should be
> using the local address for -s and --to-source the translation (the
> outgoing addresses 10.239.239.23)

This says that anything with a source address 10.239.239.0/24 (ie virtual
machine) will have the source address changed to 192.168.108.2; this is so that
the BB modem does another NAT setting the source address to my external IP
address.

While I am debugging this, to avoid complication, I have set:

iptables -A FORWARD -j ACCEPT

and this is not a problem ... evidence is outgoing packets with source address
10.239.239.23

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

Re: Firewall POSTROUTING problem

[deloptes]

Alain D D Williams wrote:

> Hi,
> 
> I have problems getting POSTROUTING to work on a Debian 10 box.
> 
> Setup:
> 
> INTERNET ... Broadband modem 192.168.108.1
> 
> Network internal to the Debian box for virtual machines 10.239.239.0/24
> 
> Debian has address 192.168.108.2 (interface enp3s0) and 10.239.239.254
> (interface br0)
> 
> Processes on Debian 10 can talk to the Internet
> 
> Processes on virtual machines (eg 10.239.239.23) can talk to the Debian
> machine (ie 192.168.108.2) on which they are hosted.
> 
> If on 10.239.239.23 I ping the BBC (212.58.249.145) and look with a packet
> sniffer on the BB modem I see outgoing addresses 10.239.239.23
> 
> This should not happen. I am running an iptables firewall that should fix
> this with the rule below:
> 
> iptables -t nat -A POSTROUTING -s 10.239.239.0/24 -j SNAT --to-source
> 192.168.108.2
> 
> I have tried variations like:
> iptables -t nat -A POSTROUTING -o enp3s0 -j SNAT --to-source 192.168.108.2
> 
> 
> It is as if the POSTROUTING rule is being ignored.
> 
> This seems to be confirmed by the output below which shows that 0 packets
> have been through POSTROUTING.
> 
> Can anyone shed any light on this ?

I remember it was not only the POSTROUTING. May be I am wrong, but I think
FORWARD and OUTPUT is important.
I also wonder why you are mixing up the -s and --to-source. You should be
using the local address for -s and --to-source the translation (the
outgoing addresses 10.239.239.23)

I later switched to shorewall and since it is doing the iptables rules for
me, so now I just have to put some values in a config and would have
something like

# iptables-save  | grep eth0
:eth0_masq - [0:0]
-A PREROUTING -i eth0 -j net_dnat
-A POSTROUTING -o eth0 -j eth0_masq
-A eth0_masq -s 192.168.xxx.0/24 -j SNAT --to-source 10.0.xxx.1
-A INPUT -i eth0 -j net-fw
-A FORWARD -i eth0 -j net_frwd
-A OUTPUT -o eth0 -j ACCEPT
-A dmz_frwd -o eth0 -j dmz-net
-A loc_frwd -o eth0 -j ACCEPT
-A vpn_frwd -o eth0 -j vpn-net


-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0