Mikrotik IPv4/IPv6 firewall

**teodor_ch** · 24-09-20, 18:23

Δε ξέρω το περιβάλλον σου αλλά το να μπορεί να εγγυηθεί κάποιος για όλες τις συσκευές στο δίκτυο του είναι οποιαδήποτε στιγμή είναι για μένα απίθανο.
Παρόλα αυτά αφού έτσι τα έχεις καταφέρει όντως δε χρειάζεσαι έλεγχο στο forward.

Πιστεύεις ότι είναι σωστό να αντιγράφουν νέοι χρήστες αυτό το firewall?

Πάντως σε επαγγελματικό χώρο με 45 συσκευές πελατών και άλλες 20-30 της επιχείρησης,
με το default firewall συν έξτρα κανόνες για τους πελάτες και με mangle+queue tree στις ~1000συνδέσεις ο επεξεργαστής είναι κάτω απο το 20%

Δηλαδή δε βρίσκω το λόγο να μπώ στον κόπο να κάνω βόλτες filter+raw για να κερδίσω τί?
Ούτε η επιχείρηση θα δεί διαφορά και εμένα η ζωή μου θα γίνει πιο δύσκολη.

- - - Updated - - -

Αρχικό μήνυμα από macro

Oταν ενα πισι στο εσωτερικο σου δικτυο ζητησει καποια πληροφορια στο ιντερνετ, θα περασει μονο απο forward μεσα απο το ρουτερ για να παει τελικα στο πισι σου. Αυτο σημαινει οτι οι clients ειναι non firewall.

Αυτό σημαίνει ότι η επίθεση έχει ήδη παρακάμψει το firewall και έχει φτάσει στον υπολογιστή.

Η αλήθεια είναι ότι και εμένα τα drops στο forward είναι ελάχιστα και αυτά απο κάποια dockers που βγαίνουν με ips του docker subnet

**deniSun** · 24-09-20, 19:11

Αρχικό μήνυμα από macro

Oταν ενα πισι στο εσωτερικο σου δικτυο ζητησει καποια πληροφορια στο ιντερνετ, θα περασει μονο απο forward μεσα απο το ρουτερ για να παει τελικα στο πισι σου. Αυτο σημαινει οτι οι clients ειναι non firewall.

Σωστά.
Από τι κινδυνεύω λοιπόν;
Από την σελίδα που ζήτησα και μπορεί να με βλάψει με κάποιον τρόπο (σσ δεν μπαίνω σε τέτοιες σελίδες).
Πώς θα το κάνει αυτό;
Με κάποια πόρτα που είναι ανοιχτή στο ρούτερ; Είναι προστατευμένο είπαμε με τους υπάρχοντες κανόνες.
Με κάποια πόρτα ανοιχτή στον ΗΥ μου; Δεν κάνω port forward στους ΗΥ.
Να με αφήσει κάποιο μαμούνι που θα ζητάει συνέχεια πράγματα από έξω; Αφού λέω ότι δεν τίθεται τέτοιο θέμα στους ΗΥ.
Φυσικά... ποτέ μην λες ποτέ.
Αλλά προσωπικά δεν τρέχω ούτε av στους ΗΥ μου γιατί τους ελέγχο μόνος μου.

- - - Updated - - -

Αρχικό μήνυμα από teodor_ch

Πιστεύεις ότι είναι σωστό να αντιγράφουν νέοι χρήστες αυτό το firewall?

Ποτέ δεν είπα κάτι τέτοιο.
Με την ίδια λογική ο νέος χρήστης δεν θα πρέπει να δοκιμάσει τίποτε αφού ως νέος δεν θα ξέρει τι κάνει το κάθε τι.
Αν παρατηρήσεις τα config μου τα συνοδεύω πάντα από κάτω με το σκεπτικό.

Αρχικό μήνυμα από teodor_ch

Πάντως σε επαγγελματικό χώρο με 45 συσκευές πελατών και άλλες 20-30 της επιχείρησης,

Το έχω τονίσει 1000άδες φορές.
Μιλάμε για οικιακή χρήση.

