Δημοσιεύτηκε: 18 Φεβ 2010, 19:26
από SpyrosB
panligo έγραψε:
SpyrosB έγραψε:Φίλε ο οδηγός σου εχει λάθη

Οι επιλογές Αllow/Deny/Reject δεν έχουν να κάνουν με το ping αλλα με το πώς θα αντιδράσει το firewall όταν πάρει ένα πακέτο

Allow, θα το επιτρέψει

Deny, θα το απορρίψει σιωπηλά αυτό που δηλαδή λέμε stealth

Reject, θα το απορρίψει στέλνοντας ένα πακέτο οτι η πόρτα είναι closed

Ευχαριστώ πολύ για την παρατήρηση. Με έβαλες σε σκέψεις και άρχισα να ερευνώ το θέμα...

Το έψαξα προκειμένου να αποσαφηνιστεί η διαφορά του Deny με του Reject και από ότι φαίνεται έχω γράψει σωστά τον οδηγό.
Για την ακρίβεια έκανα σχετική ερώτηση στο Launchpad και μου απάντησε ο Marcos, ο ιδιοκτήτης της ομάδας Gufw Developers.
Στην απάντηση του με παρέπεμψε σε αυτόν τον οδηγό του Ubuntu Documentation όπου και αναφέρονται τα εξής:
Κώδικας: Επιλογή όλων
# Allow: You will allow entry traffic for a port.
# Deny: You will deny entry traffic to a port (The machine will not respond to PINGs).
# Reject: You will deny entry traffic to a port (The machine will respond to PINGs).
# Limit: The port will accept a number of attempts.



Eίναι λάθος, μάλλον δε το έχει μελετήσει καλά το θέμα ο κύριος που έγραψε και το συγκεκριμένο άρθρο και μου κάνει εντύπωση που απαντάει χωρίς καν να μπαίνει στον κόπο να κάνει ping στον υπολογίστη του για να διαπιστώσει αν έχουμε δίκιο. Η ασφάλεια είναι σοβαρό θέμα και δεν είναι για να παίζουμε και να δίνουμε απάντηση χωρίς να ελέγξουμε αν όλα είναι σωστά, τέλος πάντων.

Το reject στέλνει μια απάντηση ICMP port unreachable σε οποιονδήποτε προσπαθεί να συνδεθεί σε συγκεκριμένο port και δεν έχει να κάνει με απάντηση σε pings. Όταν για παράδειγμα προσπαθείς να συνδεθείς με SSH το κάνεις στέλνοντας πακέτο TCP στη θύρα 22, δε κάνεις ping. Άλλωστε είναι πολύ απλο και μπορείς να το δοκιμάσεις μονος κάνοντας ping σε έναν υπολογιστή που το UFW/GUFW είναι ρυθμισμένο σε Deny και θα δείς οτι ο υπολογιστής απαντάει στα pings λογω before.rules

Επίσης

Note: Security by obscurity may be of very little actual benefit with modern cracker scripts. By default, UFW allows ping requests. You may find you wish to leave (icmp) ping requests enabled to diagnose networking problems.

You need to edit /etc/ufw/before.rules and remove edit the following lines:

Κώδικας: Επιλογή όλων
# ok icmp codes
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT


Change the "ACCEPT" to "DROP" or

Κώδικας: Επιλογή όλων
# ok icmp codes
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP
-A ufw-before-input -p icmp --icmp-type source-quench -j DROP
-A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP
-A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP

https://help.ubuntu.com/community/UFW


As mentioned, the ufw framework is capable of doing anything that iptables can do. This is achieved by using several sets of rules files, which are nothing more than iptables-restore compatible text files. Fine-tuning ufw and/or adding additional iptables commands not offered via the ufw command is a matter of editing various text files:

*

/etc/default/ufw: high level configuration, such as default policies, IPv6 support and kernel modules to use
*

/etc/ufw/before[6].rules: rules in these files are evaluated before any rules added via the ufw command
*

/etc/ufw/after[6].rules: rules in these files are evaluated after any rules added via the ufw command
*

/etc/ufw/sysctl.conf: kernel network tunables
*

/var/lib/ufw/user[6].rules or /lib/ufw/user[6].rules (0.28 and later): rules added via the ufw command (should not normally be edited by hand)
*

/etc/ufw/ufw.conf: sets whether or not ufw is enabled on boot, and in 9.04 (ufw 0.27) and later, sets the LOGLEVEL

https://wiki.ubuntu.com/UncomplicatedFi ... tuFirewall