stateful firewall issues (Was Re: Think Simple!)

[Giorgos Keramidas]

On 2006-09-01 17:49, george <zakinthinos at freemail.gr> wrote:
>Giorgos Keramidas wrote:
>>Κι εγώ ξαναλέω πως έχεις πιο σοβαρά προβλήματα αν χρησιμοποιείς αυτό το
>>firewall από το να ανησυχείς για bugs του state-keeping κώδικα.
>>
>>Οχι δεν είσαι αρκετά ασφαλής, αλλά δε φταίει το firewall γι αυτό.
>>
>  
>δεν μου τα λες και εμενα αυτα τα προβληματα αντι
>να παιδευεσαι με το εαν οι "εξαιρεσεις" που τσεκαρω
>πριν ειναι cpu-αποδοτικες ή οχι

Βλ. παρακάτω για ports >= 1024, για παράδειγμα...

>>>>>> 8) Επιτρέπεις έτσι απλά και ανενδοίαστα όλα τα incoming connections για
>>>>>> ports από 1024 και άνω.  ΑΥΤΟ ΔΕΝ ΕΙΝΑΙ ΚΑΛΗ ΙΔΕΑ!  Υπάρχουν περίπου
>>>>>> 64.510 διαφορετικοί λόγοι γιατί αυτό είναι βλακεία, αλλά θα σε αφήσω
>>>>>> να τους ανακαλύψεις ξεχωριστά τον καθένα, καθώς θα στήνεις νέα
>>>>>> services στο μηχάνημά σου.
>>>>>
>>>>> #αφησε τον χρηστη να κανει νεα 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:'' κομμάτι.
> 
> συγγνωμη συγκρινεις τους κανονες της OUTPUT με αυτους
> της INPUT και περιμενεις να ειναι οι ιδιοι ?

Οχι.  Απλά εξηγώ σε ποιο κανόνα αναφερόταν το αρχικό μου σχόλιο, επειδή
έκανες *ΕΣΥ* paste ακριβώς από κάτω ένα κανόνα που δεν έχει σχέση.

Οταν λέω λοιπόν, ότι τα έχεις αφήσει όλα ανοιχτά, δεν αναφέρομαι στους
OUTPUT κανόνες, παρόλο που έτσι φαίνεται να κατάλαβες αρχικά.

> φυσικο δεν ειναι στην OUTPUT ο χρηστης να μπορει να ξεκινησει ενα ftp
> client στην 21 (και να περιμενει πακετο στην INPUT απο τον server σε
> port > 1024 )

Οχι.  Φυσικό είναι να μη μπορεί να συνδεθεί σε *ΚΑΝΕΝΑ* port αν δεν
υπάρχει καλός λόγος.  Γι αυτό υπάρχουν τρόποι να "ανοίξεις" μόνο όσα
ports >=1024 είναι πραγματικά σε χρήση από κάποιο FTP session.

Για περισσότερα, ψάξε για "ftp helper iptable module" στο Google.

> επικρινεις το γεγονος οτι υπαρχουν 64.510 ports ανοιχτα αλλα δεν
> "βλεπεις" οτι υπαρχει state checking μεταξυ INPUT και OUTPUT, γιατι να
> το εβλεπες και να μου λεγες "βλακεια ειναι γιατι...." παει καλα, το
> αγνοεις εντελως και μιλας για 1000 περιφερειακα θεματα

Δεν το αγνοώ εντελώς.  Απλά εξακολουθεί να είναι λάθος, παρόλο που έχεις
state checking.  Το state checking *δεν* λύνει το πρόβλημα ότι έχεις
ορθάνοιχτα όλα τα ports από 1024 και πάνω.

> απο ολο το setup αφησα 3 γραμμες, αντε να δουμε αν θα δεις αυτο το
> αγιο ESTABLISHED,RELATED

Τα 'ESTABLISHED,RELATED' εγώ τα βλέπω.  Το --dport 1024: ακόμα να το
δεις εσύ;