Αρχικό μήνυμα από teodor_ch

Δηλαδή δε βρίσκω το λόγο να μπώ στον κόπο να κάνω βόλτες filter+raw για να κερδίσω τί?

Δεν ξέρω τι θα κερδίσεις.
Μπορώ να σου πω μόνο τι κέρδισα εγώ από τα προηγούμενα σεταρίσματα που είχα.
Αν αφήσουμε όμως το θέμα της απόδοσης που μπορεί να είναι μικρό σε δυνατά μηχανήματα,
τότε αυτό που μένει είναι η ευχρηστία.
Εδώ ο κάθε ένας χρησιμοποιεί ότι θέλει.
Έχω αλλάξει πολλές φορές το config μου χωρίς να κερδίσω στην πράξη τίποτε από θέμα απόδοσης, μόνο και μόνο για να το κάνω (εκείνη την στιγμή) περισσότερο "λογικό" και ευανάγνωστο/εύχρηστο σε εμένα.

Αρχικό μήνυμα από teodor_ch

Αυτό σημαίνει ότι η επίθεση έχει ήδη παρακάμψει το firewall και έχει φτάσει στον υπολογιστή.

Το αναλύω παραπάνω.

Αρχικό μήνυμα από teodor_ch

Η αλήθεια είναι ότι και εμένα τα drops στο forward είναι ελάχιστα και αυτά απο κάποια dockers που βγαίνουν με ips του docker subnet

Κάπως έτσι θεώρησα ότι δεν χρειάζεται να ελέγχω τίποτε στο forward.
Ένας λόγος που θεωρώ ότι τα μηχανήματά μου είναι καθαρά και δεν κινδυνεύουν.

**teodor_ch** · 24-09-20, 19:25

Αρχικό μήνυμα από deniSun

Κάπως έτσι θεώρησα ότι δεν χρειάζεται να ελέγχω τίποτε στο forward.
Ένας λόγος που θεωρώ ότι τα μηχανήματά μου είναι καθαρά και δεν κινδυνεύουν.

Σε ένα αποστειρωμένο περιβάλλον οκ.
Απλά επειδή δεν κοστίζει τίποτα και δεν έχω την όρεξη να χωρίσω το δίκτυο που μοιράζω στους καλεσμένους μου τα έχω αφήσει όπως προτείνει και η ΜΚ.

Για τον επαγγελματικό χώρο αναφέρθηκα στο ότι το RB951 είναι ΥΠΕΡ-αρκετό απο άποψη επεξεργαστή χωρίς καν τη χρήση του RAW.
Πόσο μάλλον για οικιακή χρήση.

Προφανώς το κάνεις γιατί έχεις το χρόνο και την όρεξη. Κανένα πρόβλημα.

**deniSun** · 24-09-20, 19:34

Αρχικό μήνυμα από teodor_ch

Προφανώς το κάνεις γιατί έχεις το χρόνο και την όρεξη. Κανένα πρόβλημα.

Όρεξη ναι... χρόνο όχι πάντα.

**macro** · 25-09-20, 10:15

Εγω δε θεωρω οτι εχεις firewall παντως. Τωρα εκφρασεις τους ειδους προσεχω κ.λ.π. δε μπορω να μπω στη διαδικασια να τις κατανοησω μιας και ειναι θεμα χρονου να την πατησεις οσο και αν προσεχεις.

Firewall μπορει να ονομαστει μονο ενα............ αυτο που τα εχεις ολα κλειστα και περνανε μονο αυτα που χρειαζεσαι και οχι καποιο setup τυπου λουνα παρκ με τη προυποθεση οτι ο end user πρεπει να ειναι προσεκτικος. Στο ειχα πει και τη πρωτη πρωτη φορα οταν το πρωτοποσταρες και για τα related που δε περνας αλλα επειδη παρεξηγησε σχετικως ευκολα δεν εδωσα προεκταση.

Δεν εισαι ο κανονας αλλα η εξαιρεση και καλα θα κανουν καποια καινουργια παιδια που φτιαχνουν firewall να μη χρησιμοποιησουν το δικο σου διοτι εχει θεματα.

