Newsgroup: it.comp.os.linux.sys
Titolo: mi hanno hackerato il linux! (lungo e doloroso) :-(

Ieri pomeriggio mi hanno hackerato (o almeno iniziato a farlo) il
linux! :-((((
Me ne sono accorto fortuitamente, cercando di passare su una consolle
effettiva (con ctrl+alt+f1): e qui ho scoperto che non potevo fare
login. Dapprima pensavo a qualcosa in qualche file di configurazione,
ma facendo alcune indagini ho scoperto qualcosa che non funzionava.
Innanzitutto, sono andato a vedere i log, per capire se qualcosa non
andava, e qui la prima anomalia: la "rotazione" dei log (già
effettuata regolarmente poche ore prima) era avvenuta di nuovo, e i
log secure, message e xtrnsfer erano azzerati.
L'ultima cosa che si poteva notare, in secure, era una connessione
alle 17.16 del giorno stesso (domenica 4) che ha attivato telnetd. Poi
più nulla, non c'era più log per oltre un'ora di eventi. L'ip di
origine era 163.17.180.247, che al traceroute mi ha portato a
risolverlo in 
mail4.stes.tcc.edu.tw
Immagino qualcosa come un'università di taiwan, ma potrebbe essere un
"ponte" da un server infettato a sua volta.
La cosa era fortemente anomala, perché avevo il telnetd bloccato in
hosts.allow a tutti gli utenti diversi da 127.0.0.1, e poi perché
ipchains chiudeva la porta 23 a tutti gli ip diversi da 127.0.0.1.
Ciononostante sono riusciti ad agganciarsi al telnet (ammesso che
l'ingresso sia avvenuto da lì, ma il log riportava, prima di
sprofondare nel silenzio, in.telnetd connection from 163.17.180.247).
Come è stato possibile?
Proseguendo nelle indagini, ho quindi trovato il file /etc/hosts.allow
modificato, con la riga: ALL:
0.0.0.0/0.0.0.0
 aggiunta in fondo =:-O
Il file hosts.equiv aggiungeva la riga "ftp" (mentre non ho mai messo
niente, come host equivalente).
Erano stati modificati anche i file passwd e shadow, dove ho trovato
un utente aggiunto:
motor:x:504:504:/tmp:/bin/bash
e il corrispondente in shadow con la password crittografata.
Era stato alterato anche il named, in /var/named ho trovato una nuova
zona: ADMROCKS, non so quale possa essere il motivo di questo, di
certo non l'ho messa io.
In /tmp era presente un file r00t.c contenente un paio di righe che
facevano riferimento a un "su root ( 0 )" (o qualcosa del genere, non
lo ricordo di preciso, ora sto scrivendo dall'ufficio), altra cosa
sospetta, e non poco.
Tutto questo è avvenuto nonostante:
a) wu.ftpd aggiornato alla 2.6;
b) hosts.allow che bloccava *esplicitamente* il telnet dalle macchine
remote;
c) ovviamente hosts.deny con ALL:ALL;
d) ipchains che bloccava la porta 23 a tutti gli ip esterni;
e) altri servizi che giravano erano httpd ma gestito da inetd, postfix
invece di sendmail, e comunque la porta 25 era chiusa da ipchains a
tutti gli ip esterni; poi pop3d sotto inetd, ircd (ma sembra
innocente, visto che nessun log fa riferimento alla porta 6667. E
comunque girava sotto utente irc, non root.
f) leafnode era bloccato anche lui da inetd e poi dal firewall (ma
purtroppo ho visto che non basta).
g) il firewall bloccava dall'esterno esplicitamente tutte le porte di
qualunque servizio, login, rlogin, finger, printer, X, e quante altre.
In pratica *non* erano chiuse solo la 110, la 21, la 80 e la 6667.
Poi è successa un'altra cosa inquietante: riavvio il sistema in
modalità single user, ricreo il disco di boot dall'immagine sul cd
della distribuzione, reinstallo il sistema dopo aver fatto un sommario
backup dei dati, provo la consolle e... non mi accetta il login!
Ho provato a *spegnere* e riaccendere fisicamente, e solo allora è
tornata ad accettarmi il login... a quel punto ho di nuovo
reinstallato tutto, per sicurezza, e ora sto piano piano ripristinando
tutto.
Però che diamine... da dove sono entrati? Di sicuro sono entrati,
perché quell'utente e quella zona non li ho mai messi io, il giorno
prima non c'erano di sicuro e l'unica cosa che ho installato coi
permessi di root in tempi relativamente recenti era stato compupic un
paio d'ore prima, ma scaricato dal sito ufficiale (non credo sia
rootato un programma ufficiale, per di più commerciale... almeno
voglio sperarlo).
E comunque l'aggressione è stata alle 17.16, mentre compupic l'ho
installato alle 15 e rotte.
Ditemi che sono un demente, e ditemi che avevo lasciato qualche (noto)
buco di sicurezza, perché sennò siamo tutti potenzialmente a rischio,
visto che i servizi li tenevo tutti aggiornati alle ultime versioni
(wu.ftpd, apache, leafnode, postfix), il firewall era attivo, e inetd
era protetto... di più che potevo fare???
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 
GP Legends: 
http://www.multiplayer.it/driving/index.html

 ma facendo alcune indagini ho scoperto qualcosa che non funzionava.