>>  * Τι εννοείς "html data";
>>
>>  * Τι εννοείς "βάλε και udp για να κάνει resolve";
>>
>>  * Τι εννοείς "data τα οποία δημιούργησε";
>>
>>  * Τι εννοείς "προσπάθησε να είσαι adaptive";
>>
>>  * Τι εννοείς "να τον αφήσεις να κάνει τη δουλειά του";
>>
> 
> το μονο που τσεκαρω ειναι εαν το πακετο που επιστρεφεται στην INPUT
> ανηκει σε μια συνδεση που ξεκινησε απο την OUTPUT (τον χρηστη δηλαδη),
> δεν τον περιοριζω ουτε per host, ουτε per ports αλλα μονο στο εαν το
> πακετο ανηκει σε συνδεση που πρωτο-ξεκινησε ο χρηστης, και αρκετες
> μερες τωρα σε ρωταω εαν αυτο το πολυ "wide" setup ειναι ασφαλες και
> εχω ακουσει τα παντα (και θα τα χρησιμοποιησω και σε ευχαριστω) αλλα
> οχι αυτη την απαντηση

> πχ. lynx www.otenet.gr = resolve hostname otenet + request σε
> www.otenet.gr (αυτα στην OUTPUT) , ε λογικο δεν ειναι να περιμενει ενα
> IP address + html data packets στην INPUT ? (και να του επιτραπει του
> χρηστη)

Ξέχνα την HTML.  Για τα packet firewalls, αν δεν έχουν κάποιο layer7
filtering κομμάτι, δεν "υπάρχει" HTML.

> το W32.bugbear_ΧΥΖ virus/bot (λεμε τωρα) που κανει scan το net και
> χτυπαει στο 445 της INPUT θα εχει να κανει RELATED,ESTABLISHED με κατι
> της OUTPUT ?
> 
> σορρυ αλλα δεν μπορω να στο κανω πιο λιανα
>
> >Νομίζεις.  Τι σε κάνει να πιστεύεις ότι υπάρχει μόνο ο περιορισμός του
> >state checking?
> 
> προς χαριν της συζητησης ξεχασε οτι υπαρχουν αλλα κομματια στο setup ,
> εαν παρατηρησεις στις 3 γραμμες που απεμειναν (υποθετωντας οτι ολα τα
> policy ειναι DROP) θα δεις (ελπιζω) οτι μονο state-checking εχει
> μεινει σαν περιορισμος

Ναι, και το TCP sequence number, και το application-protocol-level
checking, και το encryption του SSH tunnel, και ένα σωρό άλλα.  Δεν
είναι άμεσα σχετικά με ένα firewall ruleset, αλλά δεν καταλαβαίνω γιατί
πιστεύεις ότι μόνο το firewall είναι η προστασία σου από τον "κακό tcp
programmer".

Ενα καλά ρυθμισμένο firewall είναι *κάτι*, αλλά δεν είναι τα *πάντα*.

Εσύ θες να σου πω ότι αν βάλεις "αυτό τον κανόνα" ή αν αλλάξεις τη σειρά
"σε αυτούς τους δύο", τότε είσαι ασφαλής από σήμερα και για πάντα από
οποαδήποτε "επίθεση".  Απλά ξέχνα το...  Αυτό *ΔΕΝ* *ΓΙΝΕΤΑΙ* και *ΔΕΝ*
*ΘΑ* *ΣΤΟ* *ΠΩ* όσο κι αν παίξεις με firewall rules :-P

>>> τα παραπανω κυριως "ρωτανε" εαν τα assumptions που εχω υιοθετησει
>>> ειναι αρκετα ασφαλη, ακριβως 'ΔΕΝ ΓΝΩΡΙΖΩ' εαν το RELATED,ESTABLISHED
>>> περιορισμος ειναι αρκετα ασφαλης
>>
>> Ορισμένα από τα assumptions που έχεις υιοθετήσει βασίζονται σε μια
>> ημιτελή, σποραδική γνώτη του τι ακριβώς είναι ένα 'connection'.  Δεν
>> είναι ακριβώς λάθος.  Είναι ΠΟΛΥ λάθος.
>
> ποια assumptions ειναι λαθος και γιατι ? :)

Το πρώτο από όλα τα λάθος 'assumptions' ('παραδοχές' λέγονται στα
Ελληνικά, παρεπιπτόντως) είναι ότι η μόνη προστασία σου είναι το
firewall ruleset που έχεις.

Το δεύτερο είναι ότι ένα αρκετά καλό firewall ruleset είναι "αρκετό"
(για κάποια σημασία του "αρκετό").