Χωρις παραξηγηση ολα αυτα.

**deniSun** · 25-09-20, 17:40

Αρχικό μήνυμα από macro

Εγω δε θεωρω οτι εχεις firewall παντως. Τωρα εκφρασεις τους ειδους προσεχω κ.λ.π. δε μπορω να μπω στη διαδικασια να τις κατανοησω μιας και ειναι θεμα χρονου να την πατησεις οσο και αν προσεχεις.

Firewall μπορει να ονομαστει μονο ενα............ αυτο που τα εχεις ολα κλειστα και περνανε μονο αυτα που χρειαζεσαι και οχι καποιο setup τυπου λουνα παρκ με τη προυποθεση οτι ο end user πρεπει να ειναι προσεκτικος. Στο ειχα πει και τη πρωτη πρωτη φορα οταν το πρωτοποσταρες και για τα related που δε περνας αλλα επειδη παρεξηγησε σχετικως ευκολα δεν εδωσα προεκταση.

Δεν εισαι ο κανονας αλλα η εξαιρεση και καλα θα κανουν καποια καινουργια παιδια που φτιαχνουν firewall να μη χρησιμοποιησουν το δικο σου διοτι εχει θεματα.

Χωρις παραξηγηση ολα αυτα.

Ναι αλλά και εσύ δεν μου λες μια περίπτωση που θα μπορούσα να την πατήσω με την χρήση που κάνω.
Είναι σαν να σου λέω ότι δεν χρησιμοποιώ flashάκια, δεν έχω Internet και εσύ μου λες ότι θα πρέπει να έχω av.
Πες μου με ποιον τρόπο μπορεί κάποιος να βλάψει έναν ΗΥ του δικτύου μου.

- - - Updated - - -

Παρατηρώντας το fw σου βλέπω τα εξής:

1. Σχετικά με το raw ελέγχεις τους ίδιους κανόνες και για εισερχόμενη κίνηση και για εξερχόμενη.
Αυτό το θέμα το έχουμε λύσει.
Εγώ σου λέω ότι σε home/business users δεν έχεις να φοβηθείς αν θα δεχθεί επίθεση το ρούτερ σου.
Εσύ μου λες ότι "άσ το και ας υπάρχει".
οκ... το δικό σου είναι περισσότερο global.
Εγώ θεωρώ περιττό να ελέγχο τον ΗΥ μου για το αν θα κάνει DoS στο ρούτερ μου.

2α. Σχετικά με το filter... στο Input συμφωνούμε εν μέρη.
Προσωπικά θεωρώ ότι θα πρέπει να μπει πρώτα τα drop invalid και μετά τα accept.
Από δοκιμές που είχα κάνει δεν έχει διαφορά.
Το προτίμησα γιατί έτσι μου ήρθε περισσότερο λογικό ως προς την απόδοση.

2β. Στο accept έχεις και related.
Όσες μα όσες φορές τον έχω προσθέσει χώρια αυτόν τον κανόνα (απ ότι είδα η επιλογή δύο παραμέτρων εκλαμβάνονται ως or και όχι and) δεν μάζεψε ούτε ένα πακέτο, όσο χρονικό διάστημα και να το άφησα.

3α. Πάμε στο filter forward που έχουμε και τις περισσότερες διαφωνίες.
Αυτό που κάνεις εσύ είναι να αφήνεις να περάσει η κίνηση του lan από το input για να την ελέγξεις ξανά στο forward.

3β. Στο forward του λες να αφήνει όλην την κίνηση του lan να περνάει και να κόβει ότι δεν είναι nat.
Άρα στο προηγούμενο ερώτημα που σου έθεσα η απάντηση που βρίσκω για την περίπτωσή μου είναι
ότι θα μπορούσε να βλάψει έναν ΗΥ του δικτύου μου κάτι που θα περάσει από έξω από το raw,
θα περάσει και από το Input
και δεν ενώ δεν έχει γίνει nat θα περάσει προς τον ΗΥ μου.
Προσωπικά δεν μπορώ να φανταστώ πώς θα μπορούσε να υλοποιηθεί κάτι τέτοιο.
Αν κάποιος έχει περισσότερες γνώσεις σε hacking ας μας απαντήσει πόσο εύκολο/πιθανόν/δυνατόν είναι κάτι τέτοιο.

