Tallinn – day 2

(Έμαθα πως πρέπει να παραδώσω έκθεση στην υπηρεσία σχετικά με το RIPE-54 -λογικό αφού πλήρωσαν τα έξοδα- οπότε κοίτα να δεις, η καταγραφή στο blog με βοηθάει!)

[ 2007-05-08 ]

Αν κάποιος θέλει να καταλάβει τι σημαίνει “μεγάλο δίκτυο” του αρκεί η πρώτη διαφάνεια του Alain Durand “IPv6 @ Comcast: Managing 100+ Million IP addresses“[pdf document]. Την (άμεση) ανάγκη τους για το IPv6 την τοποθέτησε πολύ απλά: “Το δίκτυο 10 και οι υπόλοιπες διευθύνσεις του RFC1918 δεν μας φτάνουν και κανείς μας δεν είχε τα @@ να πάει να πει στον CEO μας πως δεν μπορούμε να εγγράψουμε καινούργιο πελάτη”. Έτσι για αυτούς το πέρασμα στο IPv6 ήταν μονόδρομος.

Αυτή τη στιγμή η Comcast δίνει υπηρεσίες 3-play, αλλά όχι σε μία combo συσκευή. Υπολογίζουν πως κάποια στιγμή θα μπορούν να το κάνουν, αν και δεν είναι τόσο απαραίτητο γιατί ο πελάτης μπορεί να θέλει το Internet-feed στο υπόγειο, TV στο σαλόνι και τηλέφωνο σε άλλο σημείο του σπιτιού, οπότε ο διαχωρισμός βολεύει (σημ: Βέβαια αυτός ο διαχωρισμός οδηγεί και σε πιο γρήγορη κατανάλωση του IPv4 space, αλλά το δίκτυό τους είναι έτσι κι αλλιώς μεγάλο). Υπολογίζουν πως χρειάζονται 8 με 9 IP addresses σε κάθε σπίτι.

Ο σχεδιασμός για την εισαγωγή του IPv6 στο δίκτυο της Comcast ξεκίνησε το 2005 (και μόνο στα network edges, όχι στον τελικό χρήστη). IPv6 μπαίνει όπου είναι απαραίτητο και μόνο. Το deployment ξεκινάει από το core προς τα edges και υπολογίζουν πως θα έχουν full-scale deployment το 2008. Να πως προχώρησαν (με baby steps κατά τα λεγόμενα του A. Durand):

  1. IPv6 addresses στους routers του δικτύου (7/2006). Το μόνο που μπορούσαν να κάνουν οι administrators ήταν ping από το ένα interface στο άλλο.
  2. Ενεργοποίηση IPv6 routing (11/2006). Τώρα οι administrators κάνανε και traceroute, telnet σε άλλο router κ.λπ.
  3. Εγκατάσταση, customization και έλεγχος των monitoring tools.
  4. Εντοπισμός προβλημάτων σχετικών με τις υλοποιήσεις σε διάφορες MIB.
  5. Τελική επιλογή internal routing protocols: OSPFv2 για IPv4 και IS-IS για IPv6

Αυτό που είναι ενδιαφέρον είναι η απόφασή τους να μην φτιάξουν ένα “IPv6 lab”. Ένα IPv6 lab αποξενώνει τους operators του δικτύου κορμού (που φέρνει και τα λεφτά) από τις εξελίξεις. Ενεργοποιώντας με baby steps το IPv6 στο δίκτυο κορμού κάνεις τους operators συμμέτοχους στο νέο παιχνίδι κάτι που είναι προτιμότερο από το να τους το εμφανίζεις μία μέρα σαν το νέο δεδομένο. Στα πλαίσια αυτά (της ψυχολογικής προετοιμασίας των operators) τύπωσαν και ένα μπλουζάκι με ένα καταπληκτικό (IMO) motto:

“96 more bits, no magic”

The cost of NOT deploying IPv6