[..]
Complimenti: fai prima a reinstallare tutto, a questo punto, perche' non
sai cos'altro puo' averti lasciato l'amico cinesino.. e poi ti consiglio
non appena finito di installare, di fare un pensierino a Lids ed a
tripwire.
-- 
|Pierluigi De Rosa (
tho...@durin.khazad-dum.net
)|
|     E' nato il Cosenza Linux User Group	|
|   mail -s help 
cslug-...@lists.linux.it
	|
|      IRC: #cslug - 
irc.openprojects.net
	|

tripwire.
Che sarebbero?


linux! :-((((
http://www.isc.org/products/BIND/
http://www.cert.org/advisories/CA-2001-02.html
che abbiano exploitato il tuo nameserver? e' solo un'ipotesi, ma e' il
baco piu' recente e piu' pericoloso...
					Alessandro

baco piu' recente e piu' pericoloso...
E' possibilissimo accidenti, molte cose mi portano a pensare al
nameserver, in particolare quel ADMROCKS che ho trovato in /var/named.
Adesso sto leggendo la documentazione di quei siti che mi hai
indicato, grazie.


 linux! :-((((
hai voglia di postarmi in email [1] le impostazioni di ipchains?
e anche inetd.conf (prima del misfatto se fosse possibile)
ciao
ah, per la prossima volta man chattr e man tripwire ;)
[1] qui magari rompono.
-- 
nebbia

e anche inetd.conf (prima del misfatto se fosse possibile)
sě per quello non č un problema, ho un backup di pochi giorni prima
della cartella etc in toto.
Devo solo riuscire a riattivare la posta a casa...


 tripwire.
lids sinceramente non so fino a che punto possa incrementare efficacemente
la sicurezza di una installazione.
Da quel che ho capito (correggetemi se sbaglio) e' un ulteriore strato
software che limita root, per cui ci vuole un "SuperRoot" per fare alcune
cose.
Ma cosi' si sposta solo il problema.
Con lids uno cerchera' di diventare superroot al posto che semplicemente
root.
Ok, magari un po' piu' complicato, ma concettualmente e' la stessa cosa.
O sbaglio?
-- 
Pa.Ped, Como
http://www.fastflow.it/~paolop
ICQ: 4755831
VOTE AGAINST SPAM! 
http://www.politik-digital.de/spam/it/
Contro i brevetti software: 
http://petition.eurolinux.org/index_html

 Che sarebbero?
tripwire e' un simpatico programmillo che sta su un semplice floppy
mediante cui indichi dei files da monitorare e di cui memorizza lo
stato al momento della sua installazione per poi segnalare tutte le
eventuali modifiche ai suddetti files. Ora, poiche' sta su un floppy e'
difficile che qualcuno possa apportare modifiche a tuo danno.. semplice
ed efficace, no? Invece Linux Intrusion Detection System consiste in
alcune patches da applicare al kernel per implementare un rigido accesso
mediante passwd (rigorosamente differente da quella di root, ovviamente)
in modo che per accedere sia in lettura che in scrittura occorrera' dare
prima la passwd e neanche root e' in grado di sbloccare la cosa.
You may go and freshmeat, now...


 cose.
Beh se si usa una passwd differente da quella di root e si specifica che
alcuni filesystems (segnatamente /usr e /var) sono read-only e per
accedere in lettura occorre la passwd la vedo un po' difficile anche per
uno che ha sgraffignato la passwd di root fare dei danni.


Che sarebbero?
Tripwire crea un database di tutti i file che specifichi in tw.config,
la sui sintassi è semplice (man tw.config), il database è criptato e ci
mette un bel po a farlo, una volta ok lo sposti al sicuro, e ogni tot di
tempo lo lanci tripwire in modalità integrity check, che confronta il
vecchio db criptato con quello attuale che generera' al momento.
Finito il processo tripwire fornisce una lista dei file cambiati nel
sistema, di quelli cancellati, e quelli aggiunti. CI sono un casino di
opzioni per controllare molto a fondo. 
Quando ti da il resoconto capisci se c'è stata qualche modifica non
voluta, e nel tuo caso potresti rispristinare solo i file cambiati senza
reinstallare tutto. Anche se detto fra noi io reinstallerei comunque :))
Lo sto provando proprio ora. Il database criptato con il tw.config di
default sul mio sistema risulta di 12 mega.
E' un po paranoico e richiede tempo perche se lo fai una volta ogni 2
mesi ti devi controllare le centinaia di file che sono cambiati (almeno
io che ho un sistema su cui smanetto spessissimo), e se lo fai spesso
comunque non è una cosa da 2 minuti.
Il risultato è una cosa di questo tipo :
router:~# tripwire -interactive -d /home/matteo/tw.db_router
### Warning:    creating ./databases directory!
###
### Phase 1:   Reading configuration file
### Phase 2:   Generating file list
### Phase 3:   Creating file information database
### Phase 4:   Searching for inconsistencies
###
###                     Total files scanned:            80706
###                           Files added:              0
###                           Files deleted:            0
###                           Files changed:            76590
###
###                     After applying rules:
###                           Changes discarded:        76589
###                           Changes remaining:        1
###
changed: drwx------ root         1024 Feb  5 16:55:31 2001 /etc/tripwire
### Phase 5:   Generating observed/expected pairs for changed files
###
### Attr        Observed (what it is)         Expected (what it should
be)
### =========== =============================
=============================
/etc/tripwire
      st_mtime: Mon Feb  5 16:55:31 2001      Mon Feb  5 16:31:15 2001
            st_ctime: Mon Feb  5 16:55:31 2001      Mon Feb  5 16:31:15
	    2001
	    ---> File: '/etc/tripwire'
	    ---> Update entry?  [YN(y)nh?]
_________________________________________________
Ecco, devo studiarci un po su pero' questo è tripwire :)
Lids penso sia un qualcosa di simile.
Spero di non aver fatto arrabbiare nessuno se ho mandato qualche riga di
troppo ma ormai che c'ero (lo sto provando ora...:))
Ciao
-- 
(N) (a) (i) (l) (m) (a) (n)
  ] - remove (dot) from my email address to reply - [
      ] - 
http://setiathome.ssl.berkeley.edu
 - [

On Mon, 05 Feb 2001 13:20:19 GMT, Crononauta wrote:
:>E' possibilissimo accidenti, molte cose mi portano a pensare al
:>nameserver, in particolare quel ADMROCKS che ho trovato in /var/named.
uhm.. per cui la tua macchina faceva anche da nameserver?
era un nameserver primario? aperto a tutti quindi?
... per capire da dove possono essere entrati.
      Paolo

> alcuni filesystems (segnatamente /usr e /var) sono read-only e per
metti /var a sola lettura? e metti password a gogo ogni 2 secondi, quindi?
-- 
Configura internet, junkbuster, fetchmail, procmail, leafnode, firewall,
dns, wwwoffle, postfix, mutt, slrn, kernel, ed altro, visitando il sito:
http://mrshark.sourceforge.net
 od 
http://mrshark.cjb.net
 e scaricando il
"Quick&Easy Configuration Howto". Cosenza LUG: IRC: 
irc.openprojects.net
canale #cslug - Mailing-list: 
http://www.linux.it/mailman/listinfo/cslug

 metti /var a sola lettura? e metti password a gogo ogni 2 secondi, quindi?
Quindi voglio vedere chi mi modifica qualcosa..
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

... per capire da dove possono essere entrati.
Contando quello che era aperto, o dal nameserver o dal pop3d! Ftpd era
aggiornato (e si è discusso molto su quello, per la sicurezza), apache
1.3 non mi risulta aver manifestato grossi problemi.
Vabbé, diciamo che la chiamo "esperienza".
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 
IDAnet: 
http://adcserver1.biodip.unimi.it/IDA/index.html
GP Legends: 
http://www.multiplayer.it/driving/index.html

Tripwire crea un database di tutti i file che specifichi in tw.config,
[etc.]
Non so perché, ma continuo a restare un amante dei backup violenti su
cd!
Alla fine dei conti, secondo me, sono la cosa più pratica.
Scardinano tutto? chissenefrega, ricopio le directory.
Purtroppo avevo fatto da pochi giorni aggiornamenti che comunque mi
hanno costretto a rimettere mano al sistema...
:-(
Vabbé, chiamiamola "esperienza".
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 


sempre installato dai package, a dire il vero.
Il problema della RedHat 6.0 (che è stata la mia "base" evoluta a più
riprese) è che quelle boiate dei pacchetti rpm, utili per chi arriva
da windows ed è abituato a installare la roba con doppio clic, sono un
delirio per via delle dipendenze.
Certe volte mi sembra di giocare a Simon (qualcuno ricorda?), provi a
installare un pacchettino, e ti dice che ne vuole un altro, allora vai
da quello che ne vuole un altro ancora, e così via, finché non
ricostruisci l'ordine esatto!! =:-O
Alla fine ci manca solo che dopo l'installazione ti dia lo SCORE!!!
Game Over quando sbagli, invece ;-)
Per questo alla fine preferisco di gran lunga mettermi a posto il
compilatore, poi buttare nel pattume TUTTO quanto riguarda gli rpm per
quanto riguarda librerie e linguaggi, e installarmi i tar.gz come Dio
comanda.
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 


 cd!
Non e' esattamente la stessa cosa: con tripwire tu reinstalli solo cio'
che e' stato eventualmente compromesso, non centinaia di Mbytes di
roba.. c'e' un evidente risparmio di tempo fra le due cose.


 delirio per via delle dipendenze.
Ok che il modo in cui RPM gestisce le dipendenze spesso ha del barbaro
ma il compilatore C e' una di quelle cose con cui non ho mai vuto
problemi, se non altro perche' l'ho sempre fatto installare quando
ho installato il sistema. Poi quando RPM ogni tanto fa le bizze uso
il metodo del bastone e della carota [1] (il bastone in testa e la
carota...) cioe' --force e --nodeps e tutto va per il meglio.. al
massimo, appena finito do' per maggiore sicurezza un rpm --rebuilddb.
[1] (C) L. Serni, ovviamente... :-)


ho installato il sistema. 
Il problema č che (almeno la RH6.0) installa durante il setup il
compilatore, ma certe cose per essere compilate hanno bisogno di
librerie magari di devel o simili... e io che sono un essenzialista
non sopporto di dover installare roba inutile.
Cosě mi dico sempre: "metto il minimo POI aggiungo".
Solo che... le aggiunte dopo sono un problema!


incasinarmi...
Hai focalizzato i miei tormenti!
Con tutto che devo capire perché installo il gcc dal tar.gz, lo provo,
funziona, ma non per tutto... AAARRGHHHH. :-(((


da qui.
La seconda che hai detto... e da vero pistola ho scordato aperta la
porta 53 dall'esterno (il nameserver serve unicamente alle macchine
della LAN). =:-O
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 


Con simpatia :)
Argh, la cosa peggiore quando ti hackerano il linux non č il sistema a
puttane, ma tutti quelli che poi si prendono le loro vendette
morali!!! =:-OOO
Valą... un po' di buonumore č sempre gradito :-)
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 


un buco per un tarlo...!!!) e in milioni le percorrono sulle tue spalle....
Non esattamente sulle spalle... un po' più in basso!!! =:-OOOO
:-)
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 


da fuori? Altrimenti io chiuderei pure quest'ultimo...
Io! Dall'ufficio :-)



Web Site: 
http://asterix75.capri.it
Secret MS Windows code:
while (1) { if (num_process > 1) bluescreen(rand()); }

alcun exploit conosciuto.
Ok, non ricordavo la release esatta, so che avevo letto tutta la
problematica della sicurezza di wu-ftpd pochi giorni prima, e avevo
aggiornato il servizio con la versione più sicura.
Quello non è stato...


 un tripwire trojan sarebbe davvero un bel casino :-(
ovviamente il db e tripware rimangono su un CDRW, su uno zip o in
qualunque altro posto che sia sicuro
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Se alla sera, dopo una strepitosa vittoria, guardandoti allo
specchio dovessi notare un secondo paio di palle, che il tuo 
cuore non si riempia d'orgoglio, perche' vuol dire che ti 
stanno inculando -- Saggio Cinese

>Valą... un po' di buonumore č sempre gradito :-)
:))

On Wed, 07 Feb 2001 09:22:51 GMT, Crononauta wrote:
:>Io! Dall'ufficio :-)
e dall'ufficio come ti colleghi? da libero? e allora abilita il
collegamento solo agli IP del dominio 
libero.it
E' meglio che lasciarlo aperto al mondo intero.
      Paolo


Architecture: i386
Version: 0.0.3-2
Depends: libc6 (>= 2.1.2)
Filename: dists/woody/main/binary-i386/admin/lcap_0.0.3-2.deb
Size: 6386
MD5sum: a8f4e6ea5ed5fc860f6985af62849016
Description: Removes 'capabilities' in the kernel, making the system more secure 
Capabilities are a form of kernel-based access control. This program
provides a user-friendlier way than setting proc/sys/kernel/cap-bound by hand
to remove capabilities from your Linux kernel.
.
For example, you can remove the capability to load kernel modules by executing
'lcap CAP_SYS_MODULE' as root. Then no one, not even root, can load modules
into your kernel. This can be useful for tightening the security of your
Linux machines.

Quello non è stato...
E' piu' sicuro usare ProFTPd?
Che ha di diverso sa wu-ftpd? Sicuramente gestisce maggiori carichi, ma
per il resto? Che controindicazioni ha? Piu pesante e basta? Bachi?


per il resto? Che controindicazioni ha? Piu pesante e basta? Bachi?
Non lo conosco assolutamente, mi spiace.


per il resto? Che controindicazioni ha? Piu pesante e basta? Bachi?
Un sacco di vantaggi. File di configurazione piu' intelligenti (alla apache, per
capirci), puo' girare da inet o stand alone, e non ho visto exploit in giro
almeno per la versione piu' recente.
Poi il discorso e' sempre il solito. Scelte come postfix, proftpd ecc, servono
per tenere lontani gli script kiddies che hanno il loro quattro exploit
compilati presi freschi freschi da rootshell.
I programmi pero' non si sostituiscono all'amministratore di sistema, e la
regola e': sii taccagno!
Meno servizi = meno possibilita'.
Se proprio non puoi essere taccagno, monitora e backuppa. Noway.
saluti
-- 
        A bleeding heart can be hell on the carpeting.