ΥΓ
Και στο filter ελέγχεις όλη την κίνηση εισερχόμενη και εξερχόμενη.
Ισχύει ότι επισήμανα στο (1).

**macro** · 25-09-20, 19:26

Μπορει ευκολα καποιος να την πατησει απο μολυσμενο site που τρεχει καποιο zero day exploit και οχι μονο αυτο. Απο οποιοδηποτε μολυσμενο site με οτιδηποτε.......... απλα τον πινεις. Τοσο απλο ειναι. Trojan, ransomware κ.λ.π. ειναι μερικα ακομη που καθονται σε sites και περιμενουν.

Tωρα οσων αφορα τα related ειναι απαραιτητα δευτεροντα πρωτοκολλα που ακολοθουν το πρωτο ack rcp connection. Μπορει να ειναι icmp, udp, quic, η οποιοδηποτε αλλο συνεδευετε με τη πρωτη πληροφορια και ειναι απαραιτητο να περναει.

**deniSun** · 25-09-20, 19:52

Αρχικό μήνυμα από macro

Απο οποιοδηποτε μολυσμενο site με οτιδηποτε.......... απλα τον πινεις. Τοσο απλο ειναι. Trojan, ransomware κ.λ.π.

Θα περάσει δηλαδή από το input και δεν θα γίνει ΝΑΤ και θα διοχετευτεί στον στο εσωτερικό δίκτυο;
Γιατί εσύ αυτές τις περιπτώσεις κόβεις.
Ότι δεν έχει γίνει ΝΑΤ.

Αρχικό μήνυμα από macro

Tωρα οσων αφορα τα related ειναι απαραιτητα δευτεροντα πρωτοκολλα

Δηλαδή αν βάλεις χώρια τον κανόνα για related βλέπεις να μαζεύεις πακέτα;
Γιατί όπως σου είπα εγώ δεν είδα ποτέ ο κανόνας αυτός να έχει μαζέψει κάτι.

**macro** · 25-09-20, 20:07

1) Εχει ηδη περασει το ΝΑΤ αφου η συνδεση σου ειναι established και ο κανονας input δε παιζει καμια σημασια στους clients. Τα πακετα προς τους clients ειναι forward. Τα ειπαμε αυτα πιο πανω.

2) Ναι πιανει οταν υπαρχει κατι να πιασει. π.χ online games. Εκει θα εβλεπες οτι πιανει μιας και πολλα παιχνιδια ζητανε δευτερευουσες πληροφοριες, π.χ. ping ή σε udp πληροφοριες του μηχανηματος σου ή γενικως της συνδεσης σου. Αυτος ειναι ο ρολος των related και ειναι σημαντικος.

**deniSun** · 25-09-20, 20:22

Αρχικό μήνυμα από macro

1) Εχει ηδη περασει το ΝΑΤ και ο κανονας input δε παιζει καμια σημασια στους clients. Τα ειπαμε αυτα πιο πανω.

2) Ναι πιανει οταν υπαρχει κατι να πιανει

Αν έχει περάσει το ΝΑΤ σε ποιο σημείο κόβει αυτά τα πακέτα;

**teodor_ch** · 25-09-20, 20:42

Αρχικό μήνυμα από deniSun

3α. Πάμε στο filter forward που έχουμε και τις περισσότερες διαφωνίες.
Αυτό που κάνεις εσύ είναι να αφήνεις να περάσει η κίνηση του lan από το input για να την ελέγξεις ξανά στο forward.

Η κίνηση απο το LAN προς το WAN ΔΕΝ περνάει απο το input. Οπότε δεν την ελέγχει ξανά.
Το αν χρειάζεται είναι άλλο θέμα.

