stateful firewall issues (Was Re: Think Simple!)
Giorgos Keramidas
keramida at ceid.upatras.gr
Fri Sep 1 15:17:21 EEST 2006
On 2006-09-01 06:52, george <zakinthinos at freemail.gr> wrote:
>Giorgos Keramidas wrote:
>>On 2006-08-30 19:39, maria <zakinthinos at freemail.gr> wrote:
>>>Giorgos Keramidas wrote:
>>> περα απο το confuzed 127.0.0.1 'i want to startx' τα λοιπα ειναι
>>> προσπαθειες να αντιμετωπιστουν INVALID πακετα πριν φθασουν να
>>> ελεγχθουν για state
>>
>> Γιατί;
Δεν είδα απάντηση εδώ...
>> Ετσι μπορεί να κόψεις νωρίς "κάποια" invalid πακέτα, αλλά βάζεις ένα
>> ΤΕΡΑΣΤΙΟ ΚΑΙ ΑΧΡΗΣΤΟ overhead στα πακέτα που είναι ήδη μέρος μιας
>> σύνδεσης -- τα οποία όπως έγραψα παραπάνω είναι η συντριπτική πλειοψηφία
>> των πακέτων σε ένα workstation που δουλεύω εγώ τόσο καιρό.
>
> το κομματι που δικαιολογει το γιατι υπαρχουν οι ελεγχοι των "INVALID"
> "εξαιρεσεων" ειναι ακριβως παρακατω, και εγω παρατηρησα οτι υπαρχουν
> 64.510 ports ανοιχτα και οτι δεν ελεγχω με ποιον host επικοινωνει ο
> χρηστης, η απορια μου ειναι "εαν βασιζομαι μονο στο state checking
> ειμαι αρκετα ασφαλης ?"
Κι εγώ ξαναλέω πως έχεις πιο σοβαρά προβλήματα αν χρησιμοποιείς αυτό το
firewall από το να ανησυχείς για bugs του state-keeping κώδικα.
Οχι δεν είσαι αρκετά ασφαλής, αλλά δε φταίει το firewall γι αυτό.
> (ας βαλουμε και μερικα checkpoints πριν, η εκπληκτικη λογικη του
> μπακαλη)
Όπως τη βρίσκει κανείς. Εμένα δε μου αρέσουν οι "μπακαλοδουλειές". Αν
εσύ τις θεωρείς ικανοποιητικές, τότε εντάξει.
>>>> 8) Επιτρέπεις έτσι απλά και ανενδοίαστα όλα τα incoming connections για
>>>> ports από 1024 και άνω. ΑΥΤΟ ΔΕΝ ΕΙΝΑΙ ΚΑΛΗ ΙΔΕΑ! Υπάρχουν περίπου
>>>> 64.510 διαφορετικοί λόγοι γιατί αυτό είναι βλακεία, αλλά θα σε αφήσω
>>>> να τους ανακαλύψεις ξεχωριστά τον καθένα, καθώς θα στήνεις νέα
>>>> services στο μηχάνημά σου.
>>>
>>> το ολο ζουμι της ιστοριας και η βασικη ερωτηση ειναι εδω
>>>
>>> ειναι προφανες οτι αφηνω πολλα ports ανοιχτα αλλα οι παρακατω γραμμες
>>> λενε (?)
>>>
>>> #αφησε τον χρηστη να κανει νεα connections
>>> #εχε το NEW εφόσον το POLICY ειναι DROP
>>>
>>> iptables -A OUTPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -s $PPP_LOCAL -j ACCEPT
Στο αρχικό σου μήνυμα δεν ήταν έτσι ο κανόνας στον οποίο αναφέρομαι:
http://lists.hellug.gr/pipermail/linux-greek-users/2006-August/064592.html
Σε αυτό το μήνυμα, υπάρχει κάτι σαν:
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -p tcp -d $PPP_LOCAL --dport 1024: -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -p udp -d $PPP_LOCAL --dport 1024: -j ACCEPT
Αναφέρομαι, φυσικά, στο ''--dport 1024:'' κομμάτι.
>>> # επετρεψε του να παραλαβει τα html data και βαλε kai udp για να
>>> # κανει resolve
>
> # επετρεψε του να παραλαβει τα οποια data δημιουργσησε γενικα
> # προσπαθησε μεσω των states να εισαι adaptive σε οτι συνδεσεις ξεκινα
> # με οποιονδηποτε host και και σε οποιοδηποτε port και να τον αφηνεις
> # να κανει την δουλεια του
Στέλνοντας ακόμα περισσότερες άχρηστες, ασαφείς, μπερδεμένες μέχρι
αηδίας, ασύντακτες και χωρίς καμία συνοχή προτάσεις δεν είμαι σίγουρος
ότι εξηγείς ακριβώς τι σήμαινε το αρχικό "περίεργο" σχόλιο για το οποίο
έγραψα.
* Τι εννοείς "html data";
* Τι εννοείς "βάλε και udp για να κάνει resolve";
* Τι εννοείς "data τα οποία δημιούργησε";
* Τι εννοείς "προσπάθησε να είσαι adaptive";
* Τι εννοείς "να τον αφήσεις να κάνει τη δουλειά του";
>>> iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -p tcp -d $PPP_LOCAL --dport 1024: -j ACCEPT
>>> iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -p udp -d $PPP_LOCAL --dport 1024: -j ACCEPT
>>
>>> με αλλα λογια επιτρεπουμε να ερθουν πραγματα που εχει ξεκινησει ο
>>> ιδιος ο χρηστης και αφορουν δικες του συνδεσεις
>>>
>>> δεν τον περιοριζουμε ουτε με ποιον host θα επικοινωνησει ουτε σε τι
>>> port
>>
>> Ετσι κι αλλιώς δεν περιορίζεσαι αν υπάρχει stateful firewall.
>
> ναι αλλα ενα καλο "πακετακι" που θα εκμεταλλευεται bugs των iptables
> μπορει να μου αλλαξει τα φωτα αφου ο μονος περιορισμος ειναι το state
> check
Νομίζεις. Τι σε κάνει να πιστεύεις ότι υπάρχει μόνο ο περιορισμός του
state checking?
>>> ο περιορισμος που υιοθετουμε ειναι οτι με βαση το RELATED,ESTABLISHED,
>>> πρεπει το πακετο να ανηκει σε συνδεση που εχει ξεκινησει ο χρηστης
>>>
>>> τα bugs των iptables και ενας καλος tcp/ip programmer παιζουν
>>> ρολο εφ'οσον η μονη γραμμη αμυνας ειναι το tcp state και το
>>> σε ποια συνδεση ανηκει ενα πακετο
>>
>> Δεν είμαι σίγουρος ότι ξέρω 100% τι κάνει το 'RELATED' αλλά για να το
>> λες, κάτι θα ξέρεις.
>
> τα παραπανω κυριως "ρωτανε" εαν τα assumptions που εχω υιοθετησει
> ειναι αρκετα ασφαλη, ακριβως 'ΔΕΝ ΓΝΩΡΙΖΩ' εαν το RELATED,ESTABLISHED
> περιορισμος ειναι αρκετα ασφαλης
Αν δε μπορείς να εμπιστευτείς το state-checking του firewall σου,
υπάρχει πάντα ένας πολύ καλός τρόπος να δεις αν μπορείς να το
εμπιστευτείς. Διάβασε το source του.
Ορισμένα από τα assumptions που έχεις υιοθετήσει βασίζονται σε μια
ημιτελή, σποραδική γνώτη του τι ακριβώς είναι ένα 'connection'. Δεν
είναι ακριβώς λάθος. Είναι ΠΟΛΥ λάθος.
Ας πούμε, τι πιστεύεις έτσι πάνω-κάτω ότι κάνει ένας "tcp programmer"
και γιατί σε φοβίζει τόσο πολύ αυτό το μυθικό ον;
> εαν θες προσπαθησε να κατανοησεις λιγο καλυτερα μονο τις γραμμες που
> γραφονται εδω (γιατι αυτες ειναι οι σημαντικες) και να επικεντρωθεις
> στο ποσο 'ανθεκτικο' ειναι το setup και οχι στο ποσο αποδοτικο/βελτιστο
Αν μπορείς να πετύχειςτο βέλτιστο, δεν είναι κρίμα να αφήνεσαι σε
"μπακαλοδουλειές" επειδή έχεις την ψευδή εντύπωση ότι είναι πιο
ασφαλείς, μόνο και μόνο επειδή δεν είναι το ίδιο αποδοτικές;
> κυριως δες οτι οι δυο γραμμες της INPUT γινονται RELATED με τις NEW συνδεσεις της OUTPUT
> normal disclaimer οτι και παλι αλλαξα οτι εγραφες
> applies
Normal disclaimer ότι ακόμα λες βλακείες(TM), applies.
More information about the Linux-greek-users
mailing list