Maurizio - Tannoiser
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

Se proprio non puoi essere taccagno, monitora e backuppa. Noway.
Vero, anche se in fondo dubito che a qualcuno interessi attaccare me con
la mia piccola LAN casalinga ;))


 Package: lcap
1) grazie del link
2) non c'e' nient'altro da fare che provarlo.
TNX
-- 
Pa.Ped, Como
http://www.fastflow.it/~paolop
ICQ: 4755831
VOTE AGAINST SPAM! 
http://www.politik-digital.de/spam/it/
Contro i brevetti software: 
http://petition.eurolinux.org/index_html

la mia piccola LAN casalinga ;))
Non ragionare così, anche io potevo dire "a chi può interessare
attaccare me", eppure mi hanno attaccato: considera che certe volte le
aggressioni si propagano in automatico, da un pc "infetto" ad un
altro...
Nel mio sistema ho trovato la shell modificata, un utente aggiunto, un
servizio di shell remota attivato in inetd.conf, gli hosts.allow
alterati, una zona del nameserver aggiunta e questo è solo quello che
ho trovato, chissà cosa c'era ancora.
Penso non sia impossibile, anzi sarebbe stato probabile, che il mio
sistema (se non me ne fossi accorto e l'avessi lasciato attivo)
sarebbe stato un eccellente "ponte" per propagare l'infezione e
l'assalto ad altri sistemi.
Quando ti trovano con degli scan su intere famiglie di ip, non è che
stanno a guardare per il sottile a chi sei o cosa fai: trovano il buco
ed entrano...
A quel punto prega 1) di accorgertene subito; 2) di avere fatto un
backup di recente...