Σε επαγγελματικό χώρο σε 1 μέρα με 90GB κίνησης οι forward κανόνες μου δεν έχουν κόψει κάτι (πέρα απο δικά μου restrictions).
Δεν είναι κάτι σύνηθες δηλαδή να υπάρχει προβληματική κίνηση στο forward.

Το βάζει και η ΜΚ οπότε δεν έχω ΚΑΝΕΝΑ λόγο να το αφαιρέσω!

Με την ίδια λογική αφού δεν ανοίγεις καμία πόρτα γιατί έχεις port scanner?

**deniSun** · 25-09-20, 20:50

Αρχικό μήνυμα από teodor_ch

Η κίνηση απο το LAN προς το WAN ΔΕΝ περνάει απο το input. Οπότε δεν την ελέγχει ξανά.
Το αν χρειάζεται είναι άλλο θέμα.

Από το forward περνάει και δεν χρειάζεται κατά την άποψή μου.
Αυτό λέει και στον κανόνα στο forward ότι αφήνει να περάσει όλη η κίνηση από το LAN
και κόβει μόνο ότι δεν έχει γίνει dst-nat.

Τους κανόνες για το forward τους έχω μόνο στο ν6.
Και αυτό γιατί εκεί έχει νόημα για εμένα αφού δεν υπάρχει ΝΑΤ.
Πρόσθεσα και στο ν4 τους ίδιους κανόνες με το ν4, αν και πραγματικά πιστεύω ότι είναι εντελώς άχρηστοι λόγο ΝΑΤ:

Κώδικας:

add action=jump chain=forward comment="Check all PPP" in-interface=pppoe-out1 \
    jump-target=ppp-frw
add action=drop chain=ppp-frw comment="Drop invalid connections" \
    connection-state=invalid
add action=accept chain=ppp-in comment="Accept established, related connections" \
    connection-state=established,related
add action=drop chain=ppp-frw comment="Drop all others"

Πάντα με in-interface το ppp γιατί πραγματικά δεν βρίσκω κανέναν λόγο να ελέγχο την κίνηση από μέσα προς τα έξω.
Πόσο μάλλον να το κάνω αυτό μόνο και μόνο για να του λέω "σε αφήνω να περάσεις".

Στο ν6 το drop all others στο forward μαζεύει αρκετό πράγμα.
Στο ν4 δεν νομίζω ότι θα δω κάτι.

**macro** · 26-09-20, 10:56

Λογω ελλειψης χρονου δε σου απαντησα για τη σειρα των drop και allow που με ρωτησες προηγουμενα.

Καθαρα για λογους performance πρεπει να βαζουμε τα allow πρωτα. Αν εχεις τα drop πρωτα, το ρουτερ χανει χρονο σε αυτα πριν δουλεψει τα allow.

**deniSun** · 26-09-20, 16:53

Λοιπόν... κοίταξα καλύτερα το config του @macro και το Link που έδωσε ο @teodor
και έχω κάνει τις εξής αλλαγές και παρατηρήσεις.

1. Ξεκινώντας με το raw του ν4 έχω προσθέσει στην κορυφή drop δηλώσεις για διευθύνσεις που δεν θα πρέπει να δρομολογούνται μέσω του ρούτερ.

Spoiler:

Και παρατήρησα ότι κόβει αρκετό πράγμα από κίνηση από το εσωτερικό δίκτυο προς το ρούτερ.

Spoiler:

Για το θέμα αυτό θα αναφερθώ και παρακάτω...
Δεν έχω προσθέσει In-interface γιατί (α) θέλω να ελέγχει κίνηση και από το εσωτερικό δίκτυο (β) απ ότι βλέπω όλη η κίνηση είναι στις δηλώσεις με dst-address, δηλαδή από μέσα προς τα έξω πράγμα που σημαίνει ότι κάποιος ρούτερ από έξω κόβει αυτή την κίνηση προς το ΜΤ. (γ) Λογικά λοιπόν θα μπορούσαν να παραληφθούν οι δηλώσεις που έχουν να κάνουν με την κίνηση από το έξω προς τα μέσα αλλά τις αφήνω μιας και το src-address μπορεί να ενεργοποιηθεί και από το εσωτερικό δίκτυο πχ να καρφώσει κάποιος έναν ΗΥ με τέτοια ΙΡ (προσωπικά το έχω αποκλύσει αυτό το ενδεχόμενο αλλά το αφήνω μόνο και μόνο μήπως οι ρούτερ που έγραψα παραπάνω σταματήσουν να κόβουν αυτά τα πακέτα).

