Le porte sono il mezzo essenziale che permette ai protocolli TCP e UDP di gestire flussi multipli di dati attraverso una unica connessione fisica alla rete.
In Internet ogni linea è individuata sulla rete da un indirizzo IP ma poiché molteplici possono essere i servizi offerti dal sistema e molte le connessioni contemporanee è necessario un metodo per separare i singoli flussi di dati ed indirizzarli verso il corretto programma di gestione.
Per questo motivo ogni sistema operativo gestisce 65536 porte per comunicare.
Queste vengono comunemente divise in:
- Conosciute (0-1023) : rappresentano alcune porte "fondamentali" e non dovrebbero essere usate se non per ruoli specifici.
- Registrate (1024 - 49151) : porte che, per quanto contenenti servizi ben conosciuti, possono essere utilizzate liberamente.
- Dinamiche o private (49152-6553) : porte assolutamente service-free.
Quello che pochi tengono in considerazione è l'importanza di randomizzare, quando possibile, il numero della porta associata ad un determinato servizio. Molti exploit, virus e simili, infatti, veicolano attacchi o infezioni proprio attraverso la conoscenza delle porte standard.
HTTP - 80, SMTP - 25, POP - 110, TELNET - 23 sono alcune tra le porte standard che non necessitano di essere cambiate.
Però servizi come Ultra VNC (5800), Emule (differenti nelle varie versioni), Mysql (3306),
e molti altri potrebbero funzionare senza problemi (se configurati correttamente) anche su porte differenti. In questo modo molti scanner che, ad esempio. cercano indirizzi ip con versioni mysql buggate sulle porte di default non troverebbero sistemi vulnerabili.
Lo spunto per questo articolo, in particolare, nasce dalla lettura di un ottimo articolo (in lingua inglese) di
Fernando Gont disponibile in versioni TXT,PDF o HTML
a questo indirizzo http://www.gont.com.ar/drafts/port-randomization/index.html oppure IN PDF
draft-ietf-tsvwg-port-randomization-01 (direttamente dal blog).
Il documento scadrà in Agosto ma spero venga aggiornato con continuità. I blink attacks, o attacchi alla cieca, rappresentano tutti quegli attacchi (a livello di server, webserver, ecc.) che non danno risultati direttamente visibili. Ad esempio le Blind SQL Injection si hanno quando il risultato della query iniettata in una pagina non restituisce messaggi di errore, ma al massimo rallentamenti nel server o crash (oppure modifiche particolari nel DB valutabili diversamente). Ebbene, come spiegato nel documento, negli ultimi anni si sono moltiplicati gli attacchi "ciechi" al protocollo TCP/UDP (che coordina principalmente le trasmissione di dati nelle reti attuali).
Tutti questi attacchi si basano sulla quintupla fondamentale:
- conoscenza del protocollo
- indirizzo d'origine
- porta d'origine
- indirizzo di destinazione
- porta di destinazione
In particolare si parla dell'utilizzo di algoritmi di randomizzazione per personalizzare il numero delle porte e soprattutto di non creare spiacevoli collisioni utilizzando particolari sistemi di hashing. Un'ottima lettura per quanto riguarda la sicurezza di network professionali e più casalinghi.
Naturalmente questo è solo uno degli accorgimenti che possiamo utilizzare.
Prudenza, firewall, controlli (
netstat -na e simili..), crittografia non possono mai mancare. Per approfondire il funzionamento delle porte, ecco un
articolo di facile comprensione di html.it.
Questo articolo è stato pubblicato il 31-12-1969 alle 18:33 e classificato in .
31-12-1969 alle 18:33
Hani, questo tipo di approccio e\' comodo per evitare attacchi di massa da parte di \"scriptkiddies\" e scan su larga scala, io stesso lo uso per evitare di leggere tonnellate di log di ssh ;) Pero\' bisogna ricordare che \"security by obscurity\" non e\' mai un buon paradigma di sicurezza, in quanto una volta scoperta la porta ( basta fare uno scan su range diversi ) il livello di sicurezza non e\' variato e inoltre questa parvenza di sicurezza aggiunta potrebbe portare ad \"abbassare la guardia\" con effetti disastrosi. Oltretutto le \"well-known ports\" sono assolutamente necessarie per servizi pubblici. Se cosi\' non fosse il web sarebbe un incubo da consultare... Cio\' nonostante, come dicevo, puo\' essere una buona pratica per servizi privati. Sia per eliminare le tonnellate di log dovute e tentativi di accesso casuali ( basati su account di default etc ) sia per rendere chiaro che si sta accedendo ad un servizio privato e non ad uso pubblico. Bb!
31-12-1969 alle 18:33
:\ la mysql_escape e' una buona pratica quando salvi sul DB.... ma ricordati l'unescape quando visualizzi :P
31-12-1969 alle 18:33
@Bria Quello che mi porta a pensare alla randomizzazione più che altro sono le zero day..che spesso sono accompagnate, appunto, da script kiddies agguerriti per i quali conta di più il numero di attacchi, senza veri obbiettivi. In quei casi, spesso, è difficile essere realmente protetti. Per quanto si possano effettuare update veloci, infatti, normalmente il rilascio delle patch sia successivo al report del bug. Allora anche questi "mezzucci" possono funzionare.. Sempre che possano essere adottati =) Per quanto riguarda l'unescape non capisco.. Prova 1 ' 2 " :F.. Niente..sei l'unico..xD