Συνήθως οι πάροχοι τεκμηριώνουν την αναβλητικότητά τους για να προχωρήσουν σε IPv6 deployment χρησιμοποιώντας τα ακόλουθα επιχειρήματα:

  1. Training costs. Οι εταιρίες συνήθως το βλέπουν σαν το μεγαλύτερο κόστος. Όχι μόνο οικονομικό. Συνήθως ένα training programme διαρκεί 5 ημέρες, οπότε αυτές τις 5 ημέρες οι operators τους είναι έξω από το δίκτυο. Πολλές φορές δεν έχουν αυτά τα περιθώρια.
  2. Network upgrade costs. Αυτά είναι τα πραγματικά κόστη. Από την άλλη όμως όλο το σύγχρονο hardware είναι IPv6 ready. Οπότε με ένα προσεκτικό σχεδιασμό για την ανανέωση των ενεργών στοιχείων, η αναβάθμιση σε εξοπλισμό IPv6 ready μπορεί να γίνει εξαιρετικά ομαλά.
  3. Dual stack operation. Το να έχει αναπτύξει κανείς ένα δίκτυο IPV6, αυτή τη στιγμή σημαίνει πρακτικά τη διαχείριση δύο δικτύων αντί για ένα. Και αυτό είναι ένα πραγματικό κόστος. Είναι όμως ένα κόστος που δεν θα φύγει για πολύ καιρό. Όταν έρθει η ώρα του IPv6, έτσι κι αλλιώς θα έχουμε dual-stack networks γιατί το IPv4 δεν θα γίνει phase-out για πολύ καιρό. Οπότε όσο πιο γρήγορα προετοιμαστεί κανείς, τόσο καλύτερο.

Πολλοί φυσικά υποστηρίζουν πως αυτή η στιγμή μπορεί να καθυστερήσει πολλά χρόνια ακόμα, χάρη στο NAT. Είναι όμως έτσι τελικά;

Στη γενική περίπτωση το NAT είναι βολικό για τον τελικό χρήστη, εκτός κι αν θέλει να αρχίσει να κάνει “κάτι παραπάνω” (π.χ. reverse NAT, VPN ανάμεσα σε δύο sites, κ.ο.κ.). Ειδικά όταν η επίλυση ενός προβλήματος πελάτη που κάνει χρήση ΝΑΤ κοστίζει όσο το κέρδος που αποφέρει ο πελάτης για ένα χρόνο. Αν δε χρειαστεί και second level support, τότε κοστίζει όσο το κέρδος που θα αποφέρει ο πελάτης για όσο χρόνο μείνει πελάτης. Και φυσικά να μη ξεχνάμε την ψευδαίσθηση της ασφάλειας που δίνει το NAT.

Χάρη στα Windows Vista σε περίπου 1.5 χρόνο θα έχουμε πολλούς χρηστες IPv6-ready. Αυτό είναι καλό. Η ύπαρξη δε tunnel brokers, 6to4 tunnels και του Teredo μπορεί να βοηθήσει να γίνει αυτή η μετάβαση χωρίς καν την ουσιαστική εμπλοκή των ISPs.

Και το καλύτερο της παρουσίασης: “I am told that Microsoft runs its complete internal network on IPv6”.

Spamhaus presentation

Το Spamhaus ξεκίνησε τα late-90s από τον Steve Linford και σήμερα είναι περίπου 30 άτομα. Αρχικά ήταν ένα evening job που κατέληξε καθημερινή εργασία.

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

Οι κύριες DNSBLs που έχει υλοποιήσει το Spamhaus project είναι:

  1. SBL: 100% human input
  2. XBL: Totally automated
  3. PBL: Εθελοντική λίστα στην οποία οι ISPs δηλώνουν τα netblocks τα οποία δεν έχουν λόγο να χρησιμοποιούν απ’ευθείας mail servers εκτός του δικτύου τους.
  4. ΖΕΝ: SBL+XBL+PBL

Επίσης συντηρούν το ROKSO (Registry of Known Spammer Operations). 200 επιχειρήσεις παράγουν το 80% του spam. Για τον ίδιο λόγο συντηρούν και τη λίστα DROP (Don’t Route Or Peer) που περιέχει 100% address space που έχει αποδοθεί σε spam operators.

  • 982565: Ήταν τα νέα zombies που ανακάλυψε το σύστημα που συντηρεί τη XBL στις 2007/05/08.
  • 36 δευτερόλεπτα είναι ο χρόνος που μεσολαβεί από την μόλυνση ενός PC μέχρι να εμφανιστεί το πρώτο spam από το PC αυτό.

Τα zombies είναι πλέον αρκετά sophisticated: έχουν proxies με ACLs και rootkits.

Το ουσιαστικό πρόβλημα με τα zombie networks είναι το command & control. Τελικά ένας πολύ μικρός αριθμός IP διευθύνσεων προκαλεί όλο το πρόβλημα. Το 65% αυτών είναι στη Β. Αμερική (και τα περισσότερα στην Καλιφόρνια).