2. Οι υπόλοιπες δηλώσεις στο raw που έχουν να κάνουν με το έλεγχο επίθεσης τις έχω αφήσει όπως τις είχα με in-interface.
Τον λόγο τον έγραψα πολλές φορές.
Σε home/business περιβάλλον δεν θεωρώ ότι κινδυνεύει ο ρούτερ από κάποια τέτοια επίθεση.
Επίσης δεν θα ήθελα να μπει μια ΙΡ από το lan σε block και να ψάχνομαι γιατί δεν έχει δίκτυο.
Φυσικά και σε μη ελεγχόμενα περιβάλλοντα πχ internet cafe ελέγχουμε όλη την κίνηση.

3. Στο filter του ν4 θεώρησα σωστό και εδώ να αφαιρέσω το in-interface από το input.
Και αυτό γιατί καλό είναι να απαλλάξουμε το ΜΤ από κίνηση τύπου invalid κλπ.
Έβαλα πρώτα το accept και μετά το drop όπως πρότεινε ο @macro αν και νομίζω ότι το είχα ελέγξει και είδα ότι ήταν προτιμότερο το αντίθετο.
Παρ όλα αυτά το είδα και σε άλλους οπότε... οκ.

4. Τα accept στο Input που έχουν να κάνουν με υπηρεσίες που τρέχουν στο ΜΤ πχ vpn λογικά θα έπρεπε να συνοδεύονται με in-interface.
Και αυτό γιατί δεν νομίζω ότι κάποιος από το εσωτερικό δίκτυο θα έπρεπε να συνδεθεί με vpn στο ΜΤ για να πάρει πρόσβαση προς τα έξω.
Παρ όλα αυτά αφαίρεσα την συγκεκριμένη παράμετρο γιατί προσθέτει έναν ακόμα έλεγχο χωρίς λόγο
και η περίπτωση που θα συμβεί το παραπάνω είναι σχεδόν μηδαμινή.
Οπότε αν θέλει κάποιος από μέσα να συνδεθεί με vpn για να βγει από το ΜΤ... οκ.

5. Οι δηλώσεις για allow all from lan και αμέσως μετά drop all others θα μπορούσαν να συνοψιστούν σε μία:

Κώδικας:

add action=drop chain=input comment="Input drop all not from LAN" \
    in-interface=pppoe-out1

Και αυτό για δύο λόγους: (α) για λιγότερους κανόνες/ελέγχους (β) για ευχρηστία και (γ) ο κανόνας όπου στο allow all from lan συνοδευόταν με In-interface δεν καλύπτει την περίπτωση του vpn πάνω στο ΜΤ.
Δηλαδή τα πακέτα από vpn θα έπεφταν στο drop.
Θα έπρεπε ή να προστεθεί επιπλέον κανόνας allo all from X-vpn ή all-vpn ή !pppoe
Οπότε... τζάμπα φασαρία.

6. Πρόσθεσα τους κανόνες του forward στο filter.
Όχι γιατί έχω πειστεί ότι υπάρχει κάποιος κίνδυνος να πάθει κάτι ένας ΗΥ από έξω,
αλλά για να κόβω invalid connections.
Και εδώ τα έχω αφήσει όλα χωρίς In-interface για τους λόγους που προανέφερα.

7. Στο κανόνα για drop πακέτα στο forward βλέπω ότι πολλοί (και έξω) χρησιμοποιούν το connection-state !dst-nat.
Ίσως για να γλιτώσουν κάτι κατά το port forward.
Προσωπικά προτίμησα να γραφεί ο κανόνας όπως ανέφερα και στο input για τους ίδιους λόγους:

