Apropo de chestia asta ca sa nu raman prost
eu accept in firewall ( Iptables) pentru IN doar smtp
si vad in loguri la greu DENY pe ( ICMP, 113, 53) sa inteleg ca unele
servere de mail fac interogari pe portul meu 53 ( de ce?) sau totusi daca
fac interogari pe 113 si primesc DENY de ce lasa totusi packetul sa
treaca...
Multumesc
----- Original Message -----
From: "Cristian Grigoriu" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 22, 2001 10:23 AM
Subject: [rlug] Re: Portul 113
>
>
> > > Nu. Daca default policy este REJECT sau DENY nu trec decit
> > > pachetele pentru care ai reguli de ACCEPT explicite. Asa ca
> > > tu nu trebuie sa faci nimic.
> >
> > Poftim? De unde ai scos-o si pe asta?
> > La orice pachet, se aplica prima regula care face match pe header-ul
> > pachetului; nu conteaza unde face jump regula, nu conteaza care e
> > policy-ul implicit. Daca regula spune ACCEPT, atunci aia se face. Daca
> > regula spune REJECT, aia se face. Daca spune DENY, aia se face.
> > Se ajunge la policy-uri numai si numai in cazul cind, pentru pachetul
> > respectiv, nu este nici o regula care sa semene.
> > Asadar, chiar daca ai policy DENY, daca ai o regula care zice REJECT
> > pentru un anume pachet, pai atunci REJECT se face.
> > Discutia era despre un fenomen ceva mai subtil decit "trece
> > pachetul sau
> > nu trece pachetul". Pentru unele chestii conteaza si cum anume "nu
> > trece".
>
> Pe ce iti bazezi afirmatiile de mai sus? Redau mai jos un fragment
> din 'IP Filter Based Firewalls HOWTO'. Chiar daca documentul este
> vechi, *principiile* sunt identice. Cel putin asa spune Rusty Russell
> si cine suntem noi sa-l contrazicem?
> ---------------------------------------------------
> 2.2. Basic Rule Processing
>
> The rules are processed from top to bottom, each one
> appended after another. This quite simply means that if the
> entirety of your config file is:
>
> block in all
> pass in all
>
> The computer sees it as:
>
> block in all
> pass in all
>
> Which is to say that when a packet comes in, the first thing
> IPF applies is:
>
> block in all
>
> Should IPF deem it necessary to move on to the next rule, it
> would then apply the second rule:
>
> pass in all
>
> At this point, you might want to ask yourself "would
> IPF move on to the second rule?" If you're familiar with
> ipfwadm or ipfw, you probably won't ask yourself this.
> Shortly after, you will become bewildered at the weird way
> packets are always getting denied or passed when they
> shouldn't. Many packet filters stop comparing packets to
> rulesets the moment the first match is made; IPF is not one
> of them.
>
> Unlike the other packet filters, IPF keeps a flag on
> whether or not it's going to pass the packet. Unless you
> interrupt the flow, IPF will go through the entire ruleset,
> making its decision on whether or not to pass or drop the
> packet based on the last matching rule. The scene: IP Fil-
> ter's on duty. It's been been scheduled a slice of CPU
> time. It has a checkpoint clipboard that reads:
>
> block in all
> pass in all
>
> A packet comes in the interface and it's time to go to work.
> It takes a look at the packet, it takes a look at the first
> rule:
>
> block in all
>
> "So far I think I will block this packet" says IPF. It
> takes a look at the second rule:
>
> pass in all
>
> "So far I think I will pass this packet" says IPF. It takes
> a look at a third rule. There is no third rule, so it goes
> with what its last motivation was, to pass the packet
> onward.
>
> It's a good time to point out that even if the ruleset had
> been
>
> block in all
> block in all
> block in all
> block in all
> pass in all
>
> that the packet would still have gone through. There is no
> cumulative effect. The last matching rule always takes
> precedence.
>
> ---
> Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
> unsubscribe from this list.
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
