Πρώτο commit
Αυτό το commit περιλαμβάνεται σε:
infl00p
commit
8ec8e9bee2
451 αρχεία άλλαξαν με 46736 προσθήκες και 0 διαγραφές
32
content/articles/34/01_editorial.md
Κανονικό αρχείο
32
content/articles/34/01_editorial.md
Κανονικό αρχείο
|
|
@ -0,0 +1,32 @@
|
|||
+++
|
||||
title = 'Editorial'
|
||||
date = '2003-10-01T00:00:00Z'
|
||||
description = ''
|
||||
author = 'Ιατρού Μιχάλης iatrou ατ hellug ντοτ gr(mailto:iatrouNO@SPAMhellug.gr)'
|
||||
issue = ['Magaz 34']
|
||||
issue_weight = 1
|
||||
+++
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Magaz\... still unpatented.*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αναμφισβήτητα το πιο σημαντικό γεγονός του Σεπτεμβρίου ήταν η ψηφοφορία σχετικά με τα software patents στο Ευρωπαϊκό Κοινοβούλιο. Η ψηφοφορία πραγματοποιήθηκε
|
||||
στις 24 Σεπτεμβρίου, ενώ είχε ήδη αναβληθεί δύο φορές, εκ των οποίων η τελευταία ήταν στις αρχές Σεπτεμβρίου. Τα αποτελέσματα της ψηφοφορίας δικαίωσαν τις
|
||||
προσπάθειες όλων όσων αντιτάχθηκαν στα software patents: οι περισσότερες τροποποιήσεις που ψηφίστηκαν στηρίζουν την ιδέα ότι το software δεν μπορεί να
|
||||
πατενταριστεί. Αν κρίνουμε δε από διάφορες [αντιδράσεις](http://news.zdnet.co.uk/business/legal/0,39020651,39116709,00.htm) μάλλον \"κάποιοι\" ενοχλήθηκαν πολύ
|
||||
από αυτή την εξέλιξη\...
|
||||
|
||||
Όπως όμως ήταν αναμενόμενο, σε μία ψηφοφορία που διήρκεσε μόλις 40 λεπτά και ψηφίστηκαν συνολικά 78 τροποποιήσεις, δεν ήταν εφικτό να γίνουν όλα **ακριβώς**
|
||||
όπως θα τα θέλαμε: μπορεί οι βάσεις να έχουν μπει, αλλά περίπου το 20% των τροποποιήσεων πρέπει να επανεξεταστεί και να καταστεί απόλυτα σαφές ότι software και
|
||||
πατέντες δεν συμβαδίζουν.
|
||||
|
||||
Το σίγουρο είναι ότι αν και κερδίσαμε αυτή τη μάχη, δεν έχουμε κερδίσει τον πόλεμο. Είναι βέβαιο πως στο εγγύς μέλλον θα υπάρξουν πολλές προσπάθειες να πληγεί η
|
||||
ελευθερία του λογισμικού και πρέπει όλοι να είμαστε σε εγρήγορση
|
||||
|
||||
**Επί του πιεστηρίου\...**\
|
||||
9 με 12 Οκτωβρίου πραγματοποιήθηκε στον εκθεσιακό χώρο της HELEXPO στη Θεσσαλονίκη η δεύτερη μεγαλύτερη έκθεση πληροφορικής στην Ελλάδα, η Infosystem. Ο
|
||||
HEL.L.U.G. μετά από δύο χρόνια απουσίας έδωσε και πάλι το παρόν. Η παρουσία του μπορεί να χαρακτηριστεί απόλυτα επιτυχής: μοιράστηκαν μερικές χιλιάδες CD, ο
|
||||
κόσμος ενημερώθηκε για το Linux, τον σύλλογο, το ελεύθερο λογισμικό αλλά και για σημαντικά προβλήματα όπως τα software patents. Φωτογραφίες τόσο από την έκθεση
|
||||
όσο και από τις λοιπές δραστηριότητες του τετραήμερου μπορείτε να βρείτε [εδώ](http://www.hellug.gr/infosystem2003/index.html).
|
||||
326
content/articles/34/02_texinfo.md
Κανονικό αρχείο
326
content/articles/34/02_texinfo.md
Κανονικό αρχείο
|
|
@ -0,0 +1,326 @@
|
|||
+++
|
||||
title = 'Documentation ala GNU'
|
||||
date = '2002-07-01T00:00:00Z'
|
||||
description = ''
|
||||
author = 'Καπελώνης Κωστής kkapelon _AT_ freemail.gr(mailto:kkapelonSPAM@SUXfreemail.gr)'
|
||||
issue = ['Magaz 34']
|
||||
issue_weight = 2
|
||||
+++
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Σε αυτό το άρθρο γίνεται μία εισαγωγή στο επίσημο εργαλείο για documentation της GNU, το σύστημα Texinfo. Απευθύνεται σε προγραμματιστές που έχουν τελειώσει
|
||||
την κατασκευή μιας εφαρμογής κονσόλας και επιθυμούν να ενσωματώσουν βοήθεια σε αυτή.*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
**1. Εισαγωγή**
|
||||
-----------------------------------------
|
||||
|
||||
**2. Οι επιλογές σας**
|
||||
------------------------------------------------
|
||||
|
||||
**3. Το texinfo από την μεριά του χρήστη.**
|
||||
---------------------------------------------------------------------
|
||||
|
||||
**4. texinfo vs manpages**
|
||||
----------------------------------------------------
|
||||
|
||||
**5. Η φιλοσοφία του texinfo**
|
||||
--------------------------------------------------------
|
||||
|
||||
**6. To πιο απλό Texinfo αρχείο**
|
||||
-----------------------------------------------------------
|
||||
|
||||
**7. Ένα μεγαλύτερο έγγραφο**
|
||||
-------------------------------------------------------
|
||||
|
||||
**8. Συγγραφή του κυρίως κειμένου.**
|
||||
--------------------------------------------------------------
|
||||
|
||||
**9. Emacs shortcuts**
|
||||
------------------------------------------------
|
||||
|
||||
**10. Επίλογος**
|
||||
--------------------------------------------
|
||||
|
||||
|
||||
### [1. Εισαγωγή]{#s1}
|
||||
|
||||
Δεν νομίζω ότι χρειάζεται να επαναλάβω ρήσεις για το Documentation και το sex. Μεγάλα παιδιά είστε, οπότε ξέρετε ότι μεγάλο βάρος στην ποιότητα και την
|
||||
ευχρηστία μιας εφαρμογής, έχει ΚΑΙ η βοήθεια/τεκμηρίωση που την συνοδεύει.
|
||||
|
||||
Δυστυχώς αρκετές φορές η βοήθεια ενός προγράμματος παραμελείται από τους προγραμματιστές της. Όλοι μας έχουμε συναντήσει προγράμματα που ενώ ήταν λειτουργικά
|
||||
και μπορούσαν να εκπληρώσουν το σκοπό τους, είχαν ελλιπές ή ακόμα και μηδαμινό documentation.
|
||||
|
||||
Ειδικά στον χώρο του ανοιχτού λογισμικού (open source) τα πράγματα δεν είναι πολύ καλά. Άπειρες επιλογές με περίεργα ονόματα σε γραφικά προγράμματα, ή
|
||||
undocumented παράμετροι σε προγράμματα κονσόλας (command line arguments) είναι καθημερινό φαινόμενο. Δεν μου αρέσει να ενεργοποιώ επιλογές που απλά είδα στο
|
||||
δίκτυο ή άκουσα από φίλους ότι \"έτσι λειτουργεί\". Οι μέρες του voodoo πρέπει να μείνουν επιτέλους στην ιστορία.
|
||||
|
||||
Τώρα θα πούνε μερικοί, \"σιγά ρε φίλε! Use the source, Luke!\". Μα καλά είμαστε σοβαροί; Είμαστε στο 2000+ και θα πρέπει να ανοίξω τον πηγαίο κώδικα του
|
||||
προγράμματος για να δω τι κάνει;Δεν το δέχομαι αυτό. Καλή εφαρμογή = καλός κώδικας + καλή τεκμηρίωση.
|
||||
|
||||
Γράφω λοιπόν αυτό το άρθρο έτσι ώστε όταν τελειώσετε το προγραμματιστικό σας αριστούργημα, με την τέλεια δομημένη εσωτερική αρχιτεκτονική, την ταχύτατη μεταφορά
|
||||
πληροφορίας ανάμεσα στα διάφορα μέρη του, τις βελτιστοποιημένες στο έπακρο εσωτερικές ρουτίνες και τις πολύπλοκες δομές δεδομένων,όταν πιστέψετε ότι έχετε βάλει
|
||||
τάξη στο χάος ;-), όταν νιώσετε ένας μικρός θεός και βιώσετε το θαύμα της δημιουργίας, να μην ξεχάσετε και τον παράγοντα τεκμηρίωση.
|
||||
|
||||
### [2. Οι επιλογές σας]{#s2}
|
||||
|
||||
Αν η εφαρμογή που γράφετε έχει γραφικό μέρος και ανήκει σε κάποιο από τα δύο γνωστά περιβάλλοντα εφαρμογών (desktop environments), δεν χρειάζεται να συνεχίσετε
|
||||
την ανάγνωση. Απλά δείτε τις αντίστοιχες σελίδες που εξηγούν πως πρέπει να είναι το documentation της εφαρμογής σας. Λογικά θα πρέπει να γράψετε ένα αρχείο SGML
|
||||
Docbook το οποίο θα πρέπει να έχει μια συγκεκριμένη μορφή.
|
||||
|
||||
Αν η εφαρμογή σας είναι απλά γραφική και δεν υπάρχει \"σωστός\" τρόπος για την εισαγωγή βοήθειας, προτιμήστε το δοκιμασμένο Latex. Βάζετε το output σε html στο
|
||||
site του προγράμματος για online αναζήτηση, ενώ μαζί με το ίδιο το πρόγραμμα ενσωματώνετε τα ps και pdf αρχεία. Αυτό είναι απλά μία πρόταση. Είναι στην κρίση
|
||||
σας να επιλέξετε.
|
||||
|
||||
Εδώ θα μιλήσουμε για την περίπτωση όπου το πρόγραμμα σας δεν έχει γραφικό περιβάλλον, αλλά εκτελείται σε περιβάλλον γραμμής εντολών. Αν είναι πολύ απλό στην
|
||||
χρήση, και με λίγες παραμέτρους τα πράγματα είναι εύκολα. Απλά βάλτε στο -h/\--help του να εμφανίζεται κάθε δυνατή παράμετρος με μία μικρή εξήγηση. Σε αυτήν την
|
||||
περίπτωση μπορείτε να ακολουθήσετε και το GNU style για τις παραμέτρους όπου κάθε μία έχει ένα σύντομο όνομα για τους έμπειρους χρήστες (πχ -b) και ένα πιο
|
||||
μεγάλο για τους αρχάριους (πχ \--buffer-size).
|
||||
|
||||
Αν όμως δεν ισχύει κάτι τέτοιο οφείλετε να δώσετε ξεχωριστό documentation. Αυτό θα βοηθήσει τόσο τους έμπειρους χρήστες όταν θα θελήσουν να \"ξεζουμίσουν\" το
|
||||
πρόγραμμα σας, αλλά και τους αρχάριους που αρέσκονται στο να βρίσκουν κάπου \"μαζεμένη\" την βοήθεια ενός προγράμματος.
|
||||
|
||||
|
||||
### [3. Το texinfo από την μεριά του χρήστη.]{#s3}
|
||||
|
||||
Ας δούμε ένα παράδειγμα. Έστω ότι θέλετε να μάθετε τα πάντα για το GNU flex.
|
||||
|
||||
Αρχικά μπορείτε να ανοίξετε ένα τερματικό στο pc σας και να δώσετε \"info flex\" [\[εικόνα\]](/34/img/flexINFO.png). Πατώντας το πλήκτρο space μπορείτε να διαβάσετε
|
||||
όλο το manual από την αρχή μέχρι το τέλος. Με τα πλήκτρα (p)revious, (n)ext kai (u)p μπορείτε να περιπλανηθείτε στους κόμβους του. Μπορείτε επίσης να φορτώσετε
|
||||
τον Emacs 21+ και με Ctrl-h i ή από το μενού \"Help-\>manuals-\>Browse manuals with info\" να δείτε όλα τα manuals που έχετε στο σύστημα σας σε texinfo format
|
||||
(το ίδιο γίνεται και αν γράψετε σκέτο \"info\" στην γραμμή εντολών). Μόλις πάτε στο manual του flex ισχύουν τα ίδια keyboard shortcuts. Επίσης έχετε όμορφα
|
||||
κουμπιά στην toolbar, ενώ μπορείτε να κάνετε και μεσαίο κλικ στα links που βλέπετε [\[εικόνα\]](/34/img/flexEMACS.png).
|
||||
|
||||
Αν επιθυμείτε κάτι πιο συμβατικό μπείτε στο [gnu.org (manuals section)](http://www.gnu.org/manual/manual.html) όπου μπορείτε είτε να κατεβάσετε ολόκληρο το
|
||||
manual σε Postscript μορφή [σε Postscript μορφή](http://www.gnu.org/manual/flex-2.5.4/ps/flex.ps.gz) για να το τυπώσετε ή μπορείτε να το διαβάσετε Online σε
|
||||
απλή και γρήγορη [HTML μορφή](http://www.gnu.org/manual/flex-2.5.4/html_node/flex_toc.html)
|
||||
|
||||
Τέλος ακόμα και αν έχετε GNOME η KDE βάζοντας info://foo στην γραμμή διεύθυνσης, μπορείτε να δείτε τα infopages της εφαρμογής foo. (Αν και νομίζω ότι στις
|
||||
τελευταίες εκδόσεις KDE και GNOME υπάρχει στο help ξεχωριστή επιλογή \"browse info pages\" όπου βρίσκονται όλα τα manuals του συστήματος.)
|
||||
|
||||
Τώρα πια θα πρέπει να έχετε αναγνωρίσει την άνεση που προσφέρει το texinfo. Browsing σε κονσόλα χρήσιμο για τους servers σας, ενσωμάτωση με τον emacs, γνώριμη
|
||||
html μορφή και υψηλής ποιότητας manual έτοιμο για εκτύπωση. Ταχύτητα, ευχρηστία και συμβατότητα. Και όπως προφανώς καταλάβατε τα πάντα βγαίνουν από ένα αρχείο
|
||||
που γράφετε μία φορά και μετά με τα διάφορα εργαλεία το μετατρέπετε σε ότι μορφή θέλετε.
|
||||
|
||||
|
||||
### [4. texinfo vs manpages]{#s4}
|
||||
|
||||
Λυπάμαι που θα απογοητεύσω όλους τους hard-core unixάδες, αλλά το επίσημο documentation format σύμφωνα με την GNU είναι το texinfo και όχι οι manpages. Μία
|
||||
manpage είναι αρκετή για μικρά προγράμματα, από κάποιο σημείο και μετά όμως τα πράγματα δυσκολεύουν.
|
||||
|
||||
Το γεγονός ότι μία manpage στερείται δομής, την κάνει δύσχρηστη. Πόσες φορές δεν έχετε εκνευρισθεί όταν ψάχνετε μία παράμετρο σε μία manpage και έχετε βρει όλες
|
||||
τις άλλες εκτός από αυτήν που χρειάζεστε;Κατά την γνώμη μου μία manpage πρέπει να έχει απλά μια μικρή περιγραφή του προγράμματος.
|
||||
|
||||
Έτσι σήμερα είναι δυνατόν να βρείτε προγράμματα που διαθέτουν infopages αλλά όχι manpages. Άλλες φορές μάλιστα υπάρχει manpage η οποία όμως απλά αναφέρει \"see
|
||||
the info pages for the full documentation\" η κάτι παρόμοιο.
|
||||
|
||||
Μπορεί λοιπόν οι manpages να ήταν αρκετές το 1980, σήμερα όμως έχετε την δυνατότητα να έχετε και δομημένο και εύκολα αναγνώσιμο documentation,οπότε γιατί να μην
|
||||
το χρησιμοποιήσετε;
|
||||
|
||||
|
||||
### [5. Η φιλοσοφία του texinfo]{#s5}
|
||||
|
||||
Το texinfo ως σύστημα βασίζεται πάνω στο Tex/Latex. Γράφετε ένα απλό αρχείο κειμένου lala.texi με ειδική σύνταξη (τα @-commands) και μετά με την εντολή texi2foo
|
||||
παίρνετε το lala.foo όπου foo μέχρι τώρα μπορεί να είναι html/dvi/pdf. Υπάρχει και εντολή makeinfo με διάφορες παραμέτρους για την παραγωγή των info αρχείων.
|
||||
|
||||
Αυτό όμως δεν πρέπει να σας φοβίζει αν δεν γνωρίζετε το Latex. (Αν και κάποια στιγμή πρέπει να μάθετε και Latex :-). Το Texinfo είναι ένα επίπεδο πιο πάνω από
|
||||
το Latex. Αυτό σημαίνει ότι αποκρύπτει από εσάς τα \\verylongandcomplicatedLatexdirectives και σας επιτρέπει να γράψετε το κείμενο σας με μικρά \@commands
|
||||
δηλαδή εντολές/keywords που απλά ξεκινάνε με το @. Τα \@commands είναι όλα documented στο manual του texinfo το οποίο είναι γραμμένο επίσης σε (μαντέψτε!)
|
||||
texinfo. Έτσι υπάρχει το \@chapter, \@section ,\@code, \@itemize με απλά και κατανοητά ονόματα. Αν μάλιστα χρησιμοποιείτε emacs θα βρείτε ότι η συγγραφή texinfo
|
||||
αρχείων με το αντίστοιχο mode είναι πραγματικά πολύ εύκολη.
|
||||
|
||||
H μαγεία είναι ότι μπορείτε να χρησιμοποιήσετε ακόμα τις εντολές του Latex αν το επιθυμείτε (κυρίως για τα εκτυπώσιμα outputs). Μάλιστα μπορείτε να γράψετε
|
||||
διαφορετικά τμήματα για την περίπτωση που το texinfo αρχείο μετάφράζεται σε tex, html ή info. (Περίπου σαν τα \#ifdef του C-preprocessor).
|
||||
|
||||
Παρόλο που το texinfo διαθέτει την εντολή \@image για την εισαγωγή εικόνων σε ένα έγγραφο, δεν θα πρέπει να την χρησιμοποιήσετε (στην αρχή τουλάχιστον). Και
|
||||
αυτό γιατί η εικόνα δεν θα φαίνεται στο info output του αρχείου σας οπότε \"χάνεται\" η συμβατότητα του texinfo, για την οποία το διαλέξατε. Δηλαδή το texinfo
|
||||
τεχνικά μπορεί να χειριστεί εικόνες (αφού μπορεί το Latex).
|
||||
|
||||
|
||||
### [6. To πιο απλό Texinfo αρχείο]{#s6}
|
||||
|
||||
Ας ξεκινήσουμε με το πιο μικρό texinfo αρχείο(σχεδόν). Στον αγαπημένο σας editor γράψτε τα παρακάτω: (σε emacs και gvim θα έχετε και syntax highlighting)
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
\input texinfo
|
||||
@setfilename example.texi
|
||||
@settitle example
|
||||
@bye
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αφού το αποθηκεύσετε με όνομα sample.texi δοκιμάστε με τις εντολές texi2dvi,texi2html,texi2pdf και makeinfo να το μετατρέψετε στα αντίστοιχα format. (To dvi
|
||||
αρχείο μπορείτε να το δείτε με την εντολή xdvi. Τα dvi αρχεία είναι μια ενδιάμεση μορφή του tex.Μπορείτε να τα κάνετε Postscript με την εντολή dvips). Τo .info
|
||||
αρχείο μπορείτε να το δείτε με την εντολή info ./example.info.
|
||||
|
||||
H πρώτη γραμμή είναι η μοναδική εντολή σε ένα texinfo αρχείο που δεν ξεκινάει με @. Και αυτό γιατί φορτώνει το texinfo.tex το οποίο περιέχει τα defines/macros
|
||||
που ενεργοποιούν τις ίδιες τις @-εντολές. Η επόμενη γραμμή ορίζει το όνομα του αρχείου που γράφετε (το οποίο προφανώς θα πρέπει να είναι ίδιο με του αρχείου που
|
||||
την περιέχει).
|
||||
|
||||
Η \@settitle δίνει έναν γενικό τίτλο στο manual σας, και η τελευταία εντολή δείχνει που σταματάει η επεξεργασία (processing) του κειμένου. Οτιδήποτε μετά το
|
||||
\@bye αγνοείται από το Texinfo.
|
||||
|
||||
Παρατηρείστε αυτό που ανέφερα παραπάνω σχετικά με την απλότητα του Texinfo. Οι @-εντολές έχουν μικρά και κατανοητά ονόματα, κάτι που δεν συμβαίνει με το Latex.
|
||||
|
||||
|
||||
### [7. Ένα μεγαλύτερο έγγραφο]{#s7}
|
||||
|
||||
Ας δούμε ένα μεγαλύτερο παράδειγμα. Σε ένα νέο αρχείο γράψτε τα παρακάτω.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
\input texinfo
|
||||
@setfilename sample.info
|
||||
@settitle A sample manual
|
||||
@setchapternewpage odd
|
||||
@titlepage
|
||||
@title My first Texinfo manual
|
||||
@subtitle Demo for Magaz
|
||||
@author Kapelonis Kostis
|
||||
|
||||
@comment This is a comment
|
||||
@page
|
||||
@vskip 11pt plus 1fill1
|
||||
Copyright @copyright{} 2002
|
||||
@end titlepage
|
||||
@comment name,next,prev,up
|
||||
@node Top,First Chapter,,(dir)
|
||||
@menu
|
||||
* First Chapter:: The first chapter is the only chapter in this sample
|
||||
* Concept Index:: This index has two entries
|
||||
@end menu
|
||||
@node First Chapter,Concept Index,Top,Top
|
||||
@chapter First Chapter
|
||||
@cindex Sample index entry
|
||||
These are the contents of the first chapter
|
||||
Here is a simple line of text.
|
||||
@cindex Another sample index entry
|
||||
Here is a numbered list
|
||||
@enumerate
|
||||
@item
|
||||
This is the first item
|
||||
@item
|
||||
This is the second item
|
||||
@end enumerate
|
||||
|
||||
@iftex
|
||||
This paragraph should
|
||||
appear only in a printed manual.
|
||||
It is enclosed inside iftex keywords.
|
||||
@end iftex
|
||||
|
||||
@ifinfo
|
||||
This paragraph should
|
||||
appear only in the info manual.
|
||||
It is enclosed inside ifinfo keywords.
|
||||
@end ifinfo
|
||||
|
||||
The @command{makeinfo} command will convert this manual
|
||||
into an info file and @TeX{} to a printed file.
|
||||
@node Concept Index ,,First Chapter,Top
|
||||
@unnumbered Concept Index
|
||||
@printindex cp
|
||||
@comment Place here table of contents
|
||||
@contents
|
||||
@bye
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Εδώ βλέπουμε αρκετές \@εντολές. Δεν θα τις αναφέρω όλες, για τις λεπτομέρειες δείτε το manual του texinfo. Οι γνώστες του Latex ήδη θα έχουν δει πως το texinfo
|
||||
\"καλύπτει\" με τις δικές του \@εντολές τις αντίστοιχες του Latex.
|
||||
|
||||
Το παράδειγμα δείχνει τις εντολές για την δημιουργία indexing, την \@menu για την δημιουργία μενού για το browsing μέσα σε Info αρχείου, καθώς και την πολύ
|
||||
σημαντική εντολή \@node. H εντολή \@vskip υπάρχει για να δείξει ότι δεν έχει χαθεί η ευελιξία που διαθέτει το Tex/Latex.
|
||||
|
||||
Ένα node (κόμβος στα ελληνικά) είναι το μικρότερο δομικό στοιχείο ενός info αρχείου. Όταν πατήσατε previous,next και up στο manual του flex, ουσιαστικά
|
||||
μετακινηθήκατε στα αντίστοιχα nodes. Κάθε info αρχείο \"κρέμεται\" από έναν top node που είναι ο αρχικός κόμβος του αντίστοιχου manual. Όλοι οι top nodes από τα
|
||||
manuals που έχετε στο σύστημα σας \"κρέμονται\" από έναν top node(supernode) του συνολικού info tree. Αν γράψετε σκέτο info σε ένα τερματικό (χωρίς όνομα manual
|
||||
δηλαδή) βλέπετε αυτόν τον supernode και άρα έχετε μπροστά σας όλα τα manual που έχετε εγκατεστημένα. To ίδιο συμβαίνει και όταν μπαίνετε στο info mode του
|
||||
Emacs.
|
||||
|
||||
Πρακτικά αυτό σημαίνει ότι τελικά θα πρέπει να χωρίσετε το κείμενο σας σε nodes. Τα \@chapter και \@section δεν είναι αυτά που καθορίζουν την δομή του online
|
||||
manual. Όπως είδατε και στην σελίδα [της GNU για τον flex](http://www.gnu.org/manual/flex-2.5.4/flex.html) ειδικά η html μορφή είναι δυνατόν να κατασκευαστεί με
|
||||
διάφορους τρόπους ανάλογα με τα nodes/chapters. Αυτή είναι και μια μεγάλη διαφορά που ίσως δυσκολέψει όσους \"σκέφτονται\" σε Latex. (Αναφέρομαι πάντα στο .info
|
||||
output που είναι browsable. Για ps/pdf ισχύουν τα γνωστά, δηλαδή το texinfo είναι ένα πιο φιλικό tex. Αν γράψετε ένα manual και ξέρετε από πριν ότι θα το
|
||||
βγάλετε μόνο σε pdf δεν χρειάζεται να δώσετε σημασία σε \@node και \@menu).
|
||||
|
||||
To \@node command συντάσσεται ως εξής:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
@node όνομα,όνομα-επόμενου,όνομα-προηγούμενου,όνομα-πατρικού.
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Μία από τις πρώτες δυσκολίες που θα συναντήσετε κάθε φορά που γράφετε ένα καινούριο node,είναι να συμπληρώσετε τα παραπάνω ονόματα. Αν γράφετε σε Emacs υπάρχει
|
||||
βέβαια έτοιμη εντολή που απλοποιεί τα πράγματα. Στην αμέσως επόμενη γραμμή βάλτε ένα \"συμβατικό\" δομικό \@command (π.χ. \@chapter, \@section) για τα outputs
|
||||
se html/ps/pdf.
|
||||
|
||||
Τo \@menu ορίζει το μενού που θα φαίνεται στην κάτω μεριά του node που βρίσκεται ο χρήστης. Συνήθως περιέχουν pointers σε άλλα nodes του ίδιου manual. Το
|
||||
supernode (μετά από ένα εισαγωγικό κείμενο) δεν είναι παρά ένα μεγάλο μενού με όλα τα manuals του συστήματος. Οι λεπτομέρειες αφήνονται ως άσκηση στον αναγνώστη
|
||||
(Βασικά δεν έχω ασχοληθεί πολύ με μενού ;-)
|
||||
|
||||
Τα outputs του παραπάνω αρχείου είναι τα παρακάτω [\[PDF screenshot\]](/34/img/samplePDF.png) [\[HTML screenshot\]](/34/img/sampleHTML.png) [\[INFO
|
||||
screenshot\]](/34/img/sampleINFO.png)
|
||||
|
||||
|
||||
### [8. Συγγραφή του κυρίως κειμένου.]{#s8}
|
||||
|
||||
Κατά τα άλλα, απλά γράφετε στο body του κειμένου, το τι ακριβώς κάνει το πρόγραμμα σας, ποιες παραμέτρους παίρνει και τι έξοδο πρέπει να περιμένει ο χρήστης.
|
||||
|
||||
Έχετε ανοιγμένο και το manual του texinfo για να βλέπετε τα διάφορα \@commands και την χρήση τους. Θα δείτε ότι το texinfo διαθέτει αρκετά \@commands ειδικά για
|
||||
το documentation προγραμμάτων (σε αντίθεση με το Latex που έχει δώσει μεγαλύτερο βάρος στο επιστημονικό/μαθηματικό κείμενο).
|
||||
|
||||
Υπάρχουν τα \@key για keyboard input, τα \@env για environment variables, τα \@file για ονόματα αρχείων, και διάφορα άλλα \@commands που ανάλογα με την
|
||||
περίπτωση μπορεί να σας φανούν πολύ χρήσιμα. Αυτά τα \@commands καθορίζουν απλά την εμφάνιση του κειμένου πάνω στο οποίο εφαρμόζονται και όχι την δομή του.
|
||||
Προφανώς έχουν περισσότερη σημασία στο τυπωμένο manual αφού η html έχει λίγα tags μορφοποίησης κειμένου, και σχεδόν μηδαμινή στο περιβάλλον κονσόλας.
|
||||
|
||||
Επίσης υπάρχουν όλα τα αναμενόμενα \@commands για list,bullets, subsection,verbatim text,code κ.τ.λ. Όλα βρίσκονται μέσα στο manual του texinfo με παραδείγματα.
|
||||
|
||||
Όπως ίσως έχετε υποψιαστεί για να βάλετε το ίδιο το \"@\" μέσα στο κείμενο το γράφετε δύο φορές δηλαδή \"@@\". Υπάρχει και ειδικό \@command με όνομα \@email.
|
||||
|
||||
|
||||
### [9. Emacs shortcuts]{#s9}
|
||||
|
||||
Αφού το texinfo είναι μέρος της Gnu tool chain (Emacs,gcc,make,gdb, [m4](http://www.gnu.org/software/m4/) ,automake,autoconf,
|
||||
[gprof](http://sources.redhat.com/binutils/docs-2.12/gprof.info/)) δεν ήταν δυνατόν να μην συνεργάζεται άψογα με τον Emacs.
|
||||
|
||||
Έτσι λοιπόν υπάρχει ειδικό Texinfo mode το οποίο διαθέτει πολύ συχνά χρησιμοποιούμενα short commands (Ctrl-c) και λιγότερο συχνά long commands (Meta/Alt-x)
|
||||
Αναφέρω εδώ μερικά:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
C-c C-c n Enter node
|
||||
C-c C-c e Enter end
|
||||
C-c C-c i Enter item
|
||||
C-c C-c v Enter variable
|
||||
C-c C-s Show structure
|
||||
C-c C-u C-m update Menu
|
||||
C-c C-u C-n update Node
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αυτά που πραγματικά σας λύνουν τα χέρια είναι οι εντολές για την εισαγωγή ενός νέου node,αφού συμπληρώνονται αυτόματα τα next,prev, up καθώς και η εντολή που
|
||||
ανοίγει ένα νέο buffer με την δομή του texinfo αρχείου όπου μπορείτε να καταλάβετε οπτικά πως είναι αυτή.
|
||||
|
||||
Γενικά, ακόμα και αν είστε φανατικός χρήστης του vi/vim/gvim σας προτείνω να ασχοληθείτε λίγο με τον Emacs κατά την συγγραφή texinfo αρχείων. Είναι πολύ
|
||||
χρήσιμος, ενώ για πολύ μεγάλα manuals με περίπλοκη δομή/μενού και cross references σχεδόν απαραίτητος.
|
||||
|
||||
|
||||
### [10. Επίλογος]{#s10}
|
||||
|
||||
Ξέρω ότι έδωσα λιγότερες τεχνικές λεπτομέρειες από όσες ίσως θα θέλατε. Δεν αναφέρθηκα στην δημιουργία indexing/table of contents ,cross-references,table και
|
||||
διάφορων άλλων δυνατοτήτων του Texinfo. Υπάρχει και η πολύ εντυπωσιακή δυνατότητα της δημιουργίας link σε εντελώς διαφορετικό manual, όπου μεταφέρεται αυτόματα
|
||||
ο χρήστης, όταν χρησιμοποιεί το info format.
|
||||
|
||||
Έτσι είναι δυνατόν ο χρηστής να διαβάζει το manual του flex μέσα στον Emacs και με ένα κλικ να βρεθεί σε αυτό του bison. Η από αυτό του automake να μεταφερθεί
|
||||
σε αυτό του autoconf και μόλις δει αυτό που θέλει, να επιστρέψει. Σε html και τυπωμένα manual τέτοια links γίνονται απλά \"See the bison manual page 33\" ή κάτι
|
||||
τέτοιο, και πάλι όμως είναι εντυπωσιακή η αυτόματη εισαγωγή τους, αφού εσείς μέσα στο texinfo αρχείο απλά βάζετε το όνομα του manual που θα μεταφερθεί ο χρήστης
|
||||
καθώς και το όνομα του node στο οποίο θα γίνει η μεταφορά.
|
||||
|
||||
Νομίζω όμως ότι ο σκοπός των άρθρων του magaz δεν είναι να σας πάρουν από το χεράκι και να σας δείξουν βήμα-βήμα τις οδηγίες χρήσης. Οφείλετε απλά να δείτε τι
|
||||
υπάρχει διαθέσιμο και αν κάτι σας φαίνεται χρήσιμο να ασχοληθείτε μαζί του.
|
||||
|
||||
686
content/articles/34/03_security.md
Κανονικό αρχείο
686
content/articles/34/03_security.md
Κανονικό αρχείο
|
|
@ -0,0 +1,686 @@
|
|||
+++
|
||||
title = 'Host/network security'
|
||||
date = '2003-06-01T00:00:00Z'
|
||||
description = ''
|
||||
author = 'Αλέξανδρος Παπαδόπουλος apapadop@cmu.edu(mailto:apapadop+magaz@cmu.edu)'
|
||||
issue = ['Magaz 34']
|
||||
issue_weight = 3
|
||||
+++
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Βήματα για να ασφαλίσουμε το GNU/Linux σύστημά μας έναντι τοπικών και δικτυακών επιθέσεων. Ίσως πούμε δυο λογάκια και για θέματα privacy.*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
**1. Τοπική ασφάλεια (Local Access)**
|
||||
----------------------------------------------------------------
|
||||
|
||||
- [1.1 sXid binaries](#ss1.1)
|
||||
- [1.2 Password cracking](#ss1.2)
|
||||
- [1.3 Φυσική πρόσβαση](#ss1.3)
|
||||
|
||||
**2. Δικτυακή ασφάλεια**
|
||||
---------------------------------------------------
|
||||
|
||||
- [2.1 Επιθέσεις Denial of Service (DoS)](#ss2.1)
|
||||
- [2.2 Network Visibility](#ss2.2)
|
||||
- [2.3 Firewalls](#ss2.3)
|
||||
|
||||
**3. Privacy**
|
||||
-----------------------------------------
|
||||
|
||||
- [3.1 Διαφημίσεις (banner ads)](#ss3.1)
|
||||
- [3.2 Cookies](#ss3.2)
|
||||
- [3.3 Web bugs](#ss3.3)
|
||||
|
||||
|
||||
### [1. Τοπική ασφάλεια (Local Access)]{#s1}
|
||||
|
||||
Με αυτό τον όρο εννοούμε τα μέτρα που πρέπει να πάρουμε ώστε κάποιος χρήστης που έχει πρόσβαση στον υπολογιστή μας (είτε φυσική πρόσβαση, είτε user account), να
|
||||
μη μπορεί να αποκτήσει τον έλεγχο του συστήματος (root access).
|
||||
|
||||
### [1.1 sXid binaries]{#ss1.1}
|
||||
|
||||
Ιδιαίτερα επικίνδυνα για αυτό το σκοπό είναι τα suid root binaries. Δηλαδή τα προγράμματα που, ασχέτως του χρήστη που τα καλεί, εκτελούνται πάντα σαν να τα είχε
|
||||
καλέσει ο root. Ο αριθμός των suid root binaries σε ένα σύστημα είναι ένα νούμερο που θέλουμε να το κρατήσουμε όσο το δυνατό μικρότερο, και να ελέγχουμε τακτικά
|
||||
οποιαδήποτε αλλαγή. Μια ατέλεια στον κώδικα ενός εκτελέσιμου προγράμματος αρκεί για να γίνει ένα [buffer
|
||||
overflow](http://www.wikipedia.org/wiki/buffer_overflow), το οποίο, σε suid root binaries, σημαίνει root shell, δηλαδή πλήρη έλεγχο του συστήματος.
|
||||
|
||||
Αν λοιπόν έχουμε μετρήσει όλα τα suid root binaries και ξέρουμε ότι είναι 25 στο σύστημά μας, και μετά από λίγο καιρό ελέγξουμε και βρούμε 26, πρέπει να
|
||||
εξετάσουμε πολύ προσεχτικά αυτό το 26ο πρόγραμμα και να σιγουρευτούμε ότι είναι κάτι που εμείς εγκαταστήσαμε.
|
||||
|
||||
Για μια λίστα με τα setuid και setgid αρχεία στο σύστημά μας, κάνουμε το εξής:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
# find / \( -perm -02000 -o -perm -04000 \) -ls > setXid
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Κατόπιν μπορούμε να μετρήσουμε τις γραμμές αυτού του αρχείου, και έτσι να ξέρουμε πόσα τέτοια (setXid) ειδικά αρχεία έχουμε:
|
||||
|
||||
# wc -l setXid
|
||||
|
||||
Είναι καλή ιδέα να ελέγχουμε περιοδικά το πλήθος αυτών των ειδικών αρχείων και να εντοπίζουμε τυχόν διαφορές.
|
||||
|
||||
### [1.2 Password cracking]{#ss1.2}
|
||||
|
||||
Ακόμα και αν κάποιος καταφέρει να αποκτήσει τοπική πρόσβαση στο σύστημά μας, με κάποιον υπάρχοντα λογαριασμό, έχουμε χάσει μόνο τη μάχη, αλλά όχι απαραιτήτως
|
||||
τον πόλεμο. Για να μην τραβήξει την προσοχή, ο επιτιθέμενος θα προσπαθήσει να μάθει όλα τα συνθηματικά (passwords) των χρηστών του συστήματος, χωρίς να τα
|
||||
αλλάξει. Ακόμα και αν κάποιος έχει root access στο μηχάνημά σας, πρέπει να είναι ιδιαίτερα προσεχτικός για να μην τον ανακαλύψετε. Οπότε, παρόλο που ο root
|
||||
μπορεί να αλλάξει οποιοδήποτε password και να προσθέσει οποιονδήποτε λογαριασμό, η καλύτερη μέθοδος είναι να ξέρει κανείς όλα τα υπάρχοντα συνθηματικά, και να
|
||||
τα χρησιμοποιεί όποτε χρειάζεται πρόσβαση.
|
||||
|
||||
Έχοντας root, ή έχοντας καταφέρει να διαβάσει το αρχείο /etc/shadow με κάποιο άλλο τρόπο, ο επιτιθέμενος θα προσπαθήσει να μάθει όλα τα συνθηματικά που
|
||||
βρίσκονται σε αυτό το αρχείο. Αν τα συνθηματικά ακολουθούν τους κανόνες των δυνατών passwords, κάτι τέτοιο θα είναι από πολύ δύσκολο έως πρακτικά αδύνατο.
|
||||
|
||||
Ο καλύτερος τρόπος για να διαπιστώσετε πόσο ισχυρά είναι τα συνθηματικά που χρησιμοποιούνται στο σύστημά σας, είναι να προσπαθήσετε να τα \"σπάσετε\" (crack)
|
||||
μόνοι σας. Χρησιμοποιώντας το καλύτερο password cracker για συστήματα UNIX [(John the Ripper)](http://www.openwall.com%20john/), θα μάθετε αν το συνθηματικό σας
|
||||
θα αντέξει σε τέτοιου είδους επιθέσεις.
|
||||
|
||||
Η χρήση του John είναι πολύ απλή: Αφού κατεβάσετε το tarball (\*.tar.gz), το κάνετε extract (tar xvfz \*.tar.gz), μπαίνετε στον κατάλογο john-1.x/src/ και
|
||||
δίνετε ένα
|
||||
|
||||
$ make
|
||||
|
||||
Αυτό θα σας πει τις επιλογές που έχετε, και θα διαλέξετε την πιο κατάλληλη για το σύστημά σας. Μόλις τελειώσει το compile, μπείτε στον κατάλογο john-1.x/run/
|
||||
και:
|
||||
|
||||
# ./unshadow /etc/passwd /etc/shadow > passwords
|
||||
$ ./john passwords
|
||||
|
||||
Ο John θέλει λίγα δευτερόλεπτα για να μαντέψει τα τελείως ελεεινά συνθηματικά (όμοια με το όνομα χρήστη, κάτω από 4 χαρακτήρες, λέξεις λεξικού), αλλά μπορεί να
|
||||
τρέχει επί εβδομάδες χωρίς να μπορεί να βρει ένα δυνατό password 8 χαρακτήρων.
|
||||
|
||||
Καλά συνθηματικά είναι αυτά που έχουν τα εξής στοιχεία:
|
||||
|
||||
- Έχουν τουλάχιστον 6 χαρακτήρες
|
||||
- Περιέχουν τουλάχιστον έναν χαρακτήρα από τις εξής κατηγορίες:
|
||||
- Kεφαλαία (A-Z)
|
||||
- Πεζά (a-z)
|
||||
- Aριθμούς (0-9)
|
||||
- Eιδικούς χαρακτήρες (!, @, \#, %, : κτλ.)
|
||||
- Δεν συνδέονται με κάτι που μπορεί να μαντέψει ο επιτιθέμενος αν σας γνωρίζει προσωπικά (ημερομηνία γέννησης, όνομα συγγενή κτλ)
|
||||
- Είναι αρκετά εύκολα να τα θυμάστε εσείς και να τα πληκτρολογείτε ώστε να μη σας σπάνε τα νεύρα! Δε λέω, καλό συνθηματικό το **kj%{8\*\#I**, αλλά δεν
|
||||
πρόκειται να το θυμάμαι για πάνω από 2 λεπτά, **ή** (ακόμα χειρότερα), άπαξ και το μάθω δεν θα θέλω να το αλλάξω ποτέ επειδή είναι το πλέον uncrackable
|
||||
συνθηματικό. Αυτή είναι εξίσου κακή πρακτική με το να έχετε πολύ εύκολα συνθηματικά, επειδή αν κάποιος καταφέρει να κλέψει αυτό το συνθηματικό
|
||||
παρακολουθώντας το δίκτυο, πχ, θα έχει αιώνια πρόσβαση στο μηχάνημά σας.
|
||||
- Δεν είναι λέξη σε οποιαδήποτε γλώσσα! Αν νομίζετε ότι ένα συνθηματικό σε Σουαχίλι ή από κάποιον επιστημονικό κλάδο σας σώζει, ρίξτε μια ματιά στις
|
||||
[λίστες](ftp://ftp.ox.ac.uk/pub/wordlists/) που κυκλοφορούν.
|
||||
|
||||
Μια καλή πρακτική είναι να δημιουργούμε συνθηματικά από χαρακτήρες φράσεων που μπορούμε να τις θυμηθούμε εύκολα, αλλά αν δεν ξέρει κάποιος την φράση, το
|
||||
συνθηματικό να μην έχει κανένα νόημα. Παράδειγμα: Ας πούμε ότι το αγαπημένο σας τραγούδι είναι το \"Welcome to the machine\" των Pink Floyd. Από τους πρώτους
|
||||
χαρακτήρες κάθε λέξης, βγάζουμε το εξής: Wttm\_PF, που δεν είναι καθόλου άσχημο, αλλά δεν σέβεται όλους τους κανόνες ενός καλού συνθηματικού. Οπότε
|
||||
αντικαθιστούμε μερικούς χαρακτήρες με αριθμούς σε \"leet-speak lingo\": **W11m-PF** και ιδού!
|
||||
|
||||
### [1.3 Φυσική πρόσβαση]{#ss1.3}
|
||||
|
||||
Για να προστατέψουμε τον υπολογιστή μας από επιθέσεις με φυσική πρόσβαση, όπου ο χρήστης κάθεται στο πληκτρολόγιο, χρειαζόμαστε πολλά και διάφορα. Ο γενικός
|
||||
κανόνας είναι ότι \"φυσική πρόσβαση = root πρόσβαση\", για τους εξής λόγους:
|
||||
|
||||
Ας πούμε ότι αφήνουμε τον υπολογιστή μας και πεταγόμαστε στο διπλανό δωμάτιο για μερικά λεπτά. Αν κάποιος θέλει να αποκτήσει πρόσβαση στον υπολογιστή μας,
|
||||
μπορεί απλά να κάτσει στο πληκτρολόγιο και να ψάξει για τυχόν root logins που έχουμε αφήσει ενεργά. Λύση: ΠΟΤΕ μην αφήνετε root logins ενεργά χωρίς πολύ καλό
|
||||
λόγο. Αν χρειάζεται να τρέχει κάτι σαν root για μεγάλα χρονικά διαστήματα, μπορείτε να το καλέσετε με έναν τρόπο που να κάνει logout μόλις τερματιστεί η
|
||||
εργασία. Παράδειγμα:
|
||||
|
||||
# tail -f /var/log/messages ; logout
|
||||
|
||||
Με αυτή τη γραμμή, μπορείτε να αφήσετε ένα root terminal με σχετική ασφάλεια, επειδή αν κάποιος διακόψει την εργασία με CTRL+C, εκτελείται αμέσως το logout και
|
||||
χάνεται το root shell.
|
||||
|
||||
Αλλά ακόμα και η πρόσβαση σαν κανονικός χρήστης μπορεί να είναι καταστροφική. Πχ, μπορεί κάποιος να σβήσει/διαβάσει/διαφθείρει όλα τα προσωπικά σας αρχεία, να
|
||||
στείλει email με το όνομά σας και άλλα δυσάρεστα. Μια λύση είναι όταν δουλεύετε στο γραφικό περιβάλλον να κλειδώνετε το τερματικό πριν φύγετε από το
|
||||
πληκτρολόγιο (όλοι οι μοντέρνοι window managers μπορούν να καλέσουν το xlock που κάνει ακριβώς αυτή τη δουλειά).
|
||||
|
||||
Τι γίνεται όμως αν κάποιος πατήσει απλά CTRL+ALT+Backspace και \"σκοτώσει\" το γραφικό περιβάλλον; Δεν θα μείνει με ένα shell του χρήστη μας;
|
||||
|
||||
Δεν είναι απαραίτητο. Για να αποφύγουμε αυτό το πρόβλημα μπορούμε να προσθέσουμε ένα alias στο .bashrc μας, που να θέτει:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
alias startx="startx -- -nolisten tcp; logout"
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Έτσι, με το που τερματίσουμε με οποιοδήποτε τρόπο το X session μας, ο χρήστης μας κάνει αυτόματα logout. Για τη σημασία του **\"-nolisten tcp\"** θα μιλήσουμε
|
||||
παρακάτω.
|
||||
|
||||
Όμως ακόμα και αν ο επιτιθέμενος δεν βρει έτοιμο prompt στο μηχάνημά μας, δεν μπορεί να το εκμεταλλευτεί; Σίγουρα, αν έχουμε \"ευκολίες\" όπως automount και
|
||||
autoexec στο CDROM. Μια δυσάρεστη έκπληξη που είχα σε ένα φρεσκο-εγκατεστημένο σύστημα ήταν όταν έβαλα ένα δισκάκι στο CD drive και μετά από λίγα δευτερόλεπτα
|
||||
είδα τον Mozilla να ανοίγει ένα παράθυρο και να μου δείχνει την \"αρχική σελίδα\" του CD, παίζοντας περιχαρώς **μουσική**! Τι θα γινόταν αν αυτό το CD είχε
|
||||
κώδικα με περίεργες προθέσεις, που περίμενε την αρχική σελίδα (index.html) για να ενεργοποιηθεί;
|
||||
|
||||
Για να αποφύγουμε τέτοιες εκπλήξεις καλό είναι να απενεργοποιήσουμε οποιοδήποτε automount και να σιγουρευτούμε ότι το mount γίνεται με ασφαλείς παραμέτρους.
|
||||
Μερικές χρήσιμες παράμετροι είναι oι noexec, nosuid. Ρίξτε μια ματιά στο man mount για περισσότερα.
|
||||
|
||||
Αλλά και πάλι, αν κάποιος μπορεί να επανεκκινήσει τον υπολογιστή, μπορεί να επιλέξει από τον boot loader (LILO, GRUB ή οτιδήποτε άλλο χρησιμοποιούμε) να κάνει
|
||||
boot σε single mode, όπου έχει πλήρη έλεγχο του συστήματος. Για να αποκλείσουμε και αυτή την πιθανότητα, μπορούμε να βάλουμε έναν κωδικό στον boot loader. Έτσι,
|
||||
μόνο όποιος ξέρει τον κωδικό μπορεί να ξεκινήσει το σύστημα. Αυτό επιτυγχάνεται στα αρχεία /etc/lilo.conf και /etc/grub.conf (για τους δύο πιο δημοφιλείς boot
|
||||
loaders).
|
||||
|
||||
Όμως ποιος τα χρειάζεται όλα αυτά, όταν υπάρχει το [KNOPPIX](http://www.knopper.net/knoppix/index-en.html); Απλά κάνουμε ένα reboot τον υπολογιστή, βάζουμε το
|
||||
δισκάκι στο drive, παρακάμπτουμε ό,τι είδους ασφάλεια υπάρχει, και κάνουμε mount τον δίσκο του θύματος με πλήρη δικαιώματα! Εύκολο; Όχι τόσο γρήγορα. Γι\'αυτό
|
||||
υπάρχουν τα [BIOS](http://www.webopedia.com/TERM/B/BIOS.html) passwords, που ζητούν τον κωδικό του χρήστη πριν επιτρέψουν σε κάποιον να αλλάξει τη συνηθισμένη
|
||||
σειρά εκκίνησης και να κάνει boot από CD ή δισκέτα.
|
||||
|
||||
Αλλά αν έχετε laptop πχ, και ο \"κακός\" μπορεί να βουτήξει απλά ολόκληρο το laptop ή να βγάλει στο πι και φι τον δίσκο και να τον πάρει μαζί του; Αυτή είναι
|
||||
μάλλον η χειρότερη περίπτωση, και το μόνο που μας σώζει είναι κάποιο encrypted filesystem, που δεν επιτρέπει στον δίσκο να διαβαστεί από κάποιον που δεν έχει το
|
||||
κατάλληλο λογισμικό και δεν ξέρει το σωστό συνθηματικό (pass-phrase) για να τον αποκωδικοποιήσει. Επειδή δεν έχω εμπειρία σε κάτι τέτοιο, θα σας προτείνω απλά
|
||||
να κωδικοποιείτε με το [Gnu Privacy Guard (GPG)](http://gnupg.org) οτιδήποτε δεν θέλετε να πέσει με τίποτα σε λάθος χέρια.
|
||||
|
||||
Δεν είναι καθόλου δύσκολο! Αν έχετε ήδη [δημιουργήσει τα κλειδιά](http://andrew.cmu.edu/~apapadop/linux/howto.html#3.3.7) σας και μπορείτε να χρησιμοποιήσετε το
|
||||
gpg, μπορείτε να μαζέψετε όλα τα ευαίσθητα αρχεία σας σε έναν κατάλογο (ας πούμε secret/). Με ένα
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ tar -cf secret.tar secret
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
δημιουργείτε ένα αρχείο που περιέχει ολόκληρο τον κατάλογο secret. Μετά μπορείτε να κωδικοποιήσετε (encrypt) το αρχείο αυτό με το προσωπικό σας κλειδί, ώστε
|
||||
μόνο εσείς να μπορείτε να το αποκωδικοποιήσετε στο μέλλον:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ gpg -esr apapadop@cmu.edu secret.tar
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
(αντικαταστήστε το email μου με το email που αντιστοιχεί στο προσωπικό κλειδί σας) Αυτή η εντολή θα έχει σαν αποτέλεσμα ένα αρχείο secret.tar.gpg που θα
|
||||
μπορείτε μόνο εσείς να το διαβάσετε. Μπορείτε να ελέγξετε αν το σύστημα δουλεύει σωστά με τις εξής εντολές:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ gpg -d -o test.tar secret.tar.gpg
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αυτή η εντολή θα αποκωδικοποιήσει το αρχείο και θα το σώσει σαν test.tar. Για να δοκιμάσουμε αν έχει την παραμικρή διαφορά από το αυθεντικό αρχείο που έχει τα
|
||||
ευαίσθητα περιεχόμενα, δίνουμε
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ md5sum test.tar secret.tar
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αν το αποτέλεσμα δεν είναι ακριβώς το ίδιο, κάτι δεν πήγε καλά. Αν το checksum όμως είναι το ίδιο, μπορούμε να σβήσουμε τον κατάλογο με τα ευαίσθητα αρχεία
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ rm -r secret/
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
και να αποκρυπτογραφήσουμε/αποσυμπιέσουμε ξανά τα περιεχόμενά του όποτε τα χρειαστούμε με τις εντολές
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
$ gpg -d -o secret.tar secret.tar.gpg
|
||||
$ tar xvf secret.tar
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αν τα παραπάνω σας φαίνονται υπερβολικά, θυμηθείτε ότι υπάρχουν εργαστήρια που διαβάζουν δεδομένα χωρίς κανένα πρόβλημα από [καμένους
|
||||
υπολογιστές](http://www.datarr.com/tfds.html), συσκευές που [διαβάζουν οθόνες πίσω από τοίχους](http://www.sans.org/rr%20encryption/TEMPEST.php) και κυβερνήσεις
|
||||
που θεωρούν σκόπιμο το [ψήσιμο](http://treachery.net/~jdyson/dod_cd_declassification.html) των CD που θέλουν να αποσύρουν\...
|
||||
|
||||
|
||||
### [2. Δικτυακή ασφάλεια]{#s2}
|
||||
|
||||
Σε αυτή την ενότητα θα εξετάσουμε τις επιθέσεις DOS και τα μέτρα που μπορούμε να πάρουμε για να αμυνθούμε. Κατόπιν θα αναφέρουμε διάφορες βασικές αρχές για τις
|
||||
δικτυακές σας περιπέτειες, που (ελπίζω) θα σας γλιτώσουν από πολλές δυσάρεστες γνωριμίες\...
|
||||
|
||||
### [2.1 Επιθέσεις Denial of Service (DoS)]{#ss2.1}
|
||||
|
||||
[Αυτές οι επιθέσεις](http://www.wikipedia.org/wiki%20Denial_of_service) έχουν σαν σκοπό τους να μην επιτρέψουν στο σύστημά μας να επιτελέσει τον στόχο του.
|
||||
Δηλαδή, αν έχουμε κάποιον server που παρέχει υπηρεσίες email για μια εταιρεία, ο σκοπός της επίθεσης DoS είναι να μη μπορεί πλέον ο συγκεκριμένος server να
|
||||
παρέχει αυτές τις υπηρεσίες. Οι επιθέσεις αυτές είναι ή μέρος μιας ιδιαίτερα συντονισμένης και μελετημένης επίθεσης (οπότε δε μας σώζει τίποτα), ή το τελευταίο
|
||||
στάδιο της απογοήτευσης για έναν φιλόδοξο επιτιθέμενο που δεν μπορεί να μπει στο σύστημά μας και απλά καταφεύγει στην επίδειξη δύναμης, προσπαθώντας να μας
|
||||
\"πετάξει έξω από το δίκτυο\".
|
||||
|
||||
Υπάρχουν πολλές περιπτώσεις στις οποίες επιθέσεις DoS έχουν χρησιμοποιηθεί για να επιτευχθεί κάποιος άλλος σκοπός. Παράδειγμα: Ο επιτιθέμενος καταφέρνει
|
||||
προσωρινό DoS ενός SSH server για 10 κρίσιμα λεπτά. Σε αυτά τα 10 λεπτά, κάποιος νόμιμος χρήστης προσπαθεί να συνδεθεί στον SSH server, αλλά ο επιτιθέμενος
|
||||
δίνει στο μηχάνημά του την IP του SSH server (που δεν μπορεί να απαντήσει), και προσκαλεί τον χρήστη να συνδεθεί στο μηχάνημά του. Ο χρήστης βλέπει ένα
|
||||
[περίεργο μήνυμα](http://www.hpcvl.org/faqs/ssh_help.html#answer_4) ότι το fingerprint του server έχει αλλάξει, λέει \"ώχου μωρέ τώρα\" και επιλέγει να
|
||||
συνδεθεί, αγνοώντας το μήνυμα. Ο επιτιθέμενος δέχεται την σύνδεση του χρήστη-θύματος, σταματάει το DoS του πραγματικού SSH server, και επιπροσθέτως του στέλνει
|
||||
όλα τα πακέτα του θύματος. Αποτέλεσμα; Ο χρήστης κάνει κανονικά τη δουλειά του στον server, και ο επιτιθέμενος βλέπει και καταγράφει τα πάντα σε clear text,
|
||||
μαθαίνοντας συνθηματικά, λογαριασμούς, άλλους κωδικούς, προσωπικά στοιχεία του θύματος, κτλ. Συγχαρητήρια, μόλις λάβατε μέρος σε μια επίθεση man-in-the-middle.
|
||||
Το συγκεκριμένο σενάριο μπορεί να πραγματοποιηθεί πανεύκολα με παλιά SSH πρωτόκολλα και το εκπληκτικό πακέτο
|
||||
[dsniff](http://naughty.monkey.org/~dugsong/dsniff/).
|
||||
|
||||
Δυστυχώς δεν υπάρχει καμία καθολική λύση για το πρόβλημα των DoS. Για την ακρίβεια, με την άνθιση των DDoS (Distributed Denial of Service) επιθέσεων, τα
|
||||
πράγματα γίνονται διαρκώς χειρότερα. Πάντως, μερικά βήματα που μπορούμε να ακολουθήσουμε για να αντιμετωπίσουμε τις πιο παραδοσιακές επιθέσεις DoS ( [SYN
|
||||
floods](http://www.cert.org/advisories/CA-1996-21.html) και ping floods) είναι τα εξής:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
# Ενεργοποιούμε προστασία έναντι επιθέσεων SYN flood
|
||||
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
|
||||
# Μην απαντάς σε ICMP echo requests (προστατεύει έναντι ping floods)
|
||||
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Επίσης μπορούμε να χρησιμοποιήσουμε το module LIMIT που παρέχει το [netfilter](http://netfilter.org), το σύστημα που διαχειρίζεται τα πακέτα στο επίπεδο του
|
||||
πυρήνα, με κάτι σαν:
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Αυτός ο κανόνας λέει στον πυρήνα να δέχεται μόνο μία νέα TCP σύνδεση ανά δευτερόλεπτο, και να αγνοεί τις υπόλοιπες. Γενικά ο πυρήνας έχει αρκετές δυνατότητες
|
||||
άμυνας έναντι DoS επιθέσεων μέσω του συστήματος netfilter και των ρυθμίσεων στον κατάλογο /proc/sys/net/ipv4.
|
||||
|
||||
### [2.2 Network Visibility]{#ss2.2}
|
||||
|
||||
**\...ή, πόσο μεγάλο στόχο δίνουμε.**
|
||||
|
||||
Εκτός από τις DoS, που έχουν έναν πολύ συγκεκριμένο σκοπό, υπάρχουν και άλλες επιθέσεις, που συνήθως έχουν σκοπό την εκμετάλλευση κάποιου bug σε ένα service του
|
||||
υπολογιστή μας. Παράδειγμα: Υπάρχουν \"εργαλεία\" που μπορεί να βρει ο καθένας στο Internet, και να δίνουν άμεσο root access αν χρησιμοποιηθούν εναντίον
|
||||
συστημάτων που τρέχουν παλιές εκδόσεις του HTTP server Apache. Όσο γρήγορα και να αναβαθμίζουμε το σύστημά μας όταν ο διανομέας βγάζει patches που κλείνουν
|
||||
αυτές τις τρύπες, υπάρχει πάντα μια ακαθόριστη περίοδος προτού γνωστοποιηθεί το bug, κατά την οποία το σύστημά μας είναι ευάλωτο. Ό,τι και να κάνουμε, και όσα
|
||||
firewalls και να έχουμε, κάποτε συμβαίνει σε όλους.
|
||||
|
||||
Οπότε εκτός από τα άμεσα patches, μια **πολύ** καλή ιδέα είναι να μην έχετε κανένα ενεργό service στο σύστημά σας, εκτός από τα τελείως απαραίτητα. Έτσι οι
|
||||
ευκαιρίες για εκμετάλλευση bugs ελαχιστοποιούνται, επειδή κανείς δεν μπορεί να εκμεταλλευτεί ένα πρόγραμμα που δεν τρέχει!
|
||||
|
||||
Αυτές οι επιθέσεις είναι πιο δύσκολες στον εντοπισμό από τις DoS, μιας και δεν δημιουργούν άμεσα προβλήματα στο σύστημά μας. Σχεδόν όλες ξεκινούν με
|
||||
αναγνωριστικές κινήσεις, όπως portscans και προσπάθειες σύνδεσης σε συνήθεις πόρτες (80-http, 22-ssh, 23-telnet, 25-smtp, 110-pop3 κτλ). Η καλύτερη άμυνα είναι
|
||||
να ρυθμίσουμε το μηχάνημά μας ώστε να μη δίνει καν στόχο. Η κλασσική λύση που ακούγεται παντού είναι ένα firewall, αλλά υπάρχει κάτι πολύ πιο σημαντικό: το να
|
||||
κλείσουμε οποιαδήποτε πόρτα / δικτυακό service δεν χρειαζόμαστε.
|
||||
|
||||
Μία default εγκατάσταση μιας μοντέρνας \"φιλικής προς το χρήστη\" διανομής, συνήθως αφήνει πολλές περιττές πόρτες ανοιχτές στον υπολογιστή μας. Μπορούμε να
|
||||
δούμε ποια services έχουμε ενεργά με ένα
|
||||
|
||||
# lsof -i
|
||||
|
||||
ή, από την μεριά του επιτιθέμενου (χρήσιμο για να καταλάβουμε τι μπορούν να δουν οι άλλοι για το μηχάνημά μας):
|
||||
|
||||
# nmap <η_ΙΡ_μου>
|
||||
|
||||
Για να δούμε τι βλέπω για το σύστημά μου:
|
||||
|
||||
# lsof -i
|
||||
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
|
||||
privoxy 14769 privoxy 3u IPv4 173542 TCP localhost.localdomain:6969
|
||||
(LISTEN)
|
||||
# ifconfig wlan0
|
||||
wlan0 Link encap:Ethernet HWaddr 00:20:E0:8D:01:2D
|
||||
inet addr:192.168.1.106 Bcast:192.168.1.255 Mask:255.255.255.0
|
||||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||||
RX packets:58578 errors:0 dropped:0 overruns:0 frame:0
|
||||
TX packets:69317 errors:0 dropped:0 overruns:0 carrier:0
|
||||
collisions:0 txqueuelen:100
|
||||
RX bytes:34820912 (33.2 MiB) TX bytes:2989402 (2.8 MiB)
|
||||
|
||||
# nmap -p1-65535 192.168.1.106
|
||||
|
||||
Starting nmap V. 3.10ALPHA4 ( www.insecure.org/nmap/ )
|
||||
All 65535 scanned ports on 192.168.1.106 are: closed
|
||||
|
||||
Nmap run completed -- 1 IP address (1 host up) scanned in 100.306 seconds
|
||||
|
||||
Τί μας λένε τα παραπάνω; Με την εντολή lsof -i βλέπω μια υπηρεσία (privoxy) να \"ακούει\" (LISTEN) για τοπικές συνδέσεις TCP στην πόρτα 6969 (TCP
|
||||
localhost.localdomain:6969). Αλλά το nmap μου λέει ότι όλες οι πόρτες είναι κλειστές! Τι γίνεται εδώ;
|
||||
|
||||
Ο privoxy στην συγκεκριμένη περίπτωση \"ακούει\" μόνο για συνδέσεις στη διεύθυνση localhost.localdomain:6969. Επειδή αυτό το όνομα δεν είναι δυνατόν να
|
||||
χρησιμοποιηθεί για απομακρυσμένες δικτυακές συνδέσεις (είναι alias για το τοπικό μηχάνημα, και δεν μπορεί να χρησιμοποιηθεί σαν δικτυακό όνομα με το παρόν
|
||||
σύστημα [DNS](http://www.webopedia.com/TERM/D/DNS.html)), ο privoxy φαίνεται σαν να μην υπάρχει όταν κάποιος εξετάζει τις πόρτες μας από το δίκτυο (γι\'αυτό
|
||||
χρησιμοποίησα την εξωτερική μου IP στο nmap - αν είχα χρησιμοποιήσει την 127.0.0.1 θα είχα διαφορετικά αποτελέσματα). Για τις χάρες του privoxy θα μιλήσουμε
|
||||
στην επόμενη ενότητα. Όπως είδαμε, δεν φαίνεται καν να υπάρχει από το δίκτυο. Άρα δεν το θεωρώ ευάλωτο σημείο.
|
||||
|
||||
Σε μια default εγκατάσταση κάποιας μοντέρνας διανομής, δυστυχώς έχουμε μεγάλες πιθανότητες να δούμε μια ελαφρώς διαφορετική εικόνα:
|
||||
|
||||
[root@helios root]# lsof -i
|
||||
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
|
||||
privoxy 14769 privoxy 3u IPv4 173542 TCP localhost.localdomain:6969
|
||||
(LISTEN)
|
||||
tcpserver 14781 root 3u IPv4 176623 TCP *:44444 (LISTEN)
|
||||
tcpserver 14783 root 3u IPv4 176629 TCP *:2121 (LISTEN)
|
||||
smbd 14793 root 9u IPv4 176648 TCP *:netbios-ssn (LISTEN)
|
||||
xinetd 14814 root 5u IPv4 179758 UDP *:ntalk
|
||||
httpd 14831 root 3u IPv4 185996 TCP *:http (LISTEN)
|
||||
httpd 14886 apache 3u IPv4 185996 TCP *:http (LISTEN)
|
||||
|
||||
Όλα αυτά τα (LISTEN) δεν είναι καθόλου απαραίτητα, εκτός κι\'αν ξέρετε τι κάνετε. Αν δεν ξέρετε τι σημαίνει κάποια καταχώρηση (όπως πχ. netbios-ssn), μπορείτε
|
||||
να την αναζητήσετε στο αρχείο /etc/services για περισσότερες πληροφορίες:
|
||||
|
||||
$ grep netbios-ssn /etc/services
|
||||
netbios-ssn 139/tcp # NETBIOS session service
|
||||
netbios-ssn 139/udp
|
||||
|
||||
Το μηχάνημα που δεν δείχνει τίποτα να ακούει (LISTENing), είναι σχεδόν αόρατο στο δίκτυο. Είναι εξαιρετικά δύσκολο για κάποιον επιτιθέμενο να το βρει και να του
|
||||
επιτεθεί. Πώς ξεφορτωνόμαστε όλα αυτά τα LISTEN λοιπόν;
|
||||
|
||||
Ανάλογα με τη διανομή που χρησιμοποιούμε ( [Debian](http://www.debian.org), [Slackware](http://www.slackware.com), [Red Hat](http://www.redhat.com),
|
||||
[Gentoo](http://www.gentoo.org) κτλ), υπάρχουν διαφορετικοί τρόποι ελέγχου των υπηρεσιών (services) που είναι ενεργές στον υπολογιστή μας. Οι περισσότερες
|
||||
διανομές GNU/Linux χρησιμοποιούν System V init scripts, δηλαδή αποθηκεύουν τα scripts που ελέγχουν τις υπηρεσίες στους καταλόγους /etc/rcX.d, όπου Χ είναι μια
|
||||
τιμή από 0 έως 6. Αυτή η τιμή αντιστοιχεί στο runlevel του συστήματος. Το runlevel στο οποίο λειτουργεί το σύστημα αμέσως μετά την εκκίνησή του (boot) το
|
||||
βρίσκουμε με ένα
|
||||
|
||||
# grep default /etc/inittab
|
||||
|
||||
Στο δικό μου σύστημα αυτό δίνει:
|
||||
|
||||
# The default runlevel.
|
||||
id:2:initdefault:
|
||||
|
||||
που σημαίνει ότι αν θέλω να κάνω κάποιες υπηρεσίες να μην ενεργοποιούνται σε κάθε επανεκκίνηση, πρέπει να τις απενεργοποιήσω από το φάκελο /etc/rc2.d .
|
||||
|
||||
Αν κάνουμε ένα
|
||||
|
||||
ls -l
|
||||
|
||||
μέσα σε αυτό το φάκελο, θα δούμε ότι υπάρχουν πολλά symbolic links με τα ονόματα όλων των διαθέσιμων υπηρεσιών. Αν θέλουμε να μην ξεκινάει σε κάθε εκκίνηση ο
|
||||
http daemon (httpd) (που είναι συνήθως ο [Apache](http://www.apache.org)), απλά σβήνουμε το link SXXhttpd (όπου ΧΧ η προτεραιότητα με την οποία ενεργοποιείται
|
||||
κατά την εκκίνηση αυτό το service).
|
||||
|
||||
Ωραία, ο web server δεν θα ξεκινάει σε κάθε εκκίνηση από δω και στο εξής. Πώς όμως τον σταματάμε εδώ και τώρα;
|
||||
|
||||
Αν προσέξατε, όλα τα symbolic links στον κατάλογο που είμαστε \"δείχνουν\" σε αρχεία του καταλόγου ../init.d (δηλαδή στο /etc/init.d). Για να σταματήσουμε ή να
|
||||
ξεκινήσουμε μια υπηρεσία αμέσως, καλούμε το script που την ελέγχει με την παράμετρο stop ή start:
|
||||
|
||||
Αυτή η εντολή ενεργοποιεί άμεσα τον HTTP server:
|
||||
|
||||
# /etc/init.d/httpd start
|
||||
|
||||
Αυτή η εντολή τον σταματάει:
|
||||
|
||||
# /etc/init.d/httpd stop
|
||||
|
||||
Με αυτό τον τρόπο μπορούμε να ξεφορτωθούμε και οποιεσδήποτε άλλες υπηρεσίες που είναι ενεργές χωρίς λόγο. Υπενθύμιση: σε ένα home PC, η εντολή
|
||||
|
||||
# lsof -i
|
||||
|
||||
δεν πρέπει να δείχνει τίποτα που να \"ακούει\" (LISTEN) για συνδέσεις από το δίκτυο (\*:port\_number).
|
||||
|
||||
ΣΗΜΕΙΩΣΗ: Υπάρχουν μερικές ειδικές περιπτώσεις, όπως το port 6000 (X11), το οποίο είναι περιττό για το 99% των συστημάτων για αποκλειστικά προσωπική χρήση, και
|
||||
έχει γνωστά προβλήματα ασφάλειας (οποιοσδήποτε στο δίκτυο μπορεί να δει τι πληκτρολογείτε). Οπότε είναι πολύ καλή ιδέα να το κλείσετε, καλώντας τα X με την
|
||||
παράμετρο -nolisten tcp:
|
||||
|
||||
$ startx -- -nolisten tcp
|
||||
|
||||
### [2.3 Firewalls]{#ss2.3}
|
||||
|
||||
Tα firewalls είναι προγράμματα ή συσκευές που ελέγχουν τα δεδομένα που ταξιδεύουν σε ένα δίκτυο. Σε προσωπικό επίπεδο, μπορούμε να τα χρησιμοποιήσουμε για να
|
||||
ελέγξουμε τις δικτυακές συνδέσεις του υπολογιστή μας και να δυναμώσουμε την άμυνά μας έναντι δικτυακών επιθέσεων. Στο GNU/Linux το
|
||||
[firewalling](http://www.wikipedia.org/wiki/firewall) γίνεται από το σύστημα [netfilter](http://www.netfilter.org), που ελέγχεται από το πρόγραμμα iptables.
|
||||
|
||||
Σε όλες τις μοντέρνες διανομές το σύστημα netfilter είναι ενεργοποιημένο στον πυρήνα Linux και το πρόγραμμα netfilter υπάρχει προεγκατεστημένο. Συνεπώς το μόνο
|
||||
που έχουμε να κάνουμε είναι να δώσουμε τους κανονισμούς σύμφωνα με τους οποίους θα διαχειρίζεται ο πυρήνας τα δικτυακά δεδομένα που έρχονται και φεύγουν από τον
|
||||
υπολογιστή μας.
|
||||
|
||||
Δεν θα μπούμε σε λεπτομέρειες, επειδή το firewalling είναι αρκετά μεγάλο θέμα. Θα σας δείξω τα rules που χρησιμοποιώ στο laptop μου, με σχόλια που θα εξηγούν τι
|
||||
κάνει το κάθε rule. Το παρόν ruleset έχει βασιστεί στο εξαιρετικό [tutorial του James C. Stephens.](http://www.sns.ias.edu/~jns/security/iptables/index.html)
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
if [ -z $1 ]; then
|
||||
# Δεν έχουμε command line argument, οπότε δεν αφήνουμε κανέναν να συνδεθεί με
|
||||
SSH σε μας.
|
||||
echo Disallowing SSH access...
|
||||
NOSSH=1
|
||||
else
|
||||
# Έχουμε IP address στη γραμμή εντολών, που θέλουμε να συνδέεται σε μας με
|
||||
SSH.
|
||||
echo Allowing SSH access for $1...
|
||||
fi
|
||||
|
||||
##############################
|
||||
#### ΓΕΝΙΚΕΣ ΠΡΟΦΥΛΑΞΕΙΣ #####
|
||||
##############################
|
||||
|
||||
## Μην απαντάς σε ping.
|
||||
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
|
||||
|
||||
## Μην απαντάς σε broadcasts.
|
||||
/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
|
||||
|
||||
## Μη δέχεσαι source routed πακέτα.
|
||||
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
|
||||
|
||||
## Μη κάνεις ICMP redirect.
|
||||
/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
|
||||
|
||||
## Προστασία έναντι περίεργων λαθών.
|
||||
/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
|
||||
|
||||
## Ενεργοποίησε το reverse path filtering.
|
||||
for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do
|
||||
/bin/echo "1" > ${interface}
|
||||
done
|
||||
|
||||
## Σημείωσε στα system logs (/var/log/messages by default) τα πακέτα που
|
||||
φαίνεται να έχουν ψεύτικες διευθύνσεις ή γενικώς να είναι ύποπτα.
|
||||
/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
|
||||
|
||||
## Μην λειτουργείς σαν router (μην προωθείς πακέτα σε άλλες διευθύνσεις).
|
||||
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward
|
||||
|
||||
##################
|
||||
#### FIREWALL ####
|
||||
##################
|
||||
|
||||
## Φόρτωσε τα connection-tracking modules.
|
||||
/sbin/modprobe ipt_state
|
||||
/sbin/modprobe ip_conntrack
|
||||
/sbin/modprobe ip_conntrack_ftp #ports=2121
|
||||
#/sbin/modprobe ipt_owner
|
||||
|
||||
## Καθάρισε τυχόν ενεργά rules
|
||||
/sbin/iptables -F
|
||||
## Διέγραψε τυχόν custom tables
|
||||
/sbin/iptables -X
|
||||
## Μηδένισε όλους τους μετρητές πακέτων
|
||||
/sbin/iptables -Z
|
||||
|
||||
## By default κάνουμε DROP (αγνοούμε) όλα τα πακέτα (ώστε να περνάνε μόνο αυτά
|
||||
που έχουν λόγο να περνάνε)
|
||||
/sbin/iptables -P INPUT DROP
|
||||
/sbin/iptables -P FORWARD DROP
|
||||
/sbin/iptables -P OUTPUT DROP
|
||||
|
||||
|
||||
#####################
|
||||
#### ΕΙΣΕΡΧΟΜΕΝΑ ####
|
||||
#####################
|
||||
|
||||
## Δεχόμαστε όλες τις τοπικές συνδέσεις
|
||||
/sbin/iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -i lo -j ACCEPT
|
||||
|
||||
## Δεχόμαστε πακέτα από όλες τις ήδη υπάρχουσες συνδέσεις (λόγω των υπολοίπων
|
||||
rules, αναγκαστικά τις έχουμε ξεκινήσει εμείς οπότε υποθέτουμε ότι είναι
|
||||
ασφαλείς)
|
||||
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||||
|
||||
if [ $NOSSH ]; then
|
||||
#Καθόμαστε.
|
||||
echo
|
||||
else
|
||||
## Επέτρεψε συνδέσεις SSH από τη διεύθυνση που παρέχουμε στη γραμμή εντολών
|
||||
/sbin/iptables -A INPUT -p tcp -s $1 --sport 1024: --dport 22 -j ACCEPT
|
||||
fi
|
||||
|
||||
######################
|
||||
##### ΕΞΕΡΧΟΜΕΝΑ #####
|
||||
######################
|
||||
|
||||
## Δεχόμαστε τοπικές συνδέσεις
|
||||
/sbin/iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
|
||||
|
||||
## SSH
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT
|
||||
|
||||
## HTTP
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
|
||||
|
||||
## HTTPS
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
|
||||
|
||||
## POP3
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 110 -j ACCEPT
|
||||
|
||||
## SMTP
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
|
||||
|
||||
## DNS
|
||||
/sbin/iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
|
||||
|
||||
## FTP (command)
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j
|
||||
ACCEPT
|
||||
|
||||
## FTP (data::Active)
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j
|
||||
ACCEPT
|
||||
|
||||
## FTP (data::Passive)
|
||||
/sbin/iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state
|
||||
ESTABLISHED,RELATED -j ACCEPT
|
||||
|
||||
if [ $NOSSH ]; then
|
||||
echo
|
||||
else
|
||||
## Επιτρέπουμε στον SSH server μας να απαντήσει.
|
||||
/sbin/iptables -A OUTPUT -p tcp --sport 22 --dport 1024: -m state --state
|
||||
ESTABLISHED,RELATED -j ACCEPT
|
||||
fi
|
||||
|
||||
## ICMP
|
||||
/sbin/iptables -A OUTPUT -p icmp -j ACCEPT
|
||||
|
||||
## dict.org:2628
|
||||
/sbin/iptables -A OUTPUT -p tcp -d 66.111.36.30 --dport 2628 -j ACCEPT
|
||||
|
||||
## Importing OpenPGP keys από pgp.mit.edu:11371
|
||||
/sbin/iptables -A OUTPUT -p tcp -d 18.7.14.139 --dport 11371 -j ACCEPT
|
||||
|
||||
## JETDIRECT printing
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 9100 -j ACCEPT
|
||||
|
||||
## Whois queries
|
||||
/sbin/iptables -A OUTPUT -p tcp --dport 43 -j ACCEPT
|
||||
|
||||
## NTP updates
|
||||
/sbin/iptables -A OUTPUT -p tcp -d 128.2.4.21/16 --dport 123 -j ACCEPT
|
||||
/sbin/iptables -A OUTPUT -p udp --sport 123 -d 128.2.4.21/16 --dport 123 -j
|
||||
ACCEPT
|
||||
|
||||
|
||||
#################
|
||||
#### LOGGING ####
|
||||
#################
|
||||
## Αυτά τα μηνύματα καταχωρούνται στο /var/log/messages
|
||||
## Με ένα tail -f /var/log/messages σαν root τα παρακολουθούμε
|
||||
|
||||
## Log εισερχόμενα TCP πακέτα που απορρίφθηκαν.
|
||||
/sbin/iptables -A INPUT -p tcp -j LOG --log-prefix "iptables:IN-TCP DROPPED:"
|
||||
|
||||
## Log εξερχόμενα TCP πακέτα που απορρίφθηκαν.
|
||||
/sbin/iptables -A OUTPUT -p tcp -j LOG --log-prefix "iptables:OUT-TCP DROPPED:"
|
||||
|
||||
## Log οτιδήποτε άλλο που δεν πέρασε
|
||||
#/sbin/iptables -A INPUT -j LOG --log-prefix "iptables:INCOMING DROPPED:"
|
||||
/sbin/iptables -A OUTPUT -j LOG --log-prefix "iptables:OUTGOING DROPPED:"
|
||||
|
||||
## Τέλος του iptables script
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Μπορείτε να κατεβάσετε αυτό το script και [σε ASCII μορφή](fw.rules) για πιο εύκολη χρήση. Το script πρέπει να ανήκει στον root και να είναι executable:
|
||||
|
||||
# chown root:root fw.rules
|
||||
# chmod 770 fw.rules
|
||||
|
||||
\...και το εκτελείτε. Τα αποτελέσματα τα βλέπετε με ένα
|
||||
|
||||
# iptables -L
|
||||
|
||||
|
||||
### [3. Privacy]{#s3}
|
||||
|
||||
Σε αυτή την ενότητα θα εξετάσουμε τα βήματα που μπορούμε να ακολουθήσουμε για να δυσκολέψουμε το έργο των απανταχού
|
||||
[spammers](http://www.wikipedia.org/wiki/Spamming), διαφημιστών, και λοιπών κερδοσκοπικών ατόμων και εταιρειών, που έχουν σαν σκοπό να μετατρέψουν το Internet
|
||||
σε ένα μεγάλο εμπορικό κέντρο. Μόνο και μόνο διαβάζοντας σελίδες και στέλνοντας emails οι κινήσεις μας παρακολουθούνται και καταγράφονται για σκοπούς marketing.
|
||||
Τα προσωπικά μας δεδομένα πωλούνται σε όσους μπορούν να πληρώσουν, και καταντάμε έρμαια μαζικών διαφημίσεων στα προσωπικά μας mailbox. Σε κάθε σελίδα που
|
||||
διαβάζουμε υπάρχουν 5-10 διαφημιστικά banners που αναβοσβήνουν, αστράφτουν, κουνιούνται, έχουν ήχο\... κάνουν τα πάντα για να αποσπάσουν την προσοχή μας από τον
|
||||
σκοπό που είχαμε όταν πήγαμε στην σελίδα (να διαβάσουμε τις πληροφορίες που έχει εκεί), και να μας κάνουν να θυμηθούμε το οποιοδήποτε προϊόν όταν το δούμε
|
||||
μπροστά μας. Προσωπικά βρίσκω τις διαφημίσεις αυτές εξαιρετικά ενοχλητικές και την πώληση των προσωπικών μου πληροφοριών σε εταιρείες ανήθικη. Να τι κάνω για να
|
||||
προστατέψω τον εαυτό μου λοιπόν.
|
||||
|
||||
### [3.1 Διαφημίσεις (banner ads)]{#ss3.1}
|
||||
|
||||
Τα banners έχουν αρχίσει να γίνονται ιδιαίτερα ενοχλητικά. Δεν μπορεί κανείς να διαβάσει μια σελίδα στο Internet χωρίς να βομβαρδίζεται από ενοχλητικά
|
||||
[animation, ήχους και χρώματα](/34/img/ads.png), όλα να υπόσχονται λεφτά και εκπτώσεις και ευκαιρίες. Εκτός από την ενόχληση αυτή, τα banners χρησιμοποιούνται από
|
||||
τους διαφημιστές για να παρακολουθούν τους netizens και να δημιουργούν καταναλωτικά προφίλ για σκοπούς marketing (βλ. ενότητα για cookies παρακάτω). Ευτυχώς
|
||||
είναι αρκετά εύκολο να [απαλλαγεί](/34/img/noads.png) κανείς από αυτά, χάρη στους proxy servers που υπάρχουν ελεύθερα διαθέσιμοι.
|
||||
|
||||
O [privoxy](http://www.privoxy.org) είναι ένας anonymizing proxy. Ένα πρόγραμμα, δηλαδή, που δέχεται αιτήσεις για νέες σελίδες από τον browser σας, και τις
|
||||
φέρνει από το δίκτυο. Όταν τις σερβίρει στον browser για να τις δείξει στην οθόνη, διαβάζει τον κώδικα της σελίδας και [αντικαθιστά τις
|
||||
διαφημίσεις](http://www.andrew.cmu.edu/~apapadop/linux/images/bloomberg_privoxy.png) με άσπρα κουτάκια (που δεν φαίνονται) είτε ένα σήμα που δείχνει στον χρήστη
|
||||
ότι υπήρχε μια διαφήμιση εκεί, και τώρα δεν την βλέπει. Έτσι βλέπουμε μόνο αυτό που θέλουμε, και όχι διαφημίσεις που μας αποσπούν την προσοχή.
|
||||
|
||||
### [3.2 Cookies]{#ss3.2}
|
||||
|
||||
Τα cookies είναι μικρά αρχεία κειμένου που οποιοδήποτε site μπορεί να αποθηκεύσει στον υπολογιστή μας. Έχουν δημιουργηθεί για να ξεπεράσουν κάποια [προβλήματα
|
||||
σχεδιασμού του πρωτοκόλλου HTTP](http://www.wikipedia.org/wiki/HTTP_cookie) που χρησιμοποιείται για web browsing. Επειδή το HTTP είναι stateless, δηλαδή δεν
|
||||
μπορεί να καταλάβει αν κάποιο click που κάνουμε είναι συνδεμένο με προηγούμενες ενέργειές μας στην ίδια σελίδα ή όχι, εφευρέθηκαν τα cookies. Τώρα, όταν κάνω
|
||||
login σε κάποιο δικτυακό χώρο που χρειάζεται να ελέγχει την πρόσβαση των χρηστών του (π.χ. online email service), το site μου δίνει ένα cookie που περιέχει
|
||||
κωδικοποιημένες τις πληροφορίες του λογαριασμού μου. Έτσι, όταν ζητάω να δω το inbox μου, το εκάστοτε site ξέρει ότι είμαι ο νόμιμος χρήστης αυτού του
|
||||
λογαριασμού, και μου δείχνει τα email μου. Αν δεν υπήρχε αυτός ο μηχανισμός για να παρακολουθεί πχ. το Yahoo! ποιος χρήστης ζητάει να δει τι, θα ήταν δυνατό να
|
||||
διαβάζουν όλοι τα emails όλων των άλλων χρηστών.
|
||||
|
||||
Όλα καλά και άγια ως εδώ με τα cookies. Τα προβλήματα ξεκινούν όταν διάφοροι εξυπνάκηδες αρχίζουν να εκμεταλλεύονται αυτό το μηχανισμό για να μας παρακολουθούν
|
||||
για διαφημιστικούς λόγους. Υπάρχουν εταιρείες όπως η απεχθής Doubleclick, που μοιράζουν άφθονα cookies σε κάθε ευκαιρία, και μετά παρακολουθούν το πού πάει ο
|
||||
κάτοχός τους.
|
||||
|
||||
Ένα παράδειγμα. Είχα ένα λογαριασμό για free web email στο rocketmail.com και ήμουν πολύ ικανοποιημένος. Ούτε spam, ούτε διαφημίσεις, ούτε τίποτα. Όταν το
|
||||
rocketmail.com αγοράστηκε από το Yahoo! άρχισαν τα προβλήματα. Κάθε φορά που χρησιμοποιώ το λογαριασμό μου, το Yahoo! προσπαθεί να μου δώσει ένα cookie εκ
|
||||
μέρους της Doubleckick. Αν δεν προστάτευα τον εαυτό μου απορρίπτοντας το cookie, οποιαδήποτε άλλα sites είχαν διαφημίσεις της Doubleclick (και είναι λίγα που
|
||||
**δεν** έχουν) θα μπορούσαν να μάθουν τη διεύθυνση email μου. Καθώς πήγαινα σε περισσότερα sites, με το cookie της Doubleckick στον υπολογιστή μου, οι συνήθειές
|
||||
μου θα καταγράφονταν και θα συσχετιζόντουσαν για να δημιουργήσουν ένα καταναλωτικό προφίλ. Τι ενδιαφέρει αυτόn τον καταναλωτή; Σε τι δικτυακούς τόπους συχνάζει;
|
||||
Πόσο χρόνο κάθεται σε τι είδους σελίδες; Αυτό το προφίλ είναι έτοιμο να πουληθεί σε οποιονδήποτε ενδιαφερόμενο κάνει direct marketing. Σε όλη αυτή τη διαδικασία
|
||||
εγώ ουδέποτε έχω συμφωνήσει να φτιαχτεί τέτοιο προφίλ, να παρακολουθούνται οι κινήσεις μου, και να δέχομαι spam email από εταιρείες που δεν ξέρω καν. Και όμως,
|
||||
δεχόμενος το cookie, έχω κάνει όλα τα παραπάνω.
|
||||
|
||||
Τα cookies είναι άχρηστα για την σωστή λειτουργία του δικτυακού τόπου στη συντριπτική πλειοψηφία των περιπτώσεων. Ο γενικός κανόνας είναι ότι αν δεν χρειάζεται
|
||||
να κάνετε login κάπου (με username και password), τότε δεν χρειάζεστε και τα cookies από εκείνο το site.
|
||||
|
||||
Για να αμυνθούμε έναντι των cookies, πρέπει απλά να ρυθμίσουμε τον browser μας να μας ρωτάει τι να κάνει κάθε φορά που κάποιος προσπαθεί να μας δώσει cookie.
|
||||
Και ο [Mozilla](/34/img/mozilla_cookie.png) και ο [Konqueror](/34/img/konqueror_cookie.png) έχουν πολύ ωραίο τρόπο αντιμετώπισης των cookies. Μπορούν να ρυθμιστούν να
|
||||
θυμούνται την επιλογή του χρήστη (αποδοχή ή απόρριψη cookies από ένα συγκεκριμένο site), και να σβήνουν όλα τα cookies με το που κλείνουμε τον browser. Έτσι
|
||||
κρατάμε τις χρήσιμες λειτουργίες των cookies επιλεκτικά, όπου τις χρειαζόμαστε, και σιγουρεύουμε ότι δεν μπορεί κανείς να μας παρακολουθήσει την επόμενη φορά
|
||||
που θα ανοίξουμε τον browser μας.
|
||||
|
||||
### [3.3 Web bugs]{#ss3.3}
|
||||
|
||||
Τα web bugs είναι αόρατες εικόνες (1x1 pixel transparent GIFs, συνήθως) που στέλνονται σαν μέρος ενός HTML email, και πρέπει να φορτωθούν από το Internet όταν
|
||||
το email ανοιχτεί. Τι σημασία έχει αυτό, σας ακούω να ρωτάτε.
|
||||
|
||||
Ας πούμε ότι είμαι ένας spammer. Τρέχω έναν web server και έναν mail server δικό μου. Στέλνω 10,000 email ένα πρωί, μη ξέροντας ποιες από αυτές τις διευθύνσεις
|
||||
είναι πραγματικές και ποιες έχουν καταργηθεί. Επίσης θέλω να μετρήσω το πόσο γρήγορα φτάνουν στα θύματά μου (καταναλωτές) οι διαφημίσεις που στέλνω. Πώς θα το
|
||||
κάνω αυτό;
|
||||
|
||||
Το email που στέλνω είναι σε HTML. Περιέχει στον κώδικα της σελίδας μια αόρατη εικόνα (transparent GIF), η πηγή του οποίου είναι ο web server μου. Συνεπώς μόλις
|
||||
κάποιο θύμα ανοίξει αυτό το email, ο mail client του θα προσπαθήσει να του δείξει την εικόνα, άρα θα προσπαθήσει να την κατεβάσει από το Internet, και πιο
|
||||
συγκεκριμένα από τον δικό μου web server. Αλλά οι web servers έχουν logs που δείχνουν ποια διεύθυνση (ΙΡ), ζήτησε ποιο αρχείο (το GIFάκι), ποιά ώρα. Συνεπώς
|
||||
μαθαίνω ότι κάποιος στο domain 194.15.60.x (που μπορώ εύκολα να μάθω πως ανήκει σε subnet ενός συγκεκριμένου Internet Service Provider - ας πούμε της OTEnet)
|
||||
άνοιξε το email μου στις 11:34 ακριβώς το πρωί.
|
||||
|
||||
Αμέσως ξέρω ότι κάποια από τις διευθύνσεις \@otenet.gr που έχω είναι πιθανότατα πραγματικό mailbox κάποιου θύματος, το οποίο διαβάζει τα mail του αρκετά συχνά.
|
||||
Άρα αρχίζω να χτυπάω τις διευθύνσεις \@otenet.gr πιο πολύ με spam από δω και πέρα.
|
||||
|
||||
Η μόνη άμυνα για αυτή την παραβίαση του προσωπικού μας χώρου είναι η απαγόρευση των HTML email. Ο [Mozilla Mail](/34/img/moz_mail.png) και το [KMail](/34/img/kmail.png)
|
||||
έχουν ρυθμίσεις για να σας βοηθήσουν να αντιμετωπίσετε τα web bugs, που είναι τελικά τελείως άχρηστα σε εμάς, και πολύ χρήσιμα στους spammers.
|
||||
|
||||
**Συμπέρασμα:**
|
||||
|
||||
Οι απειλές είναι πολλές, άλλα υπάρχουν και πολλά που μπορούμε να κάνουμε για να προστατευθούμε. Με λίγη προσοχή και τη δύναμη των εργαλείων του GNU/Linux,
|
||||
357
content/articles/34/04_tips.md
Κανονικό αρχείο
357
content/articles/34/04_tips.md
Κανονικό αρχείο
|
|
@ -0,0 +1,357 @@
|
|||
+++
|
||||
title = 'Tips για την γραμμή εντολής.'
|
||||
date = '2003-08-01T00:00:00Z'
|
||||
description = ''
|
||||
author = 'Φανουργάκης Μανώλης(mailto:mfano@NOSPAMfreemail.gr)'
|
||||
issue = ['Magaz 34']
|
||||
issue_weight = 4
|
||||
+++
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
*Μερικά tips που διευκολύνουν τη ζωή μας στη γραμμή εντολής*
|
||||
|
||||
----------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
**1. Aliases**
|
||||
-------------------------------------
|
||||
|
||||
- [1.1 ls](#ss1.1)
|
||||
- [1.2 less](#ss1.2)
|
||||
- [1.3 pushd, popd, dirs](#ss1.3)
|
||||
- [1.4 PATH](#ss1.4)
|
||||
- [1.5 history](#ss1.5)
|
||||
- [1.6 find](#ss1.6)
|
||||
- [1.7 Συντόμευση για συνηθισμένα μακριά command lines.](#ss1.7)
|
||||
- [1.8 Διάφορα](#ss1.8)
|
||||
|
||||
**2. Shell prompt**
|
||||
------------------------------------------
|
||||
|
||||
**3. Vi (=very intelligent) editor**
|
||||
-----------------------------------------------------------
|
||||
|
||||
**4. Screen**
|
||||
------------------------------------
|
||||
|
||||
|
||||
### [1. Aliases]{#s1}
|
||||
|
||||
Τα παρακάτω aliases μπορούν να μπουν στο \~/.bashrc. Αν όμως γίνουν πολλά, είναι καλύτερα για λόγους τάξης να μπουν σε ένα ξεχωριστό αρχείο, π.χ. στο \~/.alias
|
||||
και να μπει στο \~/.bashrc η γραμμή:
|
||||
|
||||
test -s ~/.alias && . ~/.alias
|
||||
|
||||
### [1.1 ls]{#ss1.1}
|
||||
|
||||
alias l='ls -lA '
|
||||
alias lh='l -h '
|
||||
|
||||
Ο διακόπτης -h της ls είναι αρκετά χρήσιμος γιατί μετατρέπει το μέγεθος αρχείων σε kB,MB,GB. Έτσι, με \'l \~/mbox\' θα πάρω το παρακάτω:
|
||||
|
||||
-rw------- 1 manolis users 135987 Ιούλ 28 22:33 /home/manolis/mbox
|
||||
|
||||
Ενώ με \'lh \~/mbox\' το παρακάτω:
|
||||
|
||||
-rw------- 1 manolis users 133k Ιούλ 28 22:33 /home/manolis/mbox
|
||||
|
||||
### [1.2 less]{#ss1.2}
|
||||
|
||||
alias m='$PAGER'
|
||||
|
||||
Όπου η μεταβλητή PAGER έχει τεθεί στο \~/.bashrc ως εξής:
|
||||
|
||||
export PAGER='less -rM '
|
||||
|
||||
Ή ό,τι άλλο χρησιμοποιείται ως pager τέλος πάντων. Εξαιρετικά βολικό, χρησιμοποιώ το less αμέτρητες φορές κάθε μέρα.
|
||||
|
||||
### [1.3 pushd, popd, dirs]{#ss1.3}
|
||||
|
||||
alias pd='pushd'
|
||||
alias po='popd'
|
||||
alias ds='dirs -v'
|
||||
|
||||
Χρήσιμα για τις \...περιπλανήσεις μας στη δομή αρχείων του linux.
|
||||
|
||||
Οι εντολές pushd, popd, dirs χειρίζονται μια στοίβα (stack) καταλόγων στους οποίους μετακινούμαστε.
|
||||
|
||||
- Με την εντολή \'pushd dir\' μεταφερόμαστε στον κατάλογο dir και τοποθετείται αυτός στην κορυφή της στοίβας.
|
||||
- Με την εντολή popd αφαιρείται ο κατάλογος που βρίσκεται στην κορυφή της στοίβας και μεταφερόμαστε σ\' αυτόν που θα γίνει η νέα κορυφή.
|
||||
- Με την εντολή dirs βλέπουμε τα περιεχόμενα της στοίβας.
|
||||
|
||||
Ένα παράδειγμα θα γίνει πιο εύκολα κατανοητό:
|
||||
|
||||
$ pd /tmp/
|
||||
/tmp ~
|
||||
|
||||
Ξεκινώντας ένα νέο shell βρίσκομαι στο home directory. Κάνω push το /tmp. Παρατηρώ ότι η pushd μου αναφέρει και την κατάσταση της στοίβας: Στην κορφή βρίσκεται
|
||||
το /tmp και μετά το home από όπου ξεκίνησα.
|
||||
|
||||
$ pd /usr/local/bin/
|
||||
/usr/local/bin /tmp ~
|
||||
|
||||
Έκανα push και το /usr/local/bin. Η στοίβα τώρα έχει τρεις καταλόγους.
|
||||
|
||||
$ ds
|
||||
0 /usr/local/bin
|
||||
1 /tmp
|
||||
2 ~
|
||||
|
||||
Ας υποθέσουμε τώρα ότι θέλω να εναλλάσομαι γρήγορα μεταξύ αυτών των καταλόγων. Με ένα pushd +n (όταν χρησιμοποιήσουμε την pushd χωρίς όρισμα, εννοείται +1) ο
|
||||
κατάλογος που βρίσκεται στη θέση n πάει στην κορυφή.
|
||||
|
||||
$ pd +1
|
||||
/tmp /usr/local/bin ~
|
||||
|
||||
Με ένα popd ξεφορτώνομαι τον κατάλογο που βρίσκεται στην κορυφή και μεταφέρομαι στον αμέσως επόμενο.
|
||||
|
||||
$ po
|
||||
/usr/local/bin ~
|
||||
|
||||
Με τη σωστή χρήση των pushd, popd, dirs μπορούμε να κάνουμε πολύ γρήγορα πολύπλοκες δουλειές. Και μην ξεχνάτε ότι τα πλήρη ονόματα των καταλόγων μπορεί να
|
||||
γίνουν πολύ μεγάλα (π.χ. /usr/X11R6/lib/X11/fonts/hellas/, \~/download/pictures/flags/greece/). Είναι πολύ βολικό να μπορεί κανείς με τρία χτυπήματα πλήκτρων να
|
||||
εναλάσσεται μεταξύ τους.
|
||||
|
||||
Για περισσότερες πληροφορίες \'help pushd\', \'help popd\', \'help dirs\'.
|
||||
|
||||
Επίσης, ας μην ξεχνάμε και την εντολή \'cd -\' που μας τοποθετεί στον προηγούμενο κατάλογο (σ\' αυτόν που είμασταν πριν κάνουμε cd ή pushd/popd).
|
||||
|
||||
### [1.4 PATH]{#ss1.4}
|
||||
|
||||
alias pt='echo $PATH|tr : \\n '
|
||||
addpath() { while test "$1" ; do PATH=${PATH}:"$1" ; shift ; done ; }
|
||||
|
||||
Το alias pt κάνει το εξής απλό και έξυπνο: Παίρνει τη μεταβλητή PATH και την περνάει στην εντολή tr (δώστε man tr) ώστε να μετατρέψει τις άνω και κάτω τελείες
|
||||
που χωρίζουν τους καταλόγους του path σε αλλαγές γραμμών. Έτσι έχουμε το εξής ευανάγνωστο αποτέλεσμα:
|
||||
|
||||
$ pt
|
||||
/usr/local/bin
|
||||
/usr/bin
|
||||
/usr/X11R6/bin
|
||||
/bin
|
||||
/usr/games/bin
|
||||
/opt/gnome/bin
|
||||
/opt/kde3/bin
|
||||
.
|
||||
|
||||
Η συνάρτηση addpath προσθέτει τα ορίσματά της στο τέλος της μεταβλητής PATH. Οι συναρτήσεις (functions) του shell είναι σαν μικρά σκριπτάκια, έχουν πιο πολλές
|
||||
δυνατότητες από τα απλά aliases. Εδώ όπως βλέπετε μπορούμε να χειριστούμε μία- μία όλες της παραμέτρους της addpath().
|
||||
|
||||
(Για περισσότερες πληροφορίες, man bash, section FUNCTIONS)
|
||||
|
||||
### []{#history} [1.5 history]{#ss1.5}
|
||||
|
||||
Το shell μας δίνει τη δυνατότητα να επαναλάβουμε μια προηγούμενη εντολή χωρίς να χρειάζεται να την πληκτρολογήσουμε ολόκληρη.
|
||||
|
||||
- Με τα βελάκια πάνω και κάτω μπορούμε να έχουμε γρήγορη πρόσβαση στις προηγούμενες εντολές.
|
||||
- Δίνοντας \'!cmd\' επαναλαμβάνεται η τελευταία εντολή που αρχιζε με τους χαρακτήρες \'cmd\'.
|
||||
- Δίνοντας \'history n\' (παρεμπιμπτόντως μην ξεχάσετε το alias h=\'history \' στο \~/.bashrc) μας εμφανίζονται οι τελευταίες n εντολές μαζί με τον αριθμό
|
||||
τους. Στη συνέχεια με \'!n\', όπου n ο αριθμός της εντολής μπορούμε να επαναλάβουμε όποια θέλουμε.
|
||||
- Με \'!-n\', όπου n αριθμός, εκτελείται η n-ιοστή προηγούμενη εντολή. Με \'!!\' εκτελείται η αμέσως προηγούμενη (συνώνυμο του \'!-1\').
|
||||
|
||||
(Για περισσότερες πληροφορίες, man bash, section HISTORY)
|
||||
|
||||
### [1.6 find]{#ss1.6}
|
||||
|
||||
export FIN='-printf %s\t%TY-%Tm-%Td-%TX\t%p\n'
|
||||
|
||||
Έχοντας αυτή τη γραμμή στο \~/.bashrc έχω πάντα στο shell μου μια μεταβλητή, την FIN. Το κείμενο της είναι μια εντολή μορφοποίησης για τα αποτελέσματα της find.
|
||||
Δίνοντας λοιπόν \"find dir \$FIN\" παίρνω μια λίστα των αρχείων κάτω από τον κατάλογο dir στην εξής μορφή:
|
||||
|
||||
135987 2003-07-28-22:33:13 ./mbox
|
||||
|
||||
Στην πρώτη στήλη το μέγεθος του αρχείου, στη δεύτερη η ημερομηνία τροποποίησης και στην τρίτη το όνομα του αρχείου. Οι στήλες είναι χωρισμένες με tab.
|
||||
|
||||
Κατευθύνοντας τώρα την έξοδο της προηγούμενης εντολής στην sort μπορούμε να κάνουμε πολύ ενδιαφέροντα πράγματα:
|
||||
|
||||
% find $FIN |sort -rnk 1|head -n 4
|
||||
|
||||
5146003 2003-08-02-20:45:48 ./Mail/LGU
|
||||
2457441 2003-08-01-11:00:07 ./Mail/saved
|
||||
2029849 2003-02-04-20:32:24 ./tmp/lp/ss11
|
||||
1603828 2003-07-28-22:22:08 ./downl/wg/glib-2.2.2.tar.bz2
|
||||
|
||||
Ο διακόπτης \'-k NUM\' της sort κάνει ταξινόμηση σύμφωνα με το NUM-οστό πεδίο. Εδώ βάλαμε το πρώτο, το μέγεθος δηλαδή. Το \'r\' είναι για φθίνουσα ταξινόμηση.
|
||||
Το \'n\' είναι για να λάβει η sort υπόψη της ότι πρόκειται για αριθμούς (και να μη βάλει το 11111 πριν από το 11 στη φθίνουσα ταξινόμηση, για παράδειγμα).
|
||||
Χρησιμοποίησα το φίλτρο head για να κρατήσω τις πρώτες 4 γραμμές μόνο (man head).
|
||||
|
||||
Τι κάναμε δηλαδή; Κάναμε μια αναζήτηση κάτω από τον τρέχοντα κατάλογο και βρήκαμε τα πιο μεγάλα σε μέγεθος αρχεία.
|
||||
|
||||
Άλλο:
|
||||
|
||||
% find $FIN |sort -rk 2|head -n 4
|
||||
|
||||
20480 2003-08-03-12:32:13 ./tmp/.tips.swp
|
||||
7946 2003-08-03-12:32:13 ./tmp/tips
|
||||
4096 2003-08-03-12:32:13 ./tmp
|
||||
150606 2003-08-03-12:21:35 ./.bash_history
|
||||
|
||||
Κάναμε ταξινόμηση ως προς την ημερομηνία και ώρα τροποποίησης.
|
||||
|
||||
Παρατήρηση: Η find μας επιστρέφει και ονόματα καταλόγων (όπως το ./tmp που φαίνεται πιο πάνω). Για να μην το κάνει αυτό μπορούμε να προσθέσουμε στις παραμέτρους
|
||||
της find το \'! -type d\'.
|
||||
|
||||
(man find για περισσότερες πληροφορίες).
|
||||
|
||||
### [1.7 Συντόμευση για συνηθισμένα μακριά command lines.]{#ss1.7}
|
||||
|
||||
Αυτό που κάναμε για την find μπορούμε να το κάνουμε και για άλλες εντολές όταν υπάρχει ένα αρκετά μακρύ command line που πληκτρολογούμε συχνά. Να μπαίνει δηλαδή
|
||||
ένα κομμάτι της εντολής που είναι πάντα σταθερό σε μια μεταβλητή του shell ή αν είναι όλη η εντολή σταθερή να μπαίνει όλη σε ένα alias.
|
||||
|
||||
Για παράδειγμα, κάθε φορά που διαβάζω ένα ενδιαφέρον ρητό πάω και το προσθέτω σε ένα αρχείο των fortunes. Με τα παρακάτω γλυτώνω πολλή πληκτρολόγηση:
|
||||
|
||||
alias addfort='pushd /usr/local/share/games/fortunes;vi quotes;strfile quotes;popd'
|
||||
|
||||
Για το rip ενός dvd:
|
||||
|
||||
alias dvdrip='for i in `seq 1 $n` ; do mplayer -dvd $i -dumpstream -dumpfile ${i}.stream ; done'
|
||||
|
||||
Αφού πρώτα θέσουμε τον αριθμό τίτλων του dvd, τους κάνουμε όλους rip με μια εντολή:
|
||||
|
||||
% n=3;dvdrip
|
||||
|
||||
Το παραπάνω μπορούσε να γίνει πιο απλά με μια συνάρτηση:
|
||||
|
||||
dvdrip() { for i in `seq 1 $1` ; do mplayer -dvd $i -dumpstream -dumpfile ${i}.stream ; done ;}
|
||||
|
||||
οπότε θα χρειαζόταν απλά:
|
||||
|
||||
% dvdrip 3
|
||||
|
||||
### [1.8 Διάφορα]{#ss1.8}
|
||||
|
||||
alias h='history '
|
||||
alias he='head '
|
||||
alias t='tail '
|
||||
alias j='jobs -l '
|
||||
|
||||
Γλυτώνουμε πληκτρολόγηση\...
|
||||
|
||||
alias ejclcd='eject /dev/cdrom;sleep 5s;eject -t /dev/cdrom'
|
||||
|
||||
Γιατί να πρέπει να κουραζόμαστε να πατάμε το κουμπί του cd όταν μπορεί να το κάνει το λινουξάκι για μας ;-) ejclcd, βγαίνει το πορτάκι, βάζουμε το δισκάκι,
|
||||
κλείνει μόνο του.
|
||||
|
||||
ssdu() { ls -AQ|xargs du -sb|sort -rn|cut -f 2|awk '{print "\"" $0 "\""}'|xargs du -sh ; }
|
||||
ssdus() { while test "$1";do du -sb "$1";shift;done|sort -rn|cut -f 2|awk '{print "\"" $0 "\""}'|xargs du -sh ; }
|
||||
|
||||
Να κάτι πιο εξεζητημένο: Η ssdu δείχνει, σε φθίνουσα σειρά, πόσο χώρο χρησιμοποιεί, σε kB/MB/GB, κάθε στοιχείο (αρχείο ή κατάλογος) του τρέχοντος καταλόγου. Και
|
||||
αν θέλετε για συγκεκριμένα αρχεία/καταλόγους μονο, η ssdus παίρνει και ορίσματα.
|
||||
|
||||
Βασική ιδέα είναι να τρέξει πρώτα η du για να μας δώσει λίστα αρχείων και καταλόγων ταξινομημένων κατά μέγεθος. Στη συνέχεια για κάθε στοιχείο της λίστας,
|
||||
παίρνουμε το όνομα και δείχνουμε μαζί και το μέγεθός του σε kB/MB/GB.
|
||||
|
||||
|
||||
### [2. Shell prompt]{#s2}
|
||||
|
||||
Το command prompt του shell μπορεί να μας παρέχει σημαντικές πληροφορίες. Π.χ. βάζοντας στο \~/.bashrc τη γραμμή:
|
||||
|
||||
export PS1='\u \w (\#)% '
|
||||
|
||||
θα πάρουμε ένα prompt του τύπου:
|
||||
|
||||
manolis /usr/local/bin (15)%
|
||||
|
||||
που μας δείχνει το όνομα του χρήστη, τον τρέχοντα κατάλογο και τον αριθμό των εντολών που έχουμε πληκτρολογήσει. (Ο αριθμός αυτός είναι χρήσιμος για την εντολή
|
||||
[history](04_tips-1.html#history)).
|
||||
|
||||
Το shell μας δίνει τη δυνατότητα να εμφανίσουμε στο prompt ένα σωρό χρήσιμα πράγματα, όπως το hostname (/h), τον αριθμό των εργασιών που τρέχουν στο υπόβαθρο
|
||||
(/j), την ημερομηνία και ώρα (/d, /t). Φυσικά πρέπει να επιλέξει κανείς μόνο όσα πραγματικά είναι χρήσιμα γιατί ένα πολύ μακρύ prompt δυσχεραίνει τη χρήση του
|
||||
τερματικού.
|
||||
|
||||
Μπορούμε να τρέξουμε ακόμα και ένα πρόγραμμα και να δείξουμε την έξοδό του στο prompt. Δώστε \"PS1=\'\`uptime\` % \'\" χωρίς τα εισαγωγικά. Δοκιμάστε επίσης
|
||||
\"PS1=\'\\n\`fortune\`\\n \$ \'\" Κάπως περίεργο, αλλά έχει πλάκα. 8-)
|
||||
|
||||
Για περισσότερες πληροφορίες, man bash, section PROMPTING.
|
||||
|
||||
|
||||
### [3. Vi (=very intelligent) editor]{#s3}
|
||||
|
||||
Κατ\' αρχάς διαβάστε τα tips που δίνονται στα τεύχη 22 και 27 του magaz.
|
||||
|
||||
Έχω βάλει στο \~/.vimrc μου τα εξής:
|
||||
|
||||
map <F1> :w<CR>
|
||||
map <F2> j.
|
||||
map <F5> :bp<CR>
|
||||
map <F6> :bn<CR>
|
||||
map <F7> :files<CR>
|
||||
map <F8> :bdelete<CR>
|
||||
|
||||
Κάνουμε map:
|
||||
|
||||
- Στο f1 το σώσιμο του αρχείου. Έτσι θα είναι πιο εύκολο να το πατάμε όλη την ώρα! Ποτέ δεν ξέρεις πότε θα χτυπήσει ο δίσκος ή θα κοπεί το ρεύμα (όποιος έχει
|
||||
καεί\...).
|
||||
- Στο f2 την εντολή \'j.\' κάνει τα εξής: Κατεβαίνει μια γραμμή (j) και επαναλαμβάνει την προηγούμενη ενέργεια αλλαγής/διόρθωσης κειμένου (.). Αυτό είναι
|
||||
χρήσιμο για να επαναλάβουμε σε πολλές γραμμές την ίδια αλλαγή με ελάχιστο κόπο.
|
||||
- Στα f5 και f6: Μεταφορά στο προηγούμενο και στο επόμενο αρχείο που είναι φορτωμένο στον vi αντίστοιχα. (Θυμίζω ότι με \':e file\' μπορούμε να ανοίξουμε ένα
|
||||
αρχείο μέσα από τον vi. Και μάλιστα, διαθέτει και autocomplete όπως το shell!)
|
||||
- Στο f7: Λίστα με όλα τα αρχεία που είναι φορτωμένα
|
||||
- Στο f8: κλείνουμε το τρέχον αρχείο.
|
||||
|
||||
Επίσης,
|
||||
|
||||
- με την εντολή \':set tw=n\' μπορούμε να θέσουμε το μήκος του κειμένου. Το κείμενο που θα πληκτρολογούμε στο εξής θα αναδιπλώνεται αυτόματα χωρίς να
|
||||
ξεπερνάει το μήκος που ορίσαμε.
|
||||
- Με την εντολή \'gqip\' ο vi αναλαμβάνει να μορφοποιήσει την τρέχουσα παράγραφο σύμφωνα με το μήκος κειμένου που έχουμε ορίσει.
|
||||
|
||||
Για περισσότερα για κάθε εντολή, \'help command\' μέσα στο περιβάλλον του vi.
|
||||
|
||||
|
||||
### [4. Screen]{#s4}
|
||||
|
||||
Η screen είναι ένα πολύ χρήσιμο πρόγραμμα που μας δίνει τη δυνατότητα να έχουμε σε ένα τερματικό πολλές οθόνες.
|
||||
|
||||
Τρέχουμε τη screen και φαίνεται να μας ανοίγει ένα νέο shell. Πατώντας \'Ctrl-A w\' (Control και A μαζί και στη συνέχεια τα αφήνουμε και πατάμε w) φαίνονται οι
|
||||
οθόνες που έχουμε. Στην προκειμένη είναι μόνο μία: η νούμερο 0 με τίτλο \'bash\'. Μπορούμε να διορθώσουμε τον τίτλο πατώντας \'Ctrl-A A\'.
|
||||
|
||||
Πατώντας \'Ctrl-A c\' φτιάχνουμε μια καινούρια οθόνη. Άλλος τρόπος έιναι δίνοντας screen (όταν βρισκόμαστε ήδη μέσα στη screen, φτιάχνει μια καινούρια οθόνη,
|
||||
δεν τρέχει νέο στιγμιότυπο της screen). Μπορούμε με \'screen -t title\' να της δώσουμε και τίτλο.
|
||||
|
||||
Ο πιο απλός τρόπος να τερματίσουμε μια οθόνη είναι να κάνουμε logout από το shell της.
|
||||
|
||||
Με \'Ctrl-A n\' μεταφερόμαστε στην οθόνη με αριθμό n. Με \'Ctrl-A Ctrl-A\' εναλλασόμαστε μεταξύ της τρέχουσας και της προηγούμενης οθόνης.
|
||||
|
||||
Φτιάχνοντας ένα αρχείο \~/.screenrc και προσθέτοντας την παρακάτω γραμμή
|
||||
|
||||
caption always "[%n %t]%? (%W)%? (%D %d %M,%c) (%l)"
|
||||
|
||||
λέμε στη screen να μας δείχνει στο κάτω μέρος της οθόνης μας τις εξής πληροφορίες:
|
||||
|
||||
[0 main] (1 kernel-build) (Sun 03 Aug,13:44) (1.17 1.11 1.04)
|
||||
|
||||
- Τον αριθμό και τον τίτλο της τρέχουσας οθόνης σε αγκύλες.
|
||||
- Τους αριθμούς και τους τίτλους των άλλων οθονών (αν υπάρχουν) σε παρενθέσεις.
|
||||
- Την ημερομηνία και ώρα.
|
||||
- Το system load
|
||||
|
||||
Με τη screen μπορούμε να το παίζουμε \... σε πολλά ταμπλώ έχοντας μόνο ένα τερματικό ανοιχτό.
|
||||
|
||||
Επίσης, άλλη πολύ ενδιαφέρουσα δυνατότητα της screen είναι ότι μπορεί να χωρίσει την οθόνη σε πολλά οριζόντια τμήματα. Σε κάθε ένα από αυτά θα αντιστοιχεί μια
|
||||
οθόνη, με δυνατότητα ρύθμισης φυσικά του ύψους του καθενός.
|
||||
|
||||
- Ctrl-A S για χωρισμό της οθόνης
|
||||
- Ctrl-A X για καταστροφή τρέχοντος τμήματος
|
||||
- Ctrl-A Tab για μετάβαση στο επόμενο τμήμα
|
||||
- Ctrl-A :resize n για αλλαγή του ύψους του τρέχοντος τμήματος σε n γραμμές, (παίρνει και +n,-n για αύξηση ή μείωση κατα n αντιστοίχως).
|
||||
|
||||
Τέλος, με τη screen έχουμε τη δυνατότητα να κάνουμε detach και reattach ένα session.
|
||||
|
||||
Με (Ctrl-A d) γίνεται το detach, οπότε κλείνει η screen. Το session μας όμως δεν χάθηκε. Δίνοντας screen -ls θα πάρουμε μια έξοδο της μορφής:
|
||||
|
||||
There are screens on:
|
||||
781.pts-0.linux (Attached)
|
||||
893.pts-3.linux (Attached)
|
||||
2002.pts-7.linux (Detached)
|
||||
3 Sockets in /tmp/uscreens/S-manolis.
|
||||
|
||||
Με \'screen -r 2002\' (το pid δεν χρειάζεται όταν υπάρχει μόνο ένα detached session) ξανακάνουμε attach το session στο τρέχον τερματικό συνεχίζοντας τη δουλειά
|
||||
μας ακριβως απο εκεί που την αφήσαμε)
|
||||
|
||||
Αν το session δεν είναι detached και δεν έχουμε, για κάποιο λόγο, πρόσβαση σ\' αυτό μπορούμε να χρησιμοποιήσουμε την εντολή \'screen -d -r pid\' η οποία κάνει
|
||||
πρώτα detach κι ύστερα attach στο τρέχον τερματικό.
|
||||
|
||||
Μια περίπτωση στην οποία αυτή η ιδιότητα είναι πολύ χρήσιμη είναι σε remote shells. Ας υποθέσουμε ότι συνδέόμαι με telnet σε ένα απομακρυσμένο unix box και
|
||||
αρχίζω να κάνω μια δουλειά. Μπορώ ανά πάσα στιγμή να κάνώ detach και να τερματίσώ τη σύνδεση. Όταν αργότερα ξανασυνδεθώ, κάνω attach το προηγούμενο session και
|
||||
συνεχίζω τη δουλειά μου από εκεί που την άφησα!
|
||||
|
||||
1631
content/articles/34/05_rce3.md
Κανονικό αρχείο
1631
content/articles/34/05_rce3.md
Κανονικό αρχείο
Το diff αρχείου καταστέλλεται επειδή είναι πολύ μεγάλο
Φόρτωση διαφορών
Φόρτωση…
Προσθήκη πίνακα
Προσθήκη υπερσυνδέσμου
Παράθεση σε νέο ζήτημα