ed entrano...
Io ho solo la  25 e la 119 aperte, protette  da un firewall chiaramente.
Secondo te vado tranquillo?


 accorga :-)
PARANOIA MASSIMA
se qualcuno modifica il floppy driver del kernel della macchina ?
:-)
-- 
Paolo Gherpelli (aka Paolo 83 RE)
gherpelli at libero dot it
gherp at freemail dot it
Powered by Debian 2.2 / Linux 2.2.18 on a P2-266

 se qualcuno modifica il floppy driver del kernel della macchina ?
... con le mani mozzate??? :-))
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Secondo te vado tranquillo?
Guarda che "tranquillo" ha fatto una brutta fine.....:-)
Ciao.
-- 
***  Per E-mail rimuovi ModE dall'indirizzo  ***
  *** Linux user # 198661 --- ICQ 33500725 ***
*** homepage 
http://web.tiscalinet.it/kailed
 ***
            *** Powered by Linux ***

Guarda che "tranquillo" ha fatto una brutta fine.....:-)
Eddai basta tentare di mettermi paura! (-:


ho trovato, chissà cosa c'era ancora.
Forse mi e` sfuggito: ma eri in dialup? 
-- 
       GHERdO, happy linux user
	"Lo Spirito CONTiNUA!"

Forse mi e` sfuggito: ma eri in dialup? 
Sono in adsl, ma non sarebbe cambiato nulla: mi hanno hackerato mentre
stavo fisicamente lavorando sulla macchina!!! Anche con un dialup
avrebbero fatto uguale...
Praticamente mi hanno bucato sotto il mio naso, per questo me ne sono
accorto subito: ho tentato di passare a una consolle "vera" (e non
l'xterm) e non ho potuto fare login.
Dai residui dei log, l'aggressione è avvenuta alle 17.16, io entro le
18 avevo già scoperto l'attacco e disconnesso il pc.


avrebbero fatto uguale...
Te lo domandavo per  curiosita`. Per sapere se ti aveva  scelto a caso o
meno... bella sfiga comunque.
-- 
       GHERdO, happy linux user
"Lei ha bisogno di qualcuno che la guardi"

 =:-O
bind ha una triste storia, sotto questo punto di vista.
ftp e dns sono i due serivizi piu' pericolosi, da tenere aggiornati in
maniera costante.
Buttha
-- 
* Per rispondere in email rimuovere la prima i dall'indirizzo
* Le mie opinioni non sono fatte per essere esposte in pubblico

meno... bella sfiga comunque.
Sicuramente mi ha scelto a caso, facendo delle ricerche su famiglie di
ip, e un port scan di massa: le ultime tracce del log, prima
dell'annullamento, rilevano un tentativo di accesso su pop3 e telnet,
entrambi respinti in quanto non č stata concessa autorizzazione.
Poi ha beccato la 53 e... :-(
Il resto č cronaca. =:-O


Il resto č cronaca. =:-O
Scusa se mi intrometto, ma volevo chiederti una cosa: come si fa a vedere quali
porte sono aperte e cosa e come aspettano?
So che si deve usare il comando netstat, ma se devo essere sincero non riesco
ad interpretarne il contenuto. Mi potresti fare un esempio, per favore? 
Aggiungo che ho letto man netstat e provato varie opzioni, ma mi risulta tutto
comunque confuso. 
Mi saro' mica preso il prione della BSE ?!?! :-((
Grazie e ciao
Fabio

>Il resto è cronaca. =:-O
# netstat -ta
# man netstat
-- 
|Pierluigi De Rosa (
tho...@durin.khazad-dum.net
)|
|     E' nato il Cosenza Linux User Group	|
|   mail -s help 
cslug-...@lists.linux.it
	|
|      IRC: #cslug - 
irc.openprojects.net
	|

ad interpretarne il contenuto. Mi potresti fare un esempio, per favore? 
Una listata di netstat -na potrebbe fornirti, tra le varie cose,
risultati di questo tipo:
Proto  Local Address          Foreign Address        State
  TCP    
0.0.0.0:25
 
0.0.0.0:0
              LISTENING
La prima colonna indica il protocollo (tcp), la seconda l'indirizzo
locale (il tuo), la terza quello remoto. L'ultima indica lo stato
(nell'esempio, "in ascolto"). Quando trovi 0.0.0.0 sia come locale che
come remoto, e lo stato in listening, vuol dire che la porta non è
collegata, ma è semplicemente "in ascolto".
Dopo i ":" trovi un numero che indica la "porta", che identifica il
tipo di servizio.
Per esempio, la 25 locale è quella dell'smtp (se fai "netstat -a"
senza la "n" ti fornisce i nomi di host e porte, anziché i numeri, ma
il concetto non cambia).
Altro esempio:
  TCP    
0.0.0.0:80
 
0.0.0.0:0
              LISTENING
La 80, invece, è il server http, questo vuol dire che il server http è
attivo sulla porta 80 e sta aspettando connessioni.
Una porta "collegata" può essere una cosa di questo tipo:
TCP    
62.211.34.217:80
 
212.102.240.71:2635
    ESTABLISHED
Questo indica che c'è un utente collegato sulla porta 80, cioè quella
del server http, vedi che in questo caso il servizio si è collegato e
vengono forniti gli ip.
E così via per tutti i servizi.
Avere un servizio in "ascolto" non implica necessariamente che la
porta sia raggiungibile, per sapere quello devi controllare le
impostazioni del firewall.
Ovviamente, se *non* hai firewall, le _porte_ che sono in listening
sul tuo pc sono a disposizione di chiunque può raggiungere il tuo ip;
questo non vuole ancora dire che il servizio sia utilizzabile, perché
potrebbe essere protetto in altro modo (es. la poltica del hosts.allow
/ hosts.deny per quanto riguarda i servizi gestiti da inetd, oppure
gli ip abilitati al relay per postfix, etc.).
Ma normalmente, se non hai firewall e (per i servizi gestiti da inetd)
se non ha specificato politiche particolari in hosts.allow|deny, i
tuoi servizi sono potenzialmente raggiungibili dal mondo intero, a
meno che il tuo provider non abbia impostazioni che "a monte"
impediscano alla gente di raggiungerti direttamente (firewall o NAT a
monte della sottorete di sua competenza, ma non incasiniamo troppo le
cose).
Per sapere se una porta è effettivamente aperta oppure no, l'unica
è... provare :-)
Io sono solito fare prove con un mio amico, mentre chattiamo, gli
chiedo di provare a collegarsi col telnet ai miei servizi che sto
chiudendo: se gli viene respinta la connessione, la porta è chiusa, se
si collega è ovviamente aperta! (e tu dirai: de Lapalisse, questo
dilettante...) ;-)
