Έτος: 1999. Περιοχή Αττική.  Ένας αρκετά ισχυρός σεισμός μεγέθους 5.7 της κλίμακας ρίχτερ, με επίκεντρο την Πάρνηθα πλήττει το λεκανοπέδιο (και όχι μόνο) στις 14:57. Έντρομοι οι κάτοικοι βγαίνουν στους δρόμους. Προσπαθούν να επικοινωνήσουν με τους δικούς τους ανθρώπους. Μάταια! Τα κινητά τηλέφωνα δεν... ανταποκρίνονται! Μα τι έγινε; Μήπως γκρεμίστηκε καμιά κεντρική κεραία του ΟΤΕ; Γιατί δεν έχουμε επικοινωνία; Τι συνέβει;

Χμμ... το αυτονόητο. Αυτό που λέγαμε κάποτε (εμείς οι πιο παλιοί!!) "μπλόκαραν" οι γραμμές! Οι βάσεις δεδομένων των παρόχων κινητής τηλεφωνίας δεν ήταν προετοιμασμένες να δεχθούν ένα τόσο μεγάλο αριθμό κλήσεων και "παρέδωσαν" πνεύμα ή αλλιώς αρνήθηκαν να εξυπηρετήσουν και σε πιο Ελληνικά κάνανε deny of services (DOS - μην μπερδεύετε το DOS (Denial Of Services) με το γνωστό και μη εξαιρεταίο DOS (Disk Operating System) που σαν λειτουργικό σύστημα μεσουρανούσε τη 10ετία του '80. Είναι δύο εντελώς διαφορετικά πράγματα.).

Χωρίς να το θέλουνε οι Αθηναίοι πραγματοποίησαν μια επίθεση Denial Of Services (DOS attack) ή καλύτερα Distributed Denial Of Services (DDOS attack) γιατί ήτανε παραπάνω από... ένας, στους servers των παρόχων κινητής τηλεφωνίας. Φυσικό επακόλουθο είναι οι servers αυτοί να "γονατίσουν" μην μπορώντας να εξυπηρετήσουν τόσες πολλές αιτήσεις κλήσεων μαζεμένες!

Παρόμοιες επιθέσεις μπορούν να γίνουν σε οποιονδήποτε server ή σύστημα εξυπηρέτησης γενικότερα. Εντάξει, δεν έχουμε σκοπό να κάνουμε συστημική ανάλυση (σε αυτό το άρθρο τουλάχιστον!) αλλά θα πρέπει να αναφέρουμε οτι τέτοιες επιθέσεις δεν γίνονται πάντα "κατά λάθος" ή λόγω "συγκυριών". Μπορούν να συμβούν (ηθελημένα ή μη) από ένα απλό pc χωρίς σύνδεση στο internet μέχρι σε ένα... κοινωνικό σύστημα!! Ας περιοριστούμε όμως στον τομέα μας, που αφορά έναν πιο virtual κόσμο: τον ηλεκτρονικό.

Κάθε ενέργεια που οδηγεί ένα σύστημα στο να μην μπορεί να ανταποκριθεί για αυτό που φτιάχτηκε μπορεί να καταταχθεί (άλλοτε περισσότερο και άλλοτε λιγότερο) στην κατηγορία των επιθέσεων DOS. Είναι αυτό που λέμε κοινά: "Μα τι έκανες βρε παιδί μου εκεί? Το χάλασες!!!" ;-)

Εικόνα 1: Η κλασική οθόνη του firefox, που μας πληροφορεί οτι ο server δεν... ανταποκρίνεται!