Το δυσκολότερο είδος zombie network που υπάρχει αυτή τη στιγμή είναι το “Yambo hosting”. Στηρίζεται σε HTTP και DNS hosting πάνω σε zombie networks με unidirectional proxies με ACLs. Είναι εξαιρετικά δύσκολο να εντοπιστεί γιατί τα URL σερβίρονται από 5 – 10 IP διευθύνσεις και η πληροφορία που σερβίρει το DNS έχει διάρκεια 5 – 10 λεπτά (μετά δείχνει σε νέο zombie).

Οι τρόποι για να αντιμετωπιστεί είναι να υπάρχει εποπτεία των DNS traffic patterns στο δίκτυο του ISP και να παρακολουθείται για ανωμαλίες επί αυτών των προτύπων.

Και φυσικά: Block port 25/tcp !!!

(σημ.: Πες τα χρυσόστομε! Από όσο είμαι σε θέση να ξέρω από τις εργασίες του antispam WG της ΑΠΔΠΧ τα εμπορικά τμήματα των παραδοσιακών Ελληνικών ISPs δεν θέλουν ούτε να το σκέφτονται σαν προοπτική αυτό. Πράγμα που είναι εξαιρετικά κοντόφθαλμο: Προτιμάνε να παίρνουν τα EUR20/μήνα από τον Spammer και να μπαίνουν τα blocks τους σε DNSBLs από το να κάνουν block το port 25/tcp και να τελειώνουμε με τον βασικό τρόπο μετάδοσης των zombies. Αναρωτιέμαι, τι κοστίζει παραπάνω άραγε;

Και έτσι μείναμε μοναχικοί υποστηρικτές της ιδέας εμείς και το ΕΔΕΤ).

Κλείνοντας, δύο παρατηρήσεις του Richard Cox από την παρουσίαση:

“Ladies and gentlemen, zombies and zombie networks are the currency of the digital underground.”

και:

“If we as an industry do not stop spam, we will find politicians trying to. Do we really want that?”

Αλήθεια, αυτό θέλουμε;

(day 1)

3 thoughts on “Tallinn – day 2

  1. “If we as an industry do not stop spam, we will find politicians trying to. Do we really want that?”

    Φαίνεται ότι κάποιοι αυτό θέλουν. Δεν εξηγείται διαφορετικά γιατί όλος ο πανικός με τα spams και η αδυναμία να τα σταματήσουν.

    Δεν ξέρω αν κάνω λάθος αλλά όλη η κίνηση για spamming από κάποιο backbone περνάει που σίγουρα δεν ανήκει σε εμένα, εσένα και σε όσους έχουν 10-100Κ στην τσέπη.

  2. > Και φυσικά: Block port 25/tcp !!!

    Block port 25/TCP και καντε να σας ανεβοκατεβαζουν καντηλια – μαζι με τους καντηλαναφτες – ολοι οσοι θελουν να χρησιμοποιουν τον δικο τους SMTP server σαν relay αντι για τον δικο σας, επειδη δεν εχουν πειστει ακομα για το ορθο της αποψης οτι αγοραζοντας IP connectivity απο τον Μητσο, εισαι υποχρεωμενος να χρησιμοποιεις με το στανιο και τις higher-level υπηρεσιες του Μητσου.

    Υπολογιζω οτι αυτοι ειναι γυρω στα… μμμ… πεντε ατομα. Και παροτι υποψιαζομαι οτι και οι πεντε ξερουν αρκετες λυσεις στο συγκεκριμενο προβλημα, γνωριζω οτι τουλαχιστον ο ενας, βαριεται να τις υλοποιησει :)

    Αν επιμενετε παντως στο block port 25/TCP, τουλαχιστον καντε κατι εξυπνοτερο απο το :

    554 void.tee.gr ESMTP not accepting messages

    :)

  3. Χεχ,

    Χρήστο αυτό συμβαίνει στον void γιατί του γίνεται redirect πολύ (μα πάρα πολύ) traffic από infected machines. Αρχικά ο void δεν υπήρχε καν (εξού και το όνομα).

    Η γνώμη μου είναι πως όποιος θέλει να έχει relay έξω από τον πάροχο που του δίνει IP feed, καλό είναι να μάθει να χρησιμοποιεί το port 587/tcp.

    Επίσης όπως καταλαβαίνεις, ο void υπάρχει ακριβώς γιατί αυτοί οι 5 χρήστες κάνουν τόση φασαρία που είναι πιο φτηνό να υπάρχει (έστω και έτσι) από το να υπάρχει πραγματικό block.

    Άσε που οι χρήστες που είναι με static IP δεν περνάνε από τον void.

    :)

Leave a comment