hellug/magaz
4
1
Fork 0
Κώδικας Ζητήματα Pull requests Έργα Κυκλοφορίες Wiki Δραστηριότητα
magaz/content/articles/34/03_security.md

687 γραμμές
61 KiB
Markdown
Ακατέργαστο Κανονική Προβολή Ιστορικό

Πρώτο commit
2022-03-23 20:14:33 +02:00
+++
title = 'Host/network security'
date = '2003-06-01T00:00:00Z'
description = ''
author = 'Αλέξανδρος Παπαδόπουλος apapadop@cmu.edu(mailto:apapadop+magaz@cmu.edu)'
issue = ['Magaz 34']
issue_weight = 3
+++
----------------------------------------------------------------------------------------------------------------------------------------------------------------
*Βήματα για να ασφαλίσουμε το GNU/Linux σύστημά μας έναντι τοπικών και δικτυακών επιθέσεων. Ίσως πούμε δυο λογάκια και για θέματα privacy.*
----------------------------------------------------------------------------------------------------------------------------------------------------------------
**1. Τοπική ασφάλεια (Local Access)**
----------------------------------------------------------------
- [1.1 sXid binaries](#ss1.1)
- [1.2 Password cracking](#ss1.2)
- [1.3 Φυσική πρόσβαση](#ss1.3)
**2. Δικτυακή ασφάλεια**
---------------------------------------------------
- [2.1 Επιθέσεις Denial of Service (DoS)](#ss2.1)
- [2.2 Network Visibility](#ss2.2)
- [2.3 Firewalls](#ss2.3)
**3. Privacy**
-----------------------------------------
- [3.1 Διαφημίσεις (banner ads)](#ss3.1)
- [3.2 Cookies](#ss3.2)
- [3.3 Web bugs](#ss3.3)
### [1. Τοπική ασφάλεια (Local Access)]{#s1}
Με αυτό τον όρο εννοούμε τα μέτρα που πρέπει να πάρουμε ώστε κάποιος χρήστης που έχει πρόσβαση στον υπολογιστή μας (είτε φυσική πρόσβαση, είτε user account), να
μη μπορεί να αποκτήσει τον έλεγχο του συστήματος (root access).
### [1.1 sXid binaries]{#ss1.1}
Ιδιαίτερα επικίνδυνα για αυτό το σκοπό είναι τα suid root binaries. Δηλαδή τα προγράμματα που, ασχέτως του χρήστη που τα καλεί, εκτελούνται πάντα σαν να τα είχε
καλέσει ο root. Ο αριθμός των suid root binaries σε ένα σύστημα είναι ένα νούμερο που θέλουμε να το κρατήσουμε όσο το δυνατό μικρότερο, και να ελέγχουμε τακτικά
οποιαδήποτε αλλαγή. Μια ατέλεια στον κώδικα ενός εκτελέσιμου προγράμματος αρκεί για να γίνει ένα [buffer
overflow](http://www.wikipedia.org/wiki/buffer_overflow), το οποίο, σε suid root binaries, σημαίνει root shell, δηλαδή πλήρη έλεγχο του συστήματος.
Αν λοιπόν έχουμε μετρήσει όλα τα suid root binaries και ξέρουμε ότι είναι 25 στο σύστημά μας, και μετά από λίγο καιρό ελέγξουμε και βρούμε 26, πρέπει να
εξετάσουμε πολύ προσεχτικά αυτό το 26ο πρόγραμμα και να σιγουρευτούμε ότι είναι κάτι που εμείς εγκαταστήσαμε.
Για μια λίστα με τα setuid και setgid αρχεία στο σύστημά μας, κάνουμε το εξής:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
# find / \( -perm -02000 -o -perm -04000 \) -ls > setXid
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Κατόπιν μπορούμε να μετρήσουμε τις γραμμές αυτού του αρχείου, και έτσι να ξέρουμε πόσα τέτοια (setXid) ειδικά αρχεία έχουμε:
# wc -l setXid
Είναι καλή ιδέα να ελέγχουμε περιοδικά το πλήθος αυτών των ειδικών αρχείων και να εντοπίζουμε τυχόν διαφορές.
### [1.2 Password cracking]{#ss1.2}
Ακόμα και αν κάποιος καταφέρει να αποκτήσει τοπική πρόσβαση στο σύστημά μας, με κάποιον υπάρχοντα λογαριασμό, έχουμε χάσει μόνο τη μάχη, αλλά όχι απαραιτήτως
τον πόλεμο. Για να μην τραβήξει την προσοχή, ο επιτιθέμενος θα προσπαθήσει να μάθει όλα τα συνθηματικά (passwords) των χρηστών του συστήματος, χωρίς να τα
αλλάξει. Ακόμα και αν κάποιος έχει root access στο μηχάνημά σας, πρέπει να είναι ιδιαίτερα προσεχτικός για να μην τον ανακαλύψετε. Οπότε, παρόλο που ο root
μπορεί να αλλάξει οποιοδήποτε password και να προσθέσει οποιονδήποτε λογαριασμό, η καλύτερη μέθοδος είναι να ξέρει κανείς όλα τα υπάρχοντα συνθηματικά, και να
τα χρησιμοποιεί όποτε χρειάζεται πρόσβαση.
Έχοντας root, ή έχοντας καταφέρει να διαβάσει το αρχείο /etc/shadow με κάποιο άλλο τρόπο, ο επιτιθέμενος θα προσπαθήσει να μάθει όλα τα συνθηματικά που
βρίσκονται σε αυτό το αρχείο. Αν τα συνθηματικά ακολουθούν τους κανόνες των δυνατών passwords, κάτι τέτοιο θα είναι από πολύ δύσκολο έως πρακτικά αδύνατο.
Ο καλύτερος τρόπος για να διαπιστώσετε πόσο ισχυρά είναι τα συνθηματικά που χρησιμοποιούνται στο σύστημά σας, είναι να προσπαθήσετε να τα \"σπάσετε\" (crack)
μόνοι σας. Χρησιμοποιώντας το καλύτερο password cracker για συστήματα UNIX [(John the Ripper)](http://www.openwall.com%20john/), θα μάθετε αν το συνθηματικό σας
θα αντέξει σε τέτοιου είδους επιθέσεις.
Η χρήση του John είναι πολύ απλή: Αφού κατεβάσετε το tarball (\*.tar.gz), το κάνετε extract (tar xvfz \*.tar.gz), μπαίνετε στον κατάλογο john-1.x/src/ και
δίνετε ένα
$ make
Αυτό θα σας πει τις επιλογές που έχετε, και θα διαλέξετε την πιο κατάλληλη για το σύστημά σας. Μόλις τελειώσει το compile, μπείτε στον κατάλογο john-1.x/run/
και:
# ./unshadow /etc/passwd /etc/shadow > passwords
$ ./john passwords
Ο John θέλει λίγα δευτερόλεπτα για να μαντέψει τα τελείως ελεεινά συνθηματικά (όμοια με το όνομα χρήστη, κάτω από 4 χαρακτήρες, λέξεις λεξικού), αλλά μπορεί να
τρέχει επί εβδομάδες χωρίς να μπορεί να βρει ένα δυνατό password 8 χαρακτήρων.
Καλά συνθηματικά είναι αυτά που έχουν τα εξής στοιχεία:
- Έχουν τουλάχιστον 6 χαρακτήρες
- Περιέχουν τουλάχιστον έναν χαρακτήρα από τις εξής κατηγορίες:
- Kεφαλαία (A-Z)
- Πεζά (a-z)
- Aριθμούς (0-9)
- Eιδικούς χαρακτήρες (!, @, \#, %, : κτλ.)
- Δεν συνδέονται με κάτι που μπορεί να μαντέψει ο επιτιθέμενος αν σας γνωρίζει προσωπικά (ημερομηνία γέννησης, όνομα συγγενή κτλ)
- Είναι αρκετά εύκολα να τα θυμάστε εσείς και να τα πληκτρολογείτε ώστε να μη σας σπάνε τα νεύρα! Δε λέω, καλό συνθηματικό το **kj%{8\*\#I**, αλλά δεν
πρόκειται να το θυμάμαι για πάνω από 2 λεπτά, **ή** (ακόμα χειρότερα), άπαξ και το μάθω δεν θα θέλω να το αλλάξω ποτέ επειδή είναι το πλέον uncrackable
συνθηματικό. Αυτή είναι εξίσου κακή πρακτική με το να έχετε πολύ εύκολα συνθηματικά, επειδή αν κάποιος καταφέρει να κλέψει αυτό το συνθηματικό
παρακολουθώντας το δίκτυο, πχ, θα έχει αιώνια πρόσβαση στο μηχάνημά σας.
- Δεν είναι λέξη σε οποιαδήποτε γλώσσα! Αν νομίζετε ότι ένα συνθηματικό σε Σουαχίλι ή από κάποιον επιστημονικό κλάδο σας σώζει, ρίξτε μια ματιά στις
[λίστες](ftp://ftp.ox.ac.uk/pub/wordlists/) που κυκλοφορούν.
Μια καλή πρακτική είναι να δημιουργούμε συνθηματικά από χαρακτήρες φράσεων που μπορούμε να τις θυμηθούμε εύκολα, αλλά αν δεν ξέρει κάποιος την φράση, το
συνθηματικό να μην έχει κανένα νόημα. Παράδειγμα: Ας πούμε ότι το αγαπημένο σας τραγούδι είναι το \"Welcome to the machine\" των Pink Floyd. Από τους πρώτους
χαρακτήρες κάθε λέξης, βγάζουμε το εξής: Wttm\_PF, που δεν είναι καθόλου άσχημο, αλλά δεν σέβεται όλους τους κανόνες ενός καλού συνθηματικού. Οπότε
αντικαθιστούμε μερικούς χαρακτήρες με αριθμούς σε \"leet-speak lingo\": **W11m-PF** και ιδού!
### [1.3 Φυσική πρόσβαση]{#ss1.3}
Για να προστατέψουμε τον υπολογιστή μας από επιθέσεις με φυσική πρόσβαση, όπου ο χρήστης κάθεται στο πληκτρολόγιο, χρειαζόμαστε πολλά και διάφορα. Ο γενικός
κανόνας είναι ότι \"φυσική πρόσβαση = root πρόσβαση\", για τους εξής λόγους:
Ας πούμε ότι αφήνουμε τον υπολογιστή μας και πεταγόμαστε στο διπλανό δωμάτιο για μερικά λεπτά. Αν κάποιος θέλει να αποκτήσει πρόσβαση στον υπολογιστή μας,
μπορεί απλά να κάτσει στο πληκτρολόγιο και να ψάξει για τυχόν root logins που έχουμε αφήσει ενεργά. Λύση: ΠΟΤΕ μην αφήνετε root logins ενεργά χωρίς πολύ καλό
λόγο. Αν χρειάζεται να τρέχει κάτι σαν root για μεγάλα χρονικά διαστήματα, μπορείτε να το καλέσετε με έναν τρόπο που να κάνει logout μόλις τερματιστεί η
εργασία. Παράδειγμα:
# tail -f /var/log/messages ; logout
Με αυτή τη γραμμή, μπορείτε να αφήσετε ένα root terminal με σχετική ασφάλεια, επειδή αν κάποιος διακόψει την εργασία με CTRL+C, εκτελείται αμέσως το logout και
χάνεται το root shell.
Αλλά ακόμα και η πρόσβαση σαν κανονικός χρήστης μπορεί να είναι καταστροφική. Πχ, μπορεί κάποιος να σβήσει/διαβάσει/διαφθείρει όλα τα προσωπικά σας αρχεία, να
στείλει email με το όνομά σας και άλλα δυσάρεστα. Μια λύση είναι όταν δουλεύετε στο γραφικό περιβάλλον να κλειδώνετε το τερματικό πριν φύγετε από το
πληκτρολόγιο (όλοι οι μοντέρνοι window managers μπορούν να καλέσουν το xlock που κάνει ακριβώς αυτή τη δουλειά).
Τι γίνεται όμως αν κάποιος πατήσει απλά CTRL+ALT+Backspace και \"σκοτώσει\" το γραφικό περιβάλλον; Δεν θα μείνει με ένα shell του χρήστη μας;
Δεν είναι απαραίτητο. Για να αποφύγουμε αυτό το πρόβλημα μπορούμε να προσθέσουμε ένα alias στο .bashrc μας, που να θέτει:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
alias startx="startx -- -nolisten tcp; logout"
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Έτσι, με το που τερματίσουμε με οποιοδήποτε τρόπο το X session μας, ο χρήστης μας κάνει αυτόματα logout. Για τη σημασία του **\"-nolisten tcp\"** θα μιλήσουμε
παρακάτω.
Όμως ακόμα και αν ο επιτιθέμενος δεν βρει έτοιμο prompt στο μηχάνημά μας, δεν μπορεί να το εκμεταλλευτεί; Σίγουρα, αν έχουμε \"ευκολίες\" όπως automount και
autoexec στο CDROM. Μια δυσάρεστη έκπληξη που είχα σε ένα φρεσκο-εγκατεστημένο σύστημα ήταν όταν έβαλα ένα δισκάκι στο CD drive και μετά από λίγα δευτερόλεπτα
είδα τον Mozilla να ανοίγει ένα παράθυρο και να μου δείχνει την \"αρχική σελίδα\" του CD, παίζοντας περιχαρώς **μουσική**! Τι θα γινόταν αν αυτό το CD είχε
κώδικα με περίεργες προθέσεις, που περίμενε την αρχική σελίδα (index.html) για να ενεργοποιηθεί;
Για να αποφύγουμε τέτοιες εκπλήξεις καλό είναι να απενεργοποιήσουμε οποιοδήποτε automount και να σιγουρευτούμε ότι το mount γίνεται με ασφαλείς παραμέτρους.
Μερικές χρήσιμες παράμετροι είναι oι noexec, nosuid. Ρίξτε μια ματιά στο man mount για περισσότερα.
Αλλά και πάλι, αν κάποιος μπορεί να επανεκκινήσει τον υπολογιστή, μπορεί να επιλέξει από τον boot loader (LILO, GRUB ή οτιδήποτε άλλο χρησιμοποιούμε) να κάνει
boot σε single mode, όπου έχει πλήρη έλεγχο του συστήματος. Για να αποκλείσουμε και αυτή την πιθανότητα, μπορούμε να βάλουμε έναν κωδικό στον boot loader. Έτσι,
μόνο όποιος ξέρει τον κωδικό μπορεί να ξεκινήσει το σύστημα. Αυτό επιτυγχάνεται στα αρχεία /etc/lilo.conf και /etc/grub.conf (για τους δύο πιο δημοφιλείς boot
loaders).
Όμως ποιος τα χρειάζεται όλα αυτά, όταν υπάρχει το [KNOPPIX](http://www.knopper.net/knoppix/index-en.html); Απλά κάνουμε ένα reboot τον υπολογιστή, βάζουμε το
δισκάκι στο drive, παρακάμπτουμε ό,τι είδους ασφάλεια υπάρχει, και κάνουμε mount τον δίσκο του θύματος με πλήρη δικαιώματα! Εύκολο; Όχι τόσο γρήγορα. Γι\'αυτό
υπάρχουν τα [BIOS](http://www.webopedia.com/TERM/B/BIOS.html) passwords, που ζητούν τον κωδικό του χρήστη πριν επιτρέψουν σε κάποιον να αλλάξει τη συνηθισμένη
σειρά εκκίνησης και να κάνει boot από CD ή δισκέτα.
Αλλά αν έχετε laptop πχ, και ο \"κακός\" μπορεί να βουτήξει απλά ολόκληρο το laptop ή να βγάλει στο πι και φι τον δίσκο και να τον πάρει μαζί του; Αυτή είναι
μάλλον η χειρότερη περίπτωση, και το μόνο που μας σώζει είναι κάποιο encrypted filesystem, που δεν επιτρέπει στον δίσκο να διαβαστεί από κάποιον που δεν έχει το
κατάλληλο λογισμικό και δεν ξέρει το σωστό συνθηματικό (pass-phrase) για να τον αποκωδικοποιήσει. Επειδή δεν έχω εμπειρία σε κάτι τέτοιο, θα σας προτείνω απλά
να κωδικοποιείτε με το [Gnu Privacy Guard (GPG)](http://gnupg.org) οτιδήποτε δεν θέλετε να πέσει με τίποτα σε λάθος χέρια.
Δεν είναι καθόλου δύσκολο! Αν έχετε ήδη [δημιουργήσει τα κλειδιά](http://andrew.cmu.edu/~apapadop/linux/howto.html#3.3.7) σας και μπορείτε να χρησιμοποιήσετε το
gpg, μπορείτε να μαζέψετε όλα τα ευαίσθητα αρχεία σας σε έναν κατάλογο (ας πούμε secret/). Με ένα
----------------------------------------------------------------------------------------------------------------------------------------------------------------
$ tar -cf secret.tar secret
----------------------------------------------------------------------------------------------------------------------------------------------------------------
δημιουργείτε ένα αρχείο που περιέχει ολόκληρο τον κατάλογο secret. Μετά μπορείτε να κωδικοποιήσετε (encrypt) το αρχείο αυτό με το προσωπικό σας κλειδί, ώστε
μόνο εσείς να μπορείτε να το αποκωδικοποιήσετε στο μέλλον:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
$ gpg -esr apapadop@cmu.edu secret.tar
----------------------------------------------------------------------------------------------------------------------------------------------------------------
(αντικαταστήστε το email μου με το email που αντιστοιχεί στο προσωπικό κλειδί σας) Αυτή η εντολή θα έχει σαν αποτέλεσμα ένα αρχείο secret.tar.gpg που θα
μπορείτε μόνο εσείς να το διαβάσετε. Μπορείτε να ελέγξετε αν το σύστημα δουλεύει σωστά με τις εξής εντολές:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
$ gpg -d -o test.tar secret.tar.gpg
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Αυτή η εντολή θα αποκωδικοποιήσει το αρχείο και θα το σώσει σαν test.tar. Για να δοκιμάσουμε αν έχει την παραμικρή διαφορά από το αυθεντικό αρχείο που έχει τα
ευαίσθητα περιεχόμενα, δίνουμε
----------------------------------------------------------------------------------------------------------------------------------------------------------------
$ md5sum test.tar secret.tar
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Αν το αποτέλεσμα δεν είναι ακριβώς το ίδιο, κάτι δεν πήγε καλά. Αν το checksum όμως είναι το ίδιο, μπορούμε να σβήσουμε τον κατάλογο με τα ευαίσθητα αρχεία
----------------------------------------------------------------------------------------------------------------------------------------------------------------
$ rm -r secret/
----------------------------------------------------------------------------------------------------------------------------------------------------------------
και να αποκρυπτογραφήσουμε/αποσυμπιέσουμε ξανά τα περιεχόμενά του όποτε τα χρειαστούμε με τις εντολές
----------------------------------------------------------------------------------------------------------------------------------------------------------------
$ gpg -d -o secret.tar secret.tar.gpg
$ tar xvf secret.tar
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Αν τα παραπάνω σας φαίνονται υπερβολικά, θυμηθείτε ότι υπάρχουν εργαστήρια που διαβάζουν δεδομένα χωρίς κανένα πρόβλημα από [καμένους
υπολογιστές](http://www.datarr.com/tfds.html), συσκευές που [διαβάζουν οθόνες πίσω από τοίχους](http://www.sans.org/rr%20encryption/TEMPEST.php) και κυβερνήσεις
που θεωρούν σκόπιμο το [ψήσιμο](http://treachery.net/~jdyson/dod_cd_declassification.html) των CD που θέλουν να αποσύρουν\...
### [2. Δικτυακή ασφάλεια]{#s2}
Σε αυτή την ενότητα θα εξετάσουμε τις επιθέσεις DOS και τα μέτρα που μπορούμε να πάρουμε για να αμυνθούμε. Κατόπιν θα αναφέρουμε διάφορες βασικές αρχές για τις
δικτυακές σας περιπέτειες, που (ελπίζω) θα σας γλιτώσουν από πολλές δυσάρεστες γνωριμίες\...
### [2.1 Επιθέσεις Denial of Service (DoS)]{#ss2.1}
[Αυτές οι επιθέσεις](http://www.wikipedia.org/wiki%20Denial_of_service) έχουν σαν σκοπό τους να μην επιτρέψουν στο σύστημά μας να επιτελέσει τον στόχο του.
Δηλαδή, αν έχουμε κάποιον server που παρέχει υπηρεσίες email για μια εταιρεία, ο σκοπός της επίθεσης DoS είναι να μη μπορεί πλέον ο συγκεκριμένος server να
παρέχει αυτές τις υπηρεσίες. Οι επιθέσεις αυτές είναι ή μέρος μιας ιδιαίτερα συντονισμένης και μελετημένης επίθεσης (οπότε δε μας σώζει τίποτα), ή το τελευταίο
στάδιο της απογοήτευσης για έναν φιλόδοξο επιτιθέμενο που δεν μπορεί να μπει στο σύστημά μας και απλά καταφεύγει στην επίδειξη δύναμης, προσπαθώντας να μας
\"πετάξει έξω από το δίκτυο\".
Υπάρχουν πολλές περιπτώσεις στις οποίες επιθέσεις DoS έχουν χρησιμοποιηθεί για να επιτευχθεί κάποιος άλλος σκοπός. Παράδειγμα: Ο επιτιθέμενος καταφέρνει
προσωρινό DoS ενός SSH server για 10 κρίσιμα λεπτά. Σε αυτά τα 10 λεπτά, κάποιος νόμιμος χρήστης προσπαθεί να συνδεθεί στον SSH server, αλλά ο επιτιθέμενος
δίνει στο μηχάνημά του την IP του SSH server (που δεν μπορεί να απαντήσει), και προσκαλεί τον χρήστη να συνδεθεί στο μηχάνημά του. Ο χρήστης βλέπει ένα
[περίεργο μήνυμα](http://www.hpcvl.org/faqs/ssh_help.html#answer_4) ότι το fingerprint του server έχει αλλάξει, λέει \"ώχου μωρέ τώρα\" και επιλέγει να
συνδεθεί, αγνοώντας το μήνυμα. Ο επιτιθέμενος δέχεται την σύνδεση του χρήστη-θύματος, σταματάει το DoS του πραγματικού SSH server, και επιπροσθέτως του στέλνει
όλα τα πακέτα του θύματος. Αποτέλεσμα; Ο χρήστης κάνει κανονικά τη δουλειά του στον server, και ο επιτιθέμενος βλέπει και καταγράφει τα πάντα σε clear text,
μαθαίνοντας συνθηματικά, λογαριασμούς, άλλους κωδικούς, προσωπικά στοιχεία του θύματος, κτλ. Συγχαρητήρια, μόλις λάβατε μέρος σε μια επίθεση man-in-the-middle.
Το συγκεκριμένο σενάριο μπορεί να πραγματοποιηθεί πανεύκολα με παλιά SSH πρωτόκολλα και το εκπληκτικό πακέτο
[dsniff](http://naughty.monkey.org/~dugsong/dsniff/).
Δυστυχώς δεν υπάρχει καμία καθολική λύση για το πρόβλημα των DoS. Για την ακρίβεια, με την άνθιση των DDoS (Distributed Denial of Service) επιθέσεων, τα
πράγματα γίνονται διαρκώς χειρότερα. Πάντως, μερικά βήματα που μπορούμε να ακολουθήσουμε για να αντιμετωπίσουμε τις πιο παραδοσιακές επιθέσεις DoS ( [SYN
floods](http://www.cert.org/advisories/CA-1996-21.html) και ping floods) είναι τα εξής:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
#!/bin/bash
# Ενεργοποιούμε προστασία έναντι επιθέσεων SYN flood
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Μην απαντάς σε ICMP echo requests (προστατεύει έναντι ping floods)
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Επίσης μπορούμε να χρησιμοποιήσουμε το module LIMIT που παρέχει το [netfilter](http://netfilter.org), το σύστημα που διαχειρίζεται τα πακέτα στο επίπεδο του
πυρήνα, με κάτι σαν:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Αυτός ο κανόνας λέει στον πυρήνα να δέχεται μόνο μία νέα TCP σύνδεση ανά δευτερόλεπτο, και να αγνοεί τις υπόλοιπες. Γενικά ο πυρήνας έχει αρκετές δυνατότητες
άμυνας έναντι DoS επιθέσεων μέσω του συστήματος netfilter και των ρυθμίσεων στον κατάλογο /proc/sys/net/ipv4.
### [2.2 Network Visibility]{#ss2.2}
**\...ή, πόσο μεγάλο στόχο δίνουμε.**
Εκτός από τις DoS, που έχουν έναν πολύ συγκεκριμένο σκοπό, υπάρχουν και άλλες επιθέσεις, που συνήθως έχουν σκοπό την εκμετάλλευση κάποιου bug σε ένα service του
υπολογιστή μας. Παράδειγμα: Υπάρχουν \"εργαλεία\" που μπορεί να βρει ο καθένας στο Internet, και να δίνουν άμεσο root access αν χρησιμοποιηθούν εναντίον
συστημάτων που τρέχουν παλιές εκδόσεις του HTTP server Apache. Όσο γρήγορα και να αναβαθμίζουμε το σύστημά μας όταν ο διανομέας βγάζει patches που κλείνουν
αυτές τις τρύπες, υπάρχει πάντα μια ακαθόριστη περίοδος προτού γνωστοποιηθεί το bug, κατά την οποία το σύστημά μας είναι ευάλωτο. Ό,τι και να κάνουμε, και όσα
firewalls και να έχουμε, κάποτε συμβαίνει σε όλους.
Οπότε εκτός από τα άμεσα patches, μια **πολύ** καλή ιδέα είναι να μην έχετε κανένα ενεργό service στο σύστημά σας, εκτός από τα τελείως απαραίτητα. Έτσι οι
ευκαιρίες για εκμετάλλευση bugs ελαχιστοποιούνται, επειδή κανείς δεν μπορεί να εκμεταλλευτεί ένα πρόγραμμα που δεν τρέχει!
Αυτές οι επιθέσεις είναι πιο δύσκολες στον εντοπισμό από τις DoS, μιας και δεν δημιουργούν άμεσα προβλήματα στο σύστημά μας. Σχεδόν όλες ξεκινούν με
αναγνωριστικές κινήσεις, όπως portscans και προσπάθειες σύνδεσης σε συνήθεις πόρτες (80-http, 22-ssh, 23-telnet, 25-smtp, 110-pop3 κτλ). Η καλύτερη άμυνα είναι
να ρυθμίσουμε το μηχάνημά μας ώστε να μη δίνει καν στόχο. Η κλασσική λύση που ακούγεται παντού είναι ένα firewall, αλλά υπάρχει κάτι πολύ πιο σημαντικό: το να
κλείσουμε οποιαδήποτε πόρτα / δικτυακό service δεν χρειαζόμαστε.
Μία default εγκατάσταση μιας μοντέρνας \"φιλικής προς το χρήστη\" διανομής, συνήθως αφήνει πολλές περιττές πόρτες ανοιχτές στον υπολογιστή μας. Μπορούμε να
δούμε ποια services έχουμε ενεργά με ένα
# lsof -i
ή, από την μεριά του επιτιθέμενου (χρήσιμο για να καταλάβουμε τι μπορούν να δουν οι άλλοι για το μηχάνημά μας):
# nmap <η_ΙΡ_μου>
Για να δούμε τι βλέπω για το σύστημά μου:
# lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
privoxy 14769 privoxy 3u IPv4 173542 TCP localhost.localdomain:6969
(LISTEN)
# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:20:E0:8D:01:2D
inet addr:192.168.1.106 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:58578 errors:0 dropped:0 overruns:0 frame:0
TX packets:69317 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:34820912 (33.2 MiB) TX bytes:2989402 (2.8 MiB)
# nmap -p1-65535 192.168.1.106
Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
All 65535 scanned ports on 192.168.1.106 are: closed
Nmap run completed -- 1 IP address (1 host up) scanned in 100.306 seconds
Τί μας λένε τα παραπάνω; Με την εντολή lsof -i βλέπω μια υπηρεσία (privoxy) να \"ακούει\" (LISTEN) για τοπικές συνδέσεις TCP στην πόρτα 6969 (TCP
localhost.localdomain:6969). Αλλά το nmap μου λέει ότι όλες οι πόρτες είναι κλειστές! Τι γίνεται εδώ;
Ο privoxy στην συγκεκριμένη περίπτωση \"ακούει\" μόνο για συνδέσεις στη διεύθυνση localhost.localdomain:6969. Επειδή αυτό το όνομα δεν είναι δυνατόν να
χρησιμοποιηθεί για απομακρυσμένες δικτυακές συνδέσεις (είναι alias για το τοπικό μηχάνημα, και δεν μπορεί να χρησιμοποιηθεί σαν δικτυακό όνομα με το παρόν
σύστημα [DNS](http://www.webopedia.com/TERM/D/DNS.html)), ο privoxy φαίνεται σαν να μην υπάρχει όταν κάποιος εξετάζει τις πόρτες μας από το δίκτυο (γι\'αυτό
χρησιμοποίησα την εξωτερική μου IP στο nmap - αν είχα χρησιμοποιήσει την 127.0.0.1 θα είχα διαφορετικά αποτελέσματα). Για τις χάρες του privoxy θα μιλήσουμε
στην επόμενη ενότητα. Όπως είδαμε, δεν φαίνεται καν να υπάρχει από το δίκτυο. Άρα δεν το θεωρώ ευάλωτο σημείο.
Σε μια default εγκατάσταση κάποιας μοντέρνας διανομής, δυστυχώς έχουμε μεγάλες πιθανότητες να δούμε μια ελαφρώς διαφορετική εικόνα:
[root@helios root]# lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
privoxy 14769 privoxy 3u IPv4 173542 TCP localhost.localdomain:6969
(LISTEN)
tcpserver 14781 root 3u IPv4 176623 TCP *:44444 (LISTEN)
tcpserver 14783 root 3u IPv4 176629 TCP *:2121 (LISTEN)
smbd 14793 root 9u IPv4 176648 TCP *:netbios-ssn (LISTEN)
xinetd 14814 root 5u IPv4 179758 UDP *:ntalk
httpd 14831 root 3u IPv4 185996 TCP *:http (LISTEN)
httpd 14886 apache 3u IPv4 185996 TCP *:http (LISTEN)
Όλα αυτά τα (LISTEN) δεν είναι καθόλου απαραίτητα, εκτός κι\'αν ξέρετε τι κάνετε. Αν δεν ξέρετε τι σημαίνει κάποια καταχώρηση (όπως πχ. netbios-ssn), μπορείτε
να την αναζητήσετε στο αρχείο /etc/services για περισσότερες πληροφορίες:
$ grep netbios-ssn /etc/services
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
Το μηχάνημα που δεν δείχνει τίποτα να ακούει (LISTENing), είναι σχεδόν αόρατο στο δίκτυο. Είναι εξαιρετικά δύσκολο για κάποιον επιτιθέμενο να το βρει και να του
επιτεθεί. Πώς ξεφορτωνόμαστε όλα αυτά τα LISTEN λοιπόν;
Ανάλογα με τη διανομή που χρησιμοποιούμε ( [Debian](http://www.debian.org), [Slackware](http://www.slackware.com), [Red Hat](http://www.redhat.com),
[Gentoo](http://www.gentoo.org) κτλ), υπάρχουν διαφορετικοί τρόποι ελέγχου των υπηρεσιών (services) που είναι ενεργές στον υπολογιστή μας. Οι περισσότερες
διανομές GNU/Linux χρησιμοποιούν System V init scripts, δηλαδή αποθηκεύουν τα scripts που ελέγχουν τις υπηρεσίες στους καταλόγους /etc/rcX.d, όπου Χ είναι μια
τιμή από 0 έως 6. Αυτή η τιμή αντιστοιχεί στο runlevel του συστήματος. Το runlevel στο οποίο λειτουργεί το σύστημα αμέσως μετά την εκκίνησή του (boot) το
βρίσκουμε με ένα
# grep default /etc/inittab
Στο δικό μου σύστημα αυτό δίνει:
# The default runlevel.
id:2:initdefault:
που σημαίνει ότι αν θέλω να κάνω κάποιες υπηρεσίες να μην ενεργοποιούνται σε κάθε επανεκκίνηση, πρέπει να τις απενεργοποιήσω από το φάκελο /etc/rc2.d .
Αν κάνουμε ένα
ls -l
μέσα σε αυτό το φάκελο, θα δούμε ότι υπάρχουν πολλά symbolic links με τα ονόματα όλων των διαθέσιμων υπηρεσιών. Αν θέλουμε να μην ξεκινάει σε κάθε εκκίνηση ο
http daemon (httpd) (που είναι συνήθως ο [Apache](http://www.apache.org)), απλά σβήνουμε το link SXXhttpd (όπου ΧΧ η προτεραιότητα με την οποία ενεργοποιείται
κατά την εκκίνηση αυτό το service).
Ωραία, ο web server δεν θα ξεκινάει σε κάθε εκκίνηση από δω και στο εξής. Πώς όμως τον σταματάμε εδώ και τώρα;
Αν προσέξατε, όλα τα symbolic links στον κατάλογο που είμαστε \"δείχνουν\" σε αρχεία του καταλόγου ../init.d (δηλαδή στο /etc/init.d). Για να σταματήσουμε ή να
ξεκινήσουμε μια υπηρεσία αμέσως, καλούμε το script που την ελέγχει με την παράμετρο stop ή start:
Αυτή η εντολή ενεργοποιεί άμεσα τον HTTP server:
# /etc/init.d/httpd start
Αυτή η εντολή τον σταματάει:
# /etc/init.d/httpd stop
Με αυτό τον τρόπο μπορούμε να ξεφορτωθούμε και οποιεσδήποτε άλλες υπηρεσίες που είναι ενεργές χωρίς λόγο. Υπενθύμιση: σε ένα home PC, η εντολή
# lsof -i
δεν πρέπει να δείχνει τίποτα που να \"ακούει\" (LISTEN) για συνδέσεις από το δίκτυο (\*:port\_number).
ΣΗΜΕΙΩΣΗ: Υπάρχουν μερικές ειδικές περιπτώσεις, όπως το port 6000 (X11), το οποίο είναι περιττό για το 99% των συστημάτων για αποκλειστικά προσωπική χρήση, και
έχει γνωστά προβλήματα ασφάλειας (οποιοσδήποτε στο δίκτυο μπορεί να δει τι πληκτρολογείτε). Οπότε είναι πολύ καλή ιδέα να το κλείσετε, καλώντας τα X με την
παράμετρο -nolisten tcp:
$ startx -- -nolisten tcp
### [2.3 Firewalls]{#ss2.3}
Tα firewalls είναι προγράμματα ή συσκευές που ελέγχουν τα δεδομένα που ταξιδεύουν σε ένα δίκτυο. Σε προσωπικό επίπεδο, μπορούμε να τα χρησιμοποιήσουμε για να
ελέγξουμε τις δικτυακές συνδέσεις του υπολογιστή μας και να δυναμώσουμε την άμυνά μας έναντι δικτυακών επιθέσεων. Στο GNU/Linux το
[firewalling](http://www.wikipedia.org/wiki/firewall) γίνεται από το σύστημα [netfilter](http://www.netfilter.org), που ελέγχεται από το πρόγραμμα iptables.
Σε όλες τις μοντέρνες διανομές το σύστημα netfilter είναι ενεργοποιημένο στον πυρήνα Linux και το πρόγραμμα netfilter υπάρχει προεγκατεστημένο. Συνεπώς το μόνο
που έχουμε να κάνουμε είναι να δώσουμε τους κανονισμούς σύμφωνα με τους οποίους θα διαχειρίζεται ο πυρήνας τα δικτυακά δεδομένα που έρχονται και φεύγουν από τον
υπολογιστή μας.
Δεν θα μπούμε σε λεπτομέρειες, επειδή το firewalling είναι αρκετά μεγάλο θέμα. Θα σας δείξω τα rules που χρησιμοποιώ στο laptop μου, με σχόλια που θα εξηγούν τι
κάνει το κάθε rule. Το παρόν ruleset έχει βασιστεί στο εξαιρετικό [tutorial του James C. Stephens.](http://www.sns.ias.edu/~jns/security/iptables/index.html)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
#!/bin/bash
if [ -z $1 ]; then
# Δεν έχουμε command line argument, οπότε δεν αφήνουμε κανέναν να συνδεθεί με
SSH σε μας.
echo Disallowing SSH access...
NOSSH=1
else
# Έχουμε IP address στη γραμμή εντολών, που θέλουμε να συνδέεται σε μας με
SSH.
echo Allowing SSH access for $1...
fi
##############################
#### ΓΕΝΙΚΕΣ ΠΡΟΦΥΛΑΞΕΙΣ #####
##############################
## Μην απαντάς σε ping.
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
## Μην απαντάς σε broadcasts.
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
## Μη δέχεσαι source routed πακέτα.
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
## Μη κάνεις ICMP redirect.
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
## Προστασία έναντι περίεργων λαθών.
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
## Ενεργοποίησε το reverse path filtering.
for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do
/bin/echo "1" > ${interface}
done
## Σημείωσε στα system logs (/var/log/messages by default) τα πακέτα που
φαίνεται να έχουν ψεύτικες διευθύνσεις ή γενικώς να είναι ύποπτα.
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
## Μην λειτουργείς σαν router (μην προωθείς πακέτα σε άλλες διευθύνσεις).
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward
##################
#### FIREWALL ####
##################
## Φόρτωσε τα connection-tracking modules.
/sbin/modprobe ipt_state
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp #ports=2121
#/sbin/modprobe ipt_owner
## Καθάρισε τυχόν ενεργά rules
/sbin/iptables -F
## Διέγραψε τυχόν custom tables
/sbin/iptables -X
## Μηδένισε όλους τους μετρητές πακέτων
/sbin/iptables -Z
## By default κάνουμε DROP (αγνοούμε) όλα τα πακέτα (ώστε να περνάνε μόνο αυτά
που έχουν λόγο να περνάνε)
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT DROP
#####################
#### ΕΙΣΕΡΧΟΜΕΝΑ ####
#####################
## Δεχόμαστε όλες τις τοπικές συνδέσεις
/sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -i lo -j ACCEPT
## Δεχόμαστε πακέτα από όλες τις ήδη υπάρχουσες συνδέσεις (λόγω των υπολοίπων
rules, αναγκαστικά τις έχουμε ξεκινήσει εμείς οπότε υποθέτουμε ότι είναι
ασφαλείς)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
if [ $NOSSH ]; then
#Καθόμαστε.
echo
else
## Επέτρεψε συνδέσεις SSH από τη διεύθυνση που παρέχουμε στη γραμμή εντολών
/sbin/iptables -A INPUT -p tcp -s $1 --sport 1024: --dport 22 -j ACCEPT
fi
######################
##### ΕΞΕΡΧΟΜΕΝΑ #####
######################
## Δεχόμαστε τοπικές συνδέσεις
/sbin/iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
## SSH
/sbin/iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
## HTTP
/sbin/iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
## HTTPS
/sbin/iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
## POP3
/sbin/iptables -A OUTPUT -p tcp --dport 110 -j ACCEPT
## SMTP
/sbin/iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
## DNS
/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
## FTP (command)
/sbin/iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j
ACCEPT
## FTP (data::Active)
/sbin/iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j
ACCEPT
## FTP (data::Passive)
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state
ESTABLISHED,RELATED -j ACCEPT
if [ $NOSSH ]; then
echo
else
## Επιτρέπουμε στον SSH server μας να απαντήσει.
/sbin/iptables -A OUTPUT -p tcp --sport 22 --dport 1024: -m state --state
ESTABLISHED,RELATED -j ACCEPT
fi
## ICMP
/sbin/iptables -A OUTPUT -p icmp -j ACCEPT
## dict.org:2628
/sbin/iptables -A OUTPUT -p tcp -d 66.111.36.30 --dport 2628 -j ACCEPT
## Importing OpenPGP keys από pgp.mit.edu:11371
/sbin/iptables -A OUTPUT -p tcp -d 18.7.14.139 --dport 11371 -j ACCEPT
## JETDIRECT printing
/sbin/iptables -A OUTPUT -p tcp --dport 9100 -j ACCEPT
## Whois queries
/sbin/iptables -A OUTPUT -p tcp --dport 43 -j ACCEPT
## NTP updates
/sbin/iptables -A OUTPUT -p tcp -d 128.2.4.21/16 --dport 123 -j ACCEPT
/sbin/iptables -A OUTPUT -p udp --sport 123 -d 128.2.4.21/16 --dport 123 -j
ACCEPT
#################
#### LOGGING ####
#################
## Αυτά τα μηνύματα καταχωρούνται στο /var/log/messages
## Με ένα tail -f /var/log/messages σαν root τα παρακολουθούμε
## Log εισερχόμενα TCP πακέτα που απορρίφθηκαν.
/sbin/iptables -A INPUT -p tcp -j LOG --log-prefix "iptables:IN-TCP DROPPED:"
## Log εξερχόμενα TCP πακέτα που απορρίφθηκαν.
/sbin/iptables -A OUTPUT -p tcp -j LOG --log-prefix "iptables:OUT-TCP DROPPED:"
## Log οτιδήποτε άλλο που δεν πέρασε
#/sbin/iptables -A INPUT -j LOG --log-prefix "iptables:INCOMING DROPPED:"
/sbin/iptables -A OUTPUT -j LOG --log-prefix "iptables:OUTGOING DROPPED:"
## Τέλος του iptables script
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Μπορείτε να κατεβάσετε αυτό το script και [σε ASCII μορφή](fw.rules) για πιο εύκολη χρήση. Το script πρέπει να ανήκει στον root και να είναι executable:
# chown root:root fw.rules
# chmod 770 fw.rules
\...και το εκτελείτε. Τα αποτελέσματα τα βλέπετε με ένα
# iptables -L
### [3. Privacy]{#s3}
Σε αυτή την ενότητα θα εξετάσουμε τα βήματα που μπορούμε να ακολουθήσουμε για να δυσκολέψουμε το έργο των απανταχού
[spammers](http://www.wikipedia.org/wiki/Spamming), διαφημιστών, και λοιπών κερδοσκοπικών ατόμων και εταιρειών, που έχουν σαν σκοπό να μετατρέψουν το Internet
σε ένα μεγάλο εμπορικό κέντρο. Μόνο και μόνο διαβάζοντας σελίδες και στέλνοντας emails οι κινήσεις μας παρακολουθούνται και καταγράφονται για σκοπούς marketing.
Τα προσωπικά μας δεδομένα πωλούνται σε όσους μπορούν να πληρώσουν, και καταντάμε έρμαια μαζικών διαφημίσεων στα προσωπικά μας mailbox. Σε κάθε σελίδα που
διαβάζουμε υπάρχουν 5-10 διαφημιστικά banners που αναβοσβήνουν, αστράφτουν, κουνιούνται, έχουν ήχο\... κάνουν τα πάντα για να αποσπάσουν την προσοχή μας από τον
σκοπό που είχαμε όταν πήγαμε στην σελίδα (να διαβάσουμε τις πληροφορίες που έχει εκεί), και να μας κάνουν να θυμηθούμε το οποιοδήποτε προϊόν όταν το δούμε
μπροστά μας. Προσωπικά βρίσκω τις διαφημίσεις αυτές εξαιρετικά ενοχλητικές και την πώληση των προσωπικών μου πληροφοριών σε εταιρείες ανήθικη. Να τι κάνω για να
προστατέψω τον εαυτό μου λοιπόν.
### [3.1 Διαφημίσεις (banner ads)]{#ss3.1}
Τα banners έχουν αρχίσει να γίνονται ιδιαίτερα ενοχλητικά. Δεν μπορεί κανείς να διαβάσει μια σελίδα στο Internet χωρίς να βομβαρδίζεται από ενοχλητικά
[animation, ήχους και χρώματα](/34/img/ads.png), όλα να υπόσχονται λεφτά και εκπτώσεις και ευκαιρίες. Εκτός από την ενόχληση αυτή, τα banners χρησιμοποιούνται από
τους διαφημιστές για να παρακολουθούν τους netizens και να δημιουργούν καταναλωτικά προφίλ για σκοπούς marketing (βλ. ενότητα για cookies παρακάτω). Ευτυχώς
είναι αρκετά εύκολο να [απαλλαγεί](/34/img/noads.png) κανείς από αυτά, χάρη στους proxy servers που υπάρχουν ελεύθερα διαθέσιμοι.
O [privoxy](http://www.privoxy.org) είναι ένας anonymizing proxy. Ένα πρόγραμμα, δηλαδή, που δέχεται αιτήσεις για νέες σελίδες από τον browser σας, και τις
φέρνει από το δίκτυο. Όταν τις σερβίρει στον browser για να τις δείξει στην οθόνη, διαβάζει τον κώδικα της σελίδας και [αντικαθιστά τις
διαφημίσεις](http://www.andrew.cmu.edu/~apapadop/linux/images/bloomberg_privoxy.png) με άσπρα κουτάκια (που δεν φαίνονται) είτε ένα σήμα που δείχνει στον χρήστη
ότι υπήρχε μια διαφήμιση εκεί, και τώρα δεν την βλέπει. Έτσι βλέπουμε μόνο αυτό που θέλουμε, και όχι διαφημίσεις που μας αποσπούν την προσοχή.
### [3.2 Cookies]{#ss3.2}
Τα cookies είναι μικρά αρχεία κειμένου που οποιοδήποτε site μπορεί να αποθηκεύσει στον υπολογιστή μας. Έχουν δημιουργηθεί για να ξεπεράσουν κάποια [προβλήματα
σχεδιασμού του πρωτοκόλλου HTTP](http://www.wikipedia.org/wiki/HTTP_cookie) που χρησιμοποιείται για web browsing. Επειδή το HTTP είναι stateless, δηλαδή δεν
μπορεί να καταλάβει αν κάποιο click που κάνουμε είναι συνδεμένο με προηγούμενες ενέργειές μας στην ίδια σελίδα ή όχι, εφευρέθηκαν τα cookies. Τώρα, όταν κάνω
login σε κάποιο δικτυακό χώρο που χρειάζεται να ελέγχει την πρόσβαση των χρηστών του (π.χ. online email service), το site μου δίνει ένα cookie που περιέχει
κωδικοποιημένες τις πληροφορίες του λογαριασμού μου. Έτσι, όταν ζητάω να δω το inbox μου, το εκάστοτε site ξέρει ότι είμαι ο νόμιμος χρήστης αυτού του
λογαριασμού, και μου δείχνει τα email μου. Αν δεν υπήρχε αυτός ο μηχανισμός για να παρακολουθεί πχ. το Yahoo! ποιος χρήστης ζητάει να δει τι, θα ήταν δυνατό να
διαβάζουν όλοι τα emails όλων των άλλων χρηστών.
Όλα καλά και άγια ως εδώ με τα cookies. Τα προβλήματα ξεκινούν όταν διάφοροι εξυπνάκηδες αρχίζουν να εκμεταλλεύονται αυτό το μηχανισμό για να μας παρακολουθούν
για διαφημιστικούς λόγους. Υπάρχουν εταιρείες όπως η απεχθής Doubleclick, που μοιράζουν άφθονα cookies σε κάθε ευκαιρία, και μετά παρακολουθούν το πού πάει ο
κάτοχός τους.
Ένα παράδειγμα. Είχα ένα λογαριασμό για free web email στο rocketmail.com και ήμουν πολύ ικανοποιημένος. Ούτε spam, ούτε διαφημίσεις, ούτε τίποτα. Όταν το
rocketmail.com αγοράστηκε από το Yahoo! άρχισαν τα προβλήματα. Κάθε φορά που χρησιμοποιώ το λογαριασμό μου, το Yahoo! προσπαθεί να μου δώσει ένα cookie εκ
μέρους της Doubleckick. Αν δεν προστάτευα τον εαυτό μου απορρίπτοντας το cookie, οποιαδήποτε άλλα sites είχαν διαφημίσεις της Doubleclick (και είναι λίγα που
**δεν** έχουν) θα μπορούσαν να μάθουν τη διεύθυνση email μου. Καθώς πήγαινα σε περισσότερα sites, με το cookie της Doubleckick στον υπολογιστή μου, οι συνήθειές
μου θα καταγράφονταν και θα συσχετιζόντουσαν για να δημιουργήσουν ένα καταναλωτικό προφίλ. Τι ενδιαφέρει αυτόn τον καταναλωτή; Σε τι δικτυακούς τόπους συχνάζει;
Πόσο χρόνο κάθεται σε τι είδους σελίδες; Αυτό το προφίλ είναι έτοιμο να πουληθεί σε οποιονδήποτε ενδιαφερόμενο κάνει direct marketing. Σε όλη αυτή τη διαδικασία
εγώ ουδέποτε έχω συμφωνήσει να φτιαχτεί τέτοιο προφίλ, να παρακολουθούνται οι κινήσεις μου, και να δέχομαι spam email από εταιρείες που δεν ξέρω καν. Και όμως,
δεχόμενος το cookie, έχω κάνει όλα τα παραπάνω.
Τα cookies είναι άχρηστα για την σωστή λειτουργία του δικτυακού τόπου στη συντριπτική πλειοψηφία των περιπτώσεων. Ο γενικός κανόνας είναι ότι αν δεν χρειάζεται
να κάνετε login κάπου (με username και password), τότε δεν χρειάζεστε και τα cookies από εκείνο το site.
Για να αμυνθούμε έναντι των cookies, πρέπει απλά να ρυθμίσουμε τον browser μας να μας ρωτάει τι να κάνει κάθε φορά που κάποιος προσπαθεί να μας δώσει cookie.
Και ο [Mozilla](/34/img/mozilla_cookie.png) και ο [Konqueror](/34/img/konqueror_cookie.png) έχουν πολύ ωραίο τρόπο αντιμετώπισης των cookies. Μπορούν να ρυθμιστούν να
θυμούνται την επιλογή του χρήστη (αποδοχή ή απόρριψη cookies από ένα συγκεκριμένο site), και να σβήνουν όλα τα cookies με το που κλείνουμε τον browser. Έτσι
κρατάμε τις χρήσιμες λειτουργίες των cookies επιλεκτικά, όπου τις χρειαζόμαστε, και σιγουρεύουμε ότι δεν μπορεί κανείς να μας παρακολουθήσει την επόμενη φορά
που θα ανοίξουμε τον browser μας.
### [3.3 Web bugs]{#ss3.3}
Τα web bugs είναι αόρατες εικόνες (1x1 pixel transparent GIFs, συνήθως) που στέλνονται σαν μέρος ενός HTML email, και πρέπει να φορτωθούν από το Internet όταν
το email ανοιχτεί. Τι σημασία έχει αυτό, σας ακούω να ρωτάτε.
Ας πούμε ότι είμαι ένας spammer. Τρέχω έναν web server και έναν mail server δικό μου. Στέλνω 10,000 email ένα πρωί, μη ξέροντας ποιες από αυτές τις διευθύνσεις
είναι πραγματικές και ποιες έχουν καταργηθεί. Επίσης θέλω να μετρήσω το πόσο γρήγορα φτάνουν στα θύματά μου (καταναλωτές) οι διαφημίσεις που στέλνω. Πώς θα το
κάνω αυτό;
Το email που στέλνω είναι σε HTML. Περιέχει στον κώδικα της σελίδας μια αόρατη εικόνα (transparent GIF), η πηγή του οποίου είναι ο web server μου. Συνεπώς μόλις
κάποιο θύμα ανοίξει αυτό το email, ο mail client του θα προσπαθήσει να του δείξει την εικόνα, άρα θα προσπαθήσει να την κατεβάσει από το Internet, και πιο
συγκεκριμένα από τον δικό μου web server. Αλλά οι web servers έχουν logs που δείχνουν ποια διεύθυνση (ΙΡ), ζήτησε ποιο αρχείο (το GIFάκι), ποιά ώρα. Συνεπώς
μαθαίνω ότι κάποιος στο domain 194.15.60.x (που μπορώ εύκολα να μάθω πως ανήκει σε subnet ενός συγκεκριμένου Internet Service Provider - ας πούμε της OTEnet)
άνοιξε το email μου στις 11:34 ακριβώς το πρωί.
Αμέσως ξέρω ότι κάποια από τις διευθύνσεις \@otenet.gr που έχω είναι πιθανότατα πραγματικό mailbox κάποιου θύματος, το οποίο διαβάζει τα mail του αρκετά συχνά.
Άρα αρχίζω να χτυπάω τις διευθύνσεις \@otenet.gr πιο πολύ με spam από δω και πέρα.
Η μόνη άμυνα για αυτή την παραβίαση του προσωπικού μας χώρου είναι η απαγόρευση των HTML email. Ο [Mozilla Mail](/34/img/moz_mail.png) και το [KMail](/34/img/kmail.png)
έχουν ρυθμίσεις για να σας βοηθήσουν να αντιμετωπίσετε τα web bugs, που είναι τελικά τελείως άχρηστα σε εμάς, και πολύ χρήσιμα στους spammers.
**Συμπέρασμα:**
Οι απειλές είναι πολλές, άλλα υπάρχουν και πολλά που μπορούμε να κάνουμε για να προστατευθούμε. Με λίγη προσοχή και τη δύναμη των εργαλείων του GNU/Linux,
Παράθεση σε νέο ζήτημα Αντιγραφή permalink