Στον κόσμο των υπολογιστών το φαινόμενο αυτό είναι αρκετά συχνό και μπορούμε να το χωρίσουμε σε δύο βασικές κατηγορίες όσο αφορά στην "πρόθεση" του επιτηθέμενου. Στην πρώτη κατηγορία έχουμε τις καλές προθέσεις. Δηλαδή δεν υπήρχε δόλος, πρόθεση στο να προκληθεί ζημιά. Δεν θα ασχοληθούμε πολύ με αυτές τις επιθέσεις, απλά θα αναφέρουμε ένα πράδειγμα:
Έστω οτι διατηρούμε ένα forum (ας πούμε για security) σε κάποιον server στο internet. Το forum μας δεν είναι πολυσύχναστο, άντε το πολύ καμιά 10αριά άτομα να μπαίνουνε την ημέρα. Μια δεδομένη χρονική στιγμή όμως ανακαλύπτουμε μια πολύ μεγάλη "τρύπα" ασφάλειας σε κάποιο πολύ γνωστό λειτουργικό σύστημα (ονόματα δεν λέμε!! - όσο κι αν μας πιέσετε) και την δημοσιεύουμε σε ένα ποστ με τον τίτλο "Μεγάλη Τρύπα!". Η "Μεγάλη Τρύπα!" παίρνει δημοσιότητα και αναφέρετε σαν link στο γνωστό http://slashdot.org/, δηλαδή σε ένα site που δέχεται καμια 200 χιλιάδες επισκέψεις ημερησιως! Ξαφνικά, εκατοντάδες users αρχίζουν να επισκέπτονται το site μας για να δούνε την "Μεγάλη Τρύπα!". Αν ο server μας δεν είναι έτοιμος να ανταπεξέλθει στις νέες συνθήκες, απλά θα σταματήσει να εξυπηρετεί της κλήσεις (βλέπε εικόνα 1 - φαινόμενο slashdot!!). Στο τέλος του άρθρου θα πούμε μερικά μικρά μυστικά που θα μπορούσαν να κάνουν τον server μας να μπορεί (ή τουλάχιστον να προσπαθεί!) να ανταποκρίνεται σε τέτοιες καταστάσεις.

Εικόνα 2: Το site του γνωστού μας, αμέριμνο πριν δεχτεί την επίθεση (εδώ φαίνεται στον firefox 3 μέσα από ένα σύστημα linux)!