Κώδικας:

add action=drop chain=forward comment="Forward drop all not from LAN" \
    in-interface=pppoe-out1

Ένας λόγος που το κάνω αυτό είναι για να υπάρχει σημετρία μεταξύ των κανόνων στο ν4 και ν6 (όσο αυτό γίνεται).
Στο ν7 λοιπόν επειδή δεν έχουμε ΝΑΤ πάμε με την λογική ότι ανοίγουμε πόρτες στο forward και δεχόμαστε τα πάντα από lan κάνοντας drop όλα τα υπόλοιπα.

8. Αντίστοιχα έχω κάνει της ίδιες αλλαγές και για το ν6.
Παραθέτω τις αλλαγές στην λίστα και στο raw.
Τα υπόλοιπα γίνονται κατά αντιστοιχία.

Spoiler:

Παρατηρήσεις:
Α. Ξεκινώντας με το θέμα των ΙΡ στις λίστες είδα ότι χωρίς τους κανόνες μπλοκαρίσματος
τα πακέτα δρομολογούνται κανονικά έξω από το ρούτερ.
Δηλαδή αν δώσει κάποιος traceroute 192.168.10.10 θα δει να φεύγουν κανονικά
έως ένα σημείο που κάποιος ρούτερ θα τα κόψει.
Θεωρώ ότι τέτοια πακέτα θα έπρεπε να μην βγαίνουν προς τα έξω.
Οπότε περιμένω παρατηρήσεις/διορθώσεις για τις διευθύνσεις στις λίστες.

Β. Δεν έχω βρει ακόμα (εύκολο) τρόπο για να κόβει το 192.168.0.0/16 πλην του range που χρησιμοποιούμε στο lan.
Δηλαδή αν πχ παίζουμε με 5.Χ και δώσουμε 6.1 σε traceroute το πακέτο θα βγει κανονικά όπως είπα στο (Α).
Έναν κανόνα δηλαδή στο raw:
add action=drop chain=prerouting dst-address-list=LocalIP
όπου:
add address=192.168.0.0/16 list=LocalIP
Όπου το 192.168.0.0/16 δεν θα περιλαμβάνει το 192.168.5.0/24

Γ. Σχετικά με τις λίστες ΙΡ θέλει προσοχή γιατί δεν ξέρω αν περιλαμβάνουν κάποιο range από αυτά που χρησιμοποιούν οι πάροχοι για να βάζουν τους χρήστες πίσω από ΝΑΤ.
Οπότε αν κάποιος είναι σε μια τέτοια περίπτωση ας μας πει.

Δ. Καλό είναι που ανοίξαμε ξανά το θέμα του fw και κάναμε κάποιες διορθώσεις
αλλά πιστεύω ότι θα έπρεπε να μας ενδιαφέρει πολύ περισσότερο το fw σε ν6.
Όπου εκεί λόγω μη ύπαρξης ΝΑΤ και λόγω real ip
η οποιαδήποτε συσκευή με ν6 είναι τελείως ευάλωτη χωρίς σωστό fw.
+ ότι έχουν γραφεί πολύ λίγα πράγματα για ν6 fw.

**jkarabas** · 27-09-20, 10:29

Καλημέρα
Τώρα διαβάζω το link που έστειλε ο teodor πολύ ενδιαφέρον.
Μελετώ και τις δικές σου προτάσεις deni και το βλέπουμε.

Θέμα: Mikrotik IPv4/IPv6 firewall

Παρόμοια Θέματα

Mikrotik IPv6 σε PPPoE client με modem σε bridge mode

Έναρξη πιλοτικής λειτουργίας IPv4/IPv6 dual stack από τον ΟΤΕ

Mikrotik 2011 DHCP lease failed without success Point to Multipoint

IPV6 + IPV4 SPEED TEST

Tags για αυτό το Θέμα

Bookmarks

Bookmarks

Δικαιώματα - Επιλογές