Am 21.12.22 um 20:58 schrieb ToddAndMargo:
On 12/20/22 18:11, Reindl Harald wrote:
Am 20.12.22 um 23:55 schrieb ToddAndMargo:
On 12/20/22 12:01, Reindl Harald wrote:
you need exactly ONE "-m conntrack --ctstate RELATED,ESTABLISHED -j
ACCEPT" rule as the first of your ruleset which handles UDP and TCP
(aka don't specify -p)
[!] -p, --protocol protocol
The protocol of the rule or of the packet to check.
The specified protocol can be one of tcp, udp,
udplite, icmp, icmpv6,esp, ah, sctp, mh or
the special keyword "all"
Is leavingf off the "-p xxx" the same and "-p all"?
surely
If so, I am no sure tht I feel confortable opening
up "udplite, icmp, icmpv6, esp, ah, sctp, mh"
as well.
you do not open anything - when you don't even understand that
"RELATED,ESTABLISHED" only hits RESPONSE packets and so there must
have been any rule accepting the initial packet of a connection please
refrain for setup fireall rules
how do you imagine a ESTABLISHED state packet can exist in a protocl
you didn't accept the initial connect packet?
Bad guys fussing with packets to trick your stuff.
bad guys can't change how things are working
Hi Reindl,
I think that my level of paranoia is higher that
yours. It may comes from you understand this stuff
many times more than I do
your level of paranoia is fore sure not higher that mine but i don't
throw rules which make no sense and which i don't understand in my
infrastructure because every single rule i don't undertand in doubt does
either hram or is useless
technical rules have nothing to do with paranoia
when you don't accept any inital packet of a connection there is no way
that it falls under ctstate RELATED,ESTABLISHED
if you don't accept a sctp packet there is no way that any sctp could
hit RELATED,ESTABLISHED
the problem with your curent ruleset ist that you did copy&paste rules
from wherever without understanding what they are doing - that's the
worst case szart of a firewall ruleset