Ας έρθουμε τώρα στην σκοτεινή πλευρά! (εδώ κανονικά ξεκινάει να παίζει και η μουσική του... twilight zone http://www.youtube.com/watch?v=NzlG28B-R8Y, δηστυχώς όμως δεν έχουμε την δυνατότητα να το κάνουμε αυτό... άμεσα  ;-)
Τις επιθέσεις που γίνονται επίτηδες με σκοπό να σταματήσει ο server να ανταποκρίνεται. Τα είδη των επιθέσεων είναι πάρα πολλά (http://tinyurl.com/2c59m4) και δεν μας ενδιαφέρει η απλή παράθεση τους η οποία μπορεί να βρεθεί πολύ εύκολα στο net. Άλλοστε εμάς μας αφορά η... ανορθόδοξη προσέγγιση των θεμάτων ;-)
θα παρουσιάσουμε ένα παραγματικό παράδειγμα επίθεσης (μέ όλα τα... απότελέσματα του!!) από windows Vista. Επίσης, θα δείξουμε πως φτιάχνονται τέτοια προγράμματα, δείχνοντας ένα απλό πρόγραμμα σε γλώσσα perl, αυτή τη φορά σε Linux Ubuntu. Θα δείξουμε, ακόμα, πως δοκιμάσαμε αυτό το πρόγραμμα με θύμα (αυτή τη φορά) τον... εαυτό μας! Τέλος, θα αναφέρουμε τεχνικές αντιμετώπισης ηθελημένων ή μη επιθέσεων dos.

Πριν ξεκινήσουμε, όμως, πρέπει να αναφέρουμε οτι απαγορεύεται αυστηρά η χρήση και η εκτέλεση προγραμμάτων για επιθέσεις DOS παρά μόνο αν είμαστε οι ιδιοκτήτες του site και ο server είναι δικός μας ή το κάνουμε με την σύμφωνη γνώμη του ιδιοκτήτη! θέλουμε να σας τονίσουμε να μην κάνετε επιπόλαιη ή μη εξουσιοδοτημένη χρήση όσων παρουσιαστούν παρακάτω μιας και είναι πολύ πιθανό ο administrator του προς επίθεση server να κινηθεί νομικά εναντίον σας και να αντιμετωπίσετε σοβαρές κυρώσεις.

Επίθεση από Windows Vista

Η πιο κοινή επίθεση είναι να στείλουμε τυχαία δεδομένα - σκουπίδια(flood) στον server στον οποίο θέλουμε να δοκιμάσουμε την αντοχή. Τα δεδομένα αυτά θα είναι τυχαία bytes, kBytes ή και Μβytes και θα αποστέλονται από ένα πρόγραμμα το οποίο θα δημιουργεί (στην μνήμη) πολλαπλές συνδέσεις (multiple asynchronous sockets) με τον server για να αυξήσει τόσο τον όγκο των δεδομένων που στέλονται όσο και το πλήθος των συνδέσεων. Το αποτέλεσμα όπως θα δείτε είναι η άρνηση εξυπηρέτησης από τον server. Το αξιοσημείωτο στην περίπτωση αυτή δεν είναι τόσο το αποτέλεσμα όσο οι... παράπλευρες απώλειες όπως θα δείτε στην συνέχεια, καθώς επίσης και η αντίδραση του ιδιοκτήτη της υπηρεσίας Host που (ομολογουμένως) είχε όλο το δίκιο να διαμαρτυρηθεί!!
Θα σας δείξουμε λοιπόν ένα πραγματικό και "πλήρη" κύκλο μιας επίθεσης!

Για την συγκεκριμένη επίθεση χρησιμποιήσαμε ένα έτοιμο πρόγραμμα το οποίο κυκλοφορεί στο εμπόριο και το οποίο χρησιμοποιείται για δοκιμές "αντοχής" σε servers από επιθέσεις DOS (servers crash tests). Το πρόγραμμα αυτό είναι το DoSHTTP (εικόνα 3) και μπορείτε να κατεβάσετε μια evaluation έκδοση από το site της εταιρίας που το δημιούργησε (http://socketsoft.net/).

Εικόνα 3: Ένα πρόγραμμα για δοκιμές "αντοχής" σε επιθέσης DOS (servers crash tests)

Το site που θα δεχτεί την επίθεση είναι ένα ελληνικό portal/forum (εικόνα 2) που αφορά στο security του οποίου γνωρίζουμε τους διαχειριστές του και είχαμε την σύμφωνη γνώμη τους. Το μόνο που είχαμε να κάνουμε είναι να τρέξουμε το πρόγραμμα και να δώσουμε την διεύθυνση του site θύματος (εικόνα 3). Στο πεδία της φόρμας αφήσαμε τα defaults: Ο user agent αφορά στις πληροφορίες του http header και στα πεδία Sockets (συνδέσεις) και Requests (τύπος αιτήσεων) βάλαμε αντίστοιχα 500 (συνδέσεις) και continuous (συνεχής συνδέσεις με τον server – περισσότερες λεπτομέρειες δείτε παρακάτω στο "Τρόποι Προστασίας"). Πατώντας το κουμπάκι "Start Flood" το πρόγραμμα ξεκίνησε το θεάρεστο έργο του: Να στέλνει χιλιάδες αιτήσεις (requests) στον server. Καθώς το πρόγραμμα έτρεχε, δοκιμάσαμε να μπούμε στο site με τον firefox. Τα απτελέσματα φαίνονται στην παρακάτω εικόνα:

Εικόνα 4: Ο server (εδώ για την ακρίβεια ο server της SQL)... "γονάτησε".

Ο server δεν μπόρεσε να εξυπηρετήσει όλες τις... αιτήσεις και μας "έκοψε". Η αντίδραση είναι αρκετά κλασική σε τέτοιου είδους επίθέσεις. Το πρόγραμμα μας όμως μετά από λίγη ώρα τελείωσε δίνοντας μας σημαντικές πληροφορίες:

Εικόνα 5: Μετά το τέλος του dOs έχουμε και... στατιστικά στοιχεία!

Εντάξει μέχρι εδώ! Όλα καλά! Τώρα το site (αφού το πρόγραμμα μας τελείωσε) λογικά θα πρέπει να μας επιτρέπει την πρόσβαση, έτσι δεν είναι; Αμ δε! Λογαριάσαμε χωρίς των ξενοδόχο. Η εταιρία που έχει το site αποφάσισε να μας κόψει (όχι μόνο σε εμάς αλλά σε όλους) την πρόσβαση στο site αυτό, όπως δείχνει και η παρακάτω εικόνα.

Εικόνα 6: Στατιστικά στοιχεία του site έχουμε... το ίδιο το site δεν το έχουμε!

Η ιδιοκτήτρια εταιρία διαπιστώνοντας επίθεση dOs έκανε redirection το site στη σελίδα που βλέπετε στην εικόνα 6 και κλείδωσε τα accounts των διαχειριστών καθως και κάθε πρόσβαση σε αυτό (όπως ftp κλπ)!

Από εδώ και πέρα ξεκινάει ένας κύκλος διαπραγματεύσεων (με mails κλπ) για να πειστεί η εταιρία hosting οτι το attach ήτανε για λόγους test.
Για λόγους πληροφόρησης σας δείχνουμε την πρώτη απάντηση της εταιρίας όταν ζητήσαμε να επαναφέρουν το site:

You are on a shared server and you are effecting other customers on the server.

We will not unsuspended you.
Thank You,
Gxxxxxxxx Wxxxxxxxx

http://www.webhostingpad.com/

Ticket Details
===================
Ticket ID: Nxxxxxxxxxxx
Department: Manager
Priority: High
Status: Closed

Απ' ότι φαίνεται από το ύφος της επιστολής, η εταιρία δεν συμμετείχε στον ενθουσιασμό μας για την επιτυχία της δοκιμής. Φυσικά το δίκιο είναι με το μέρος τους μιας και η δοκιμή μας επειρέασε (απ ότι αναφέρουν) όλο τον server ο οποίος περιλαμβάνει πολλά άλλα sites εκτός από το s3cure.gr.
Για να μην λέμε πολλά, μετά από κάποιες διαπραγματεύσεις και αφού τους αναφέραμε τους αγαθούς σκοπούς μας, το site άνοιξε και επανήλθε κανονικά...

Επίθεση... αυτοκτονίας από linux ubuntu

Ήρθε η ώρα να φτιάξουμε το δικό μας πρόγραμμα επίθεσης dOs και να το δοκιμάσουμε στον... εαυτό μας, δηλαδή στον apache server που έχουμε στον linuxaki μας (εικόνα 7).
Ως συνήθως θα χρησιμοποιήσομε την αγαπημένη μας γλώσσα... την perl! Πριν φτάσουμε όμως στα ενδότερα του κώδικα θα σας πούμε σε γενικές γραμμές την "μεθοδολογία" που θα ακολουθήσουμε.
Απαιτείται να έχετε εγκατεστημένη την Perl και τον Apache server καθώς και κάποιες μικρές βασικές γνώσεις για αυτά τα δύο.

Εικόνα 7: Ο apache web server εγατεστημένος στο "linuxaki" μας :-)

Θα φτιάξουμε ένα πρόγραμμα το οποίο θα δημιουργεί πολλές συνδέσεις με τον server και θα τις κρατάει ανοιχτές για τόσο χρονικό διάστημα, όσο του πούμε εμείς. Θα τρέχει (από που αλλού;) από την γραμμή εντολών και θα δέχεται τέσσερις παραμαμέτρους:
1η παράμετρος: Η Διεύθυνση (URL) του server θύματος.
2η παράμετρος: Η Πόρτα που θα "χτυπήσει" το πρόγραμμα.
3η παράμετρος: Ο αριθμός των δευτερολέπτων που το πρόγραμμα θα "περιμένει" με τις συνδέσεις ανοιχτές.
4η παράμετρος: Το πλήθος των συνδέσεων που θα πραγματοποιηθούν στον server.

Το πρόγραμμα περιέχει τα κατάλληλα σχόλια ώστε να μην χρειάζετε πολύ ανάλυση των ενεργειών που υλοποιεί:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 

#!/usr/bin/perl
#
# ΑΡΧΙΚΗ ΙΔΕΑ ΑΠΟ Vade79[v9@nonexistant].
# ΤΡΟΠΟΠΟΙΗΣΗ ΚΑΙ ΑΛΛΑΓΗ ΤΟΥ ΚΩΔΙΚΑ ΣΕ ΜΙΑ ΑΠΛΟΥΣΤΕΡΗ ΜΟΡΦΗ
# Thiseas 2008.
#
use Socket; # ΒΑΣΙΚΗ ΒΙΒΛΙΟΘΗΚΗ ΕΠΙΚΟΙΝΩΝΙΑΣ.
# ΕΙΣΑΓΩΓΗ ΠΑΡΑΜΕΤΡΩΝ. ΑΝ ΔΕΝ ΕΧΟΥΝ ΔΩΘΕΙ ΠΑΡΑΜΕΤΡΟΙ ΒΑΛΕ DEFAULT ΤΙΜΕΣ.
$Server   = $ARGV[0]; if (!$Server){$Server='127.0.0.1';}
$Port   = $ARGV[1]; if (!$Port){$Port=80;} 
$Anamoni  = $ARGV[2]; if (!$Anamoni){$Anamoni=1;}
$Pli8osSyndesewn = $ARGV[3]; if (!$Pli8osSyndesewn){$Pli8osSyndesewn=1;}

# ΕΜΦΑΝΙΣΗ ΤΟΥ ΤΙΤΛΟΥ ΚΑΙ ΤΩΝ ΕΠΙΛΟΓΩΝ ΤΟΥ ΠΡΟΓΡΑΜΜΑΤΟΣ.
print " - dOs Attach by Flooding - \n";
print "Syndeseis    : $Pli8osSyndesewn. \n";
print "Anamoni      : $Anamoni. \n";

# ΔΗΛΩΣΕΙΣ ΜΕΤΑΒΛΗΤΩΝ ΚΑΙ ΠΡΩΤΟΚΟΛΟΥ ΕΠΙΚΟΙΝΩΝΙΑΣ
my ($Pli8os_Syndesewn_Ari8mos,$pa,$protocol_info,$EpityxeisSyndeseis,$counter,$H_Syndesi);
$Pli8os_Syndesewn_Ari8mos=inet_aton($Server);
$pa=sockaddr_in($Port,$Pli8os_Syndesewn_Ari8mos);
$protocol_info=getprotobyname('tcp');
$EpityxeisSyndeseis=0;
print "$Server:$Port, Ginetai prospa8eia gia $Pli8osSyndesewn syndeseis.\n";


# ΕΔΩ  ΠΡΑΓΜΑΤΟΠΟΙΟΥΝΤΑΙ ΟΛΕΣ ΟΙ ΣΥΝΔΕΣΕΙΣ ΠΟΥ ΖΗΤΗΘΗΚΑΝ.
$counter=0;
while ($counter < $Pli8osSyndesewn){
 $H_Syndesi = "SOCK$counter";
 socket($H_Syndesi,PF_INET,SOCK_STREAM,$protocol_info);
 if (connect($H_Syndesi,$pa)) { $EpityxeisSyndeseis++; } # ΕΠΙΤΥΧΗΣ ΣΥΝΔΕΣΗ.
 $counter++;
}
# ΜΠΟΡΕΙ ΝΑ ΖΗΤΗΘΟΥΝ ΠΟΛΥ ΠΕΡΙΣΣΟΤΕΡΕΣ ΣΥΝΔΕΣΕΙΣ ΑΠΟ ΑΥΤΕΣ ΠΟΥ ΟΡΙΖΟΝΤΑΙ 
# ΣΤΟ /etc/apache2/apache2.conf 'Η ΑΠΟ ΑΥΤΕΣ ΠΟΥ ΕΙΝΑΙ ΗΔΗ ΕΛΕΥΘΕΡΕΣ, ΟΠΟΤΕ 
# ΕΔΩ ΑΝΑΦΕΡΟΥΜΕ ΠΟΣΕΣ ΕΠΙΤΥΧΕΙΣ ΣΥΝΔΕΣΕΙΣ ΠΡΑΓΜΑΤΟΠΟΙΗΘΗΚΑΝ.
print "$Server:$Port, Pragmatopoih8hkan $EpityxeisSyndeseis epityxeis syndeseis apo $counter, Anamoni $Anamoni. \n";
print "$Server:$Port, dOs se ekseliksi...\n";
sleep($Anamoni); # ΠΕΡΙΜΕΝΕΕΕΕΕΕΕΕ......!
print "$Server:$Port, Telos diadikasias.\n";

# ΤΩΡΑ ΚΛΕΙΣΕ ΟΛΕΣ ΤΙΣ ΣΥΝΔΕΣΕΙΣ (ΑΝΕΞΑΡΤΗΤΑ ΑΝ ΗΤΑΝ ΕΠΙΤΥΧΕΙΣ 'Η ΟΧΙ).
$counter = 0;
while ($counter < $Pli8osSyndesewn){
 $H_Syndesi="SOCK$counter";
 shutdown($H_Syndesi,2);
 $counter++;
}

Ο σκοπός όμως είναι να δούμε και στη πράξη πως ακριβώς συμπεριφέρεται το πρόγραμμα... Για να δούμε:

Κίνησις 1η: Στην αρχή είμαστε επιφυλακτικοί και τρέχουμε το πρόγραμμα με πολύ μικρές τιμές. Αυτό βοηθάει να κατανοήσουμε καλύτερα την λειτουργία του μιας και τις μικρές τιμές μπορούμε να τις χειριστούμε ευκολότερα, οπότε τρέχουμε το εξής:

Δηλαδή "χτυπάμε" το linuxaki στην πόρτα 80 με αναμονή 1 δευτερόλεπτο και 5 συνδέσεις.
Αμέσως μετά και σε ένα άλλο παράθυρο command  τρέχουμε "sudo netstat -tapn". Με αυτόν τον τρόπο θα δούμε τις όλες τις ανοιχτές συνδέσεις που έχουμε (μαζί με τις 5 που μόλις ανοίξαμε). Χε χε... αν δεν τα καταφέρετε να το τρέξετε σε λιγότερο από ένα δευτερόλεπτο (για να δείτε τις συνδέσεις ανοιχτές - established) απλά αυξήστε τον χρόνο αναμονής ;-). Αν μετά από το τέλος του προγράμματος ξανατρέξουμε "sudo netstat -tapn" πάλι θα δούμε τις 5 συνδέσεις μας αυτή τη φορά όμως σε άλλο... status:

Είναι ενδιαφέρον να πειραματιστείτε λίγο με το παραπάνω για να καταλάβετε πως λειτουργεί ο apache και πως συμπεριφέρονται οι διαδικασίες monitoring (όπως η netstat) του λειτoυργικού σας.  Για τους πιό ανήσυχους θα προτείναμε να πειραματιστούν και με το configuration του apache server (όπως π.χ. στο μέγιστο αριθμό επιτρεπόμενων ανοιχτών συνδέσεων κλπ, όπως Timeout, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout) τρέχοντας το πρόγραμμα με διαφορετικές παραμέτρους συνδέσεων και καθυστέρησης. Απλά μην ξεχνάτε οτι με κάθε αλλαγή στο /etc/apache2/apache2.conf πρέπει να εκκίνησετε ξανά τον apache  με "sudo /etc/init.d/apache2 restart".

Κίνησις 2η: Τώρα που ξεψαρώσαμε λίγο μπορούμε να αρχίσουμε τις... "χυδαιότητες" και να απαιτήσουμε οχι 5 αλλά 1000 συνδέσεις και όχι 1 αλλά 180 δευτερόλεπτα καθυστέρηση:

Μόλις ξεκινήσει το πρόγραμμα να τρέχει θα πρέπει να κάνουμε, στον internet browser, refresh την σελίδα του appache. Ανάλογα τις ρυθμίσεις που έχουμε στο /etc/apache2/apache2.conf κάποια στιγμή θα δούμε το περίφημο  "Network Timeout" (εικόνα 11)

Εικόνα 11: Network Time out... εν δράση!

Τρόποι προστασίας

Οι τρόποι προστασίας μπορούνε να διαχωριστούν σε 2 βασικούς άξονες:
Ο ένας αφορά στην προστασία από το φαινόμενο slashdot. Δηλαδή από την απότομη αύξηση της επισκεψιμότητας στον server μας η οποία δεν οφείλετε σε επίθεση. Τέτοιες καταστάσεις μπορούμε να τις αντιμετωπίσουμε με την αλλαγή κάποιων τιμών του apache configuration file (/etc/apache2/apache2.conf), όπως η αλλαγή των τιμών:
KeepAlive σε συνδιασμό με τις MaxKeepAliveRequests και KeepAliveTimeout (http://tinyurl.com/5detgy).
Η KeepAlive καθορίζει αν μια σύνδεση με τον server μας θα μένει ανοιχτή ή όχι. Για να καταλάβουμε τι σημαίνει αυτό θα δώσουμε το εξής παράδειγμα: Σκεφτείτε οτι το site μας περιέχει ένα μέρος με κείμενο και ένα μέρος με τρείς εικόνες, δηλαδή 4 διαφορετικά "κομμάτια". Χοντρικά, εάν έχουμε θέσει το KeepAlive=off τότε θα πραγματοποιηθούν 4 διαφορετικές συνδέσεις από τoν firefox (ας πούμε) για να μας δείξει το site, μια για να φορτωθεί το κάθε "κομμάτι".
Ας πούμε τώρα οτι χρειάζονται 4 δευτερόλεπτα για να διαβαστούν τα παραπάνω. Αν θέσουμε 
KeepAlive=on
KeepAliveTimeout=6
Τότε με μία σύνδεση (που θα διαρκεί 6 δευτερόλεπτα) θα μπορέσει ο browser μας να φέρει το site μας (με μία! - και τα 4 κομμάτια). Ο χρόνος φυσικά θα είναι πολύ καλύτερος από τον προηγούμενο. Φυσικά,... ο τρόπος αυτός έχει ένα μειονέκτημα: Ο μέγιστος αριθμός των συνδέσεων στον server μας ορίζετε από την  MaxKeepAliveRequests. Δηλαδή με ένα "MaxKeepAliveRequests=1000" τότε οι πρώτοι 1000 χρήστες θα συνδεθούν για 6 δευτερόλεπτα. Έτσι εάν τον server μας τον επισκεφτούν ταυτόχρονα 10000 χρήστες!!! (λέμε τώρα), τότε μόνο 1000 κάθε φορά θα μπορούν να έχουν πρόσβαση στα δεδομένα και οι υπόλοιποι 9000 θα περιμένουν από 6 δευτερόλεπτα (τουλάχιστον). Αυτό θα έχει σαν αποτέλεσμα πολύ από αυτούς να δούνε στους browsers τους το περίφημο time out και θα τους ζητηθεί να πατήσουν το refresh για ακόμα μια πρσοπάθεια.
Μιά καλή λύση σε πολυσύχναστα sites θα ήταν να θέσουμε το "KeepAlive=off". Αυτό θα είχε σαν αποτέλεσμα ο κάθε χρήστης (ατομικά) να έχει μια μικρή καθυστέρηση (σε σχεση με το αν είχαμε συνεχή σύνδεση). Η καθυστέρηση αυτή (στατιστικά) κυμαίνεται γύρω στο 15-20%, δηλαδή όχι και τόσο σοβαρή. Το καλό όμως θα είναι οτι θα μπορούμε να "εξυπηρετήσουμε" ένα πάρα πολύ μεγάλο αριθμό χρηστών χωρίς ιδαίτερα προβλήματα.
Ένας άλλος σημαντικός παράγοντας για καλύτερη απόκριση είναι τα settings της βάσης δεδομένων. Αν έχουμε π.χ. MySQL και το site μας κάνει χρήση πολλών εντολών που φέρνουν ή ενημερώνουν την Βάση μας, τότε αξίζουν προσοχής όλες οι πατράμετροι που ορίζουν το cache και τα buffers της μνήμης που χρησιμοποιήται (π.χ. query_cash_size). Μια λεπτομερής ανάλυση αυτών των παραμέτρων θα ξέφευγε εντελώς από τον σκοπό του άρθρου. Αξίζει όμως να αναφέρουμε οτι υπάρχουν αρκετές και λεπτομερείς αναφορές στο net (http://tinyurl.com/eoxha).
Φυσικά δεν λείπουνε και τα έτοιμα προγράμματα που μετρούν (και κάποια διορθώνουν) προβλήματα ταχύητητας και υψηλού φόρτου σε έναν server όπως τα:
> JMeter (http://tinyurl.com/56rfyo): πρόγραμμα από το γνωστό Jakarta Project σε java που μπορεί να μετρήσει μετρήσει την αποδοτικότητα του server.
> Web Developer Server Suite (http://tinyurl.com/5p35hn): Εμπορικό πρόγραμμα σε windows για μέτρηση και έλεγχο.
> Zend platform: μια γνωστή επμορική εφαρμογή με ομολογουμένος πολλές δυνατότητες και αξιοσημείωτα χαρακτηρηστικά βελτιστοποίησης (http://www.zend.com/).

Όπως είπαμε όμως, είπαμε και πριν, υπάρχει και ο άλλος άξονας. Οι... επιθέσεις. Μια σύντομη αλλά περιεκτική λίστα τρόπων προστασίας από επιθέσεις DOS είναι η παρακάτω:
> Ένα καλό firewall (στην ιδανική περίπτωση hardware) με σύστημα intrution detection (π.χ http://tinyurl.com/6z6tup ή http://tinyurl.com/evn6v). Εδώ μπορείτε να "μπλοκάρετε" συγκεκριμένες πόρτες, Ips, ακόμα και συγκεκριμένα πρωτόκολα επικοινωνίας με τον server σας. 
> Να έχετε πάντα ενημερωμένο software (λειτουργικό, web servers, firewalls, antiviruses κλπ) με τις τελευταίες ενημερώσεις του κατασκευαστή.
> Ειδικό Software, Routers και hardawre συστήματα για πρόληψη επιθέσεων DOS (http://tinyurl.com/6emync).

Γενικά, οποτεδήποτε παρατηρήσετε ασυνήθιστη πτώση της ταχύτητας του δικύου σας να ελέγχετε και να μελετάτε πάντα τα logs του server σας. Για παράδειγμα, σε περίπτωση που παρατηρήσετε πάρα πολλές συνδέσεις από μια συγκεκριμένη IP σε πολύ μικρό χρονικό διάστημα (π.χ. μέσα σε 10") είναι κατά πάσα πιθανότητα επίθεση DOS. Το πρώτο που θα πρέπει να κάνετε τότε είναι να "κόψετε" την IP να έχει πρόσβαση στον server σας, π.χ. μέσω του firewall.

Αντί... επιλόγου ;-)

Να ξεκαθαρίσουμε οτι η διαδικασία του να καλείς ένα έτοιμο πρόγραμμα για να κάνεις απλά κακό σε κάποιον server (που δεν σου φταίει σε τίποτα) είναι ο ορισμός του lamer και του script kiddie και καταδικάζεται μετά "βδελυγμίας" από όλους τους απανταχού normal ανθρώπους (πόσο μάλλον και από τους hackers – που δεν είναι και... normal!!)
Από την άλλη μεριά, η διαδικασία επίθεσης που περιγράφτηκε στο linux, προσφέρεται για πειραματισμούς με τον apache μας μιας και στo δικό μας περιβάλον δεν πρόκειται να μας κατηγορήσει κανείς ;-). Με τον ίδιο ακριβώς τρόπο (και προτείνετε από τον γράφοντα) μπορούμε να δοκιμάσουμε τις "αντοχές" ενός τοπικού IIS 7, προς γνώση και συμόρφωση (μας)!
Επίσης, αλλάχτε και το προγραμματάκι μας, προσαρμόστε το, ενισχύστε το... αλλάξτε του τα φώτα guys!! "Κρεμάστε" το σύστημα σας και ξαναεγκαταστήστε το!! Άλλωστε, ο τρόπος αυτός του πειραματισμού είναι ο καλύτερος για να μάθει κάποιος αυτά που κανένα βιβλίο και καμιά αίθουσα διαδασκαλίας δεν μπορεί να του προσφέρει.
Είναι ο τρόπος που μάθανε όλοι οι hackers: "The hard way" ή για τους λάτρεις του Matrix: "The Blue Pile" (http://tinyurl.com/68k2z)

Happy Testing!

DoS Attacks  [ Πρώτη Δημοσίευση: Περιοδικό TotalXakeR #17 ]