Sign in to follow this  
Guest

MAC OS X IN RETE e SU INTERNET

Recommended Posts

Guest

-- e' una specie di redirect

---- piu' o meno.

per sapere cosa e' cat leggi il suo man ;-)

il simbolo di minore dice a cat di processare /etc/services e la pipa | reindirizza l'output di cat come input di less (man less). Potevi mandarlo a more o a grep ecc.

Fai qualche tentativo nella tua home con i files di testo e i vari minore, maggiore, pipa, doppio maggiore ecc. (scusa, ma devo scriverlo cosi' altrimenti l'intrfaccia web del forum li interpreta per chissa' cosa)

Magari prendi un tutorial a caso per linux e seguilo.

Share this post


Link to post
Share on other sites

Posso permettermi di sfatare 3 miti?

1) Il servizio ssh e' piu' sicuro di telnet.

2) Il firewall di osx protegge da intrusioni esterne.

3) Le manpages sono inutili e incomprensibili.

Motivi:

1) il demone ssh gestisce le password in modo criptato, mentre telnet le gestisce in 'chiaro'. Ssh quindi non consente a un hacker GIA' introdotto nella nostra macchina di rivelare le password che ancora non sa. Ssh non consente nemmeno al vostro provider di sbirciare nelle vostre sessioni remote. Tutto qui. Nulla a che fare con la 'sicurezza'. Dopodiche' aggiungo che il demone ssh in questi ultimi mesi (vedi bugtraq) e' il servizio considerato potenzialmente piu' vulnerabile. Il brute forcing dello stack del demone e' pratica diffusa, semplice, e con la quale di ottiene con estrema rapidita' l'accesso come root alla shell del sistema. Ergo: la vostra macchina/rete rischia una TOTALE compromissione per colpa dell'utilizzo 'normale' di sshd (chiamato "Login Remoto" su osx).

Io non uso ssh. Uso sempre telnet. Un comodo sniffer (uno qualsiasi) mi consente di monitorare costantemente le attivita' di chi usa il server. Ogni amministratore dovrebbe poterlo fare.

2) Il firewall e' come una porta blindata. Se la chiudi non passa nessuno. Se la apri passano tutti. L'unico modo di utilizzare con successo un firewall, e' quello di scendere nei meandri piu' profondi della sua configurazione, capirla, e agire di conseguenza.

Esempio: aprite la condivisione ftp su osx. Se attivate il firewall di osx, i servizi 'spuntati' saranno diponibili, gli altri no. Bene. Scusate ma, mi spiegate l'utilita' di questa cosa? Secondo me non ne ha proprio. Se un servizio non deve essere utilizzato, non bisogna chiudere la porta, bensi' spegnere il demone. Ora, la GUI del firewall di osx fa schifo, fa pieta', e' un puro esercizio di inutile stile. Per fortuna qui entra in gioco BrickHouse. E il Terminal.

A mio modestissimo parere un firewall settato bene deve consentire un accesso selezionato ai servizi. Cosa significa? Significa che io devo poter decidere CHI puo' collegarsi al mio server ftp e chi NO. Con Brickhouse posso decidere quali IP (o quali classi di ip) sono abilitati alla connessione a un determinato servizio. Posso abilitare l'accesso ai client della LAN e disabilitarlo a internet. Con un click. Poi, non contento, posso editare con il Terminal il file /etc/ftpusers. Gli users listati in quel file NON possono fare login con ftp. E' utile disabilitare gli admins, il root e gli users corrispondenti ai vari demoni, anche spenti.

Tutti gli altri servizi (telnet web sql ecc) hanno la possibilita' di 'filtrare' gli accessi, sia utilizzando i loro script di conf, sia utlizzando BrickHouse. Vorre sottolineare anche come BrickHouse non sia un firewall, ma una semplice GUI costruita per rendere facile la configirazione di 'ipfw', firewall/router integrato in osx.

La configurazione di ipfw puo' essere fatta anche tutta da Terminale. Non e' ASSOLUTAMENTE una cosa difficile. Un pdf generico su osx presente su macity, non ricordo il link ma e' roba di poco tempo fa, contiene fra le tante cose anche la spiegazione di come aggiungere 'regole' al firewall di osx.

PostArmor: "Un firewall, invece, impedisce qualsiasi tipo di risposta, quindi a tutti gli effetti il computer non esiste al portscan..."

Non e' assolutamente cosi'. IL firewall di osx non previene assolutamente il portscan. Prova con nmap. L'unico modo che hai su osx di nascondere una porta e' quello di spegnerlo, oppure quello di filtrarlo totalmente togliendo la spunta dal firewall.. che equivale esattamente a spegnerlo.

L'unica soluzione per avere servizi SICURI e' quella di settare il firewall con regole PRECISE, utilizzando password LUNGHE, affidate a utenti FIDATI, e tenendosi aggiornati SPESSO sui tanti modi con i quali un servizio puo' essere 'bucato', sia dall'esterno sia dall'interno. Se tutto cio' vi sembra troppo, allora non aprite nessun servizio. Non sperate che ci possa mai essere un sistema operativo che consenta a un 'newbie' di gestire server in modo 'sicuro'. Non puo' esistere.

3) Chest: la prima volta che ho usato man e' stato con la DP2 di osx. Te la ricordi? Non sapevo nulla non capivo nulla e mi schifava quella inutile e incasinata serie di incomprensibili messaggi subliminali da geek in fase terminale.

Bene. Ora ti dico che le man pages sono la parte piu' importante di osx. Sono il succo di Unix, sono lo strumento (l'unico cosi' veloce) con il quale un ignaro amighista come me ha imparato a conoscere e ad utilizzare UNIX. E come godo nel vedere che tutto cio' che imparo su osx, va benissimo su Freebsd, Linux, Irix.. Su tutti i miei sistemi.

Bisogna entrare nella loro filosofia. Bisogna accettarne sia la necessaria concisione, sia il fatto che alcune di quelle pagine furono scritte 20 anni fa da persone che forse ora non ci sono nemmeno piu', e che mai pensarono di poter finire su una cozza arancione con pipici' come la mia.

Se non ci fossero state la man pages non avrei mai capito come muovermi, credo che oggi sarei, mio malgrado, passato a windows. Dove non c'e' nulla da capire. A me sinceramente fa piu' schifo l'opuscoletto del cavolo che si trova nella scatola di Jaguar. 10 euro buttati in inutile carta patinata che spiegano quello che anche un microcefalo avrebbe capito in 3 minuti di utilizzo di osx!

Bene, ho concluso, ho espresso le mie personalissime opinioni, attendo risposte perche' la questione della sicurezza e' FONDAMENTALE per lo sviluppo della nostra piattaforma.

ciao ciao

Share this post


Link to post
Share on other sites
Guest

Ora, la GUI del firewall di osx fa schifo, fa pieta', e' un puro esercizio di inutile stile. Per fortuna qui entra in gioco BrickHouse. E il Terminal.

Mi fa piacere che qualcuno condivida la mia preferenza per BrickHouse, comparato con il nuovo pannello di controllo, anche se non ho usato un'espressione cosí forte... Ad esempio, pensate alla necessitá per una ditta di avere un server FTP, ma accessibile solo agli utenti interni: con BrickHouse si fa, con il pannello standard no...

La configurazione di ipfw puo' essere fatta anche tutta da Terminale. Non e' ASSOLUTAMENTE una cosa difficile. Un pdf generico su osx presente su macity, non ricordo il link ma e' roba di poco tempo fa, contiene fra le tante cose anche la spiegazione di come aggiungere 'regole' al firewall di osx.

Sono d'accordo che da Terminal si puó fare una configurazione ottimale, l'ho fatto spesso anch'io, ma, scusa Hany, quand'é l'ultima volta che hai avuto a che fare con utenti non particolarmente dotati tecnicamente?

PostArmor: "Un firewall, invece, impedisce qualsiasi tipo di risposta, quindi a tutti gli effetti il computer non esiste al portscan..."

Non e' assolutamente cosi'. IL firewall di osx non previene assolutamente il portscan. Prova con nmap. L'unico modo che hai su osx di nascondere una porta e' quello di spegnerlo, oppure quello di filtrarlo totalmente togliendo la spunta dal firewall.. che equivale esattamente a spegnerlo.

Un po' di precisazioni si impone: un hacker ha piú maniere di cercare ed attaccare un bersaglio.

Una é il port scan "generico" (non é un termine tecnico, ma spero che ci capiamo), ovvero una scansione di tutta una serie di indirizzi IP per vedere se una porta, talvolta lasciata aperta da utenti ignari/ignoranti, é disponibile all'attacco. Un esempio tipico é la porta 139, usata da Windows per la rete, e quindi tipicamente aperta. In questi casi, il firewall attivo rende la porta "invisibile" e quindi l'hacker non si accorge che a quell'indirizzo c'é un computer "attaccabile".

Diverso é invece il caso di un hacker che giá sa che a quel particolare indirizzo esiste una macchina, e prova un portscan su di esso per vedere cosa é rimasto aperto. Qui entra in gioco una corretta configurazione del firewall: se un servizio deve essere attivato in maniera solo parzialmente pubblica (vedi sopra), una richiesta di connessione proveniente da un indirizzo non autorizzato deve non solo essere respinta, ma completamente ignorata, in modo da non offrire all'attaccante indizi su che servizi possono essere disponibili e sfruttarne le debolezze.

Se sono stato ancora una volta troppo tecnico, mi scuso... ma mi sembra che stiamo arrivando ad una comprensione migliore...

Share this post


Link to post
Share on other sites

Concordo parzialmente con cio' che dici.

"il firewall attivo rende la porta "invisibile" e quindi l'hacker non si accorge che a quell'indirizzo c'é un computer "attaccabile"."

Qui bisognerrebbe discuterne davvero molto approfonditamente. Bisognerebbe anche dare una definizione piu' precisa di 'firewall'. Direi di limitarci qui a parlare di firewall software che agiscono sui client (come osx), tralasciando quelli su router oppure i proxy.

Come tu sai esistono due tipi di port scan: ACK e SYN. I normali portscanner da lamer si limitano ad eseguire uno scan di tipo ACK, mandando richieste a una determinata porta e aspettando la risposta. Alcuni firewall software riconoscono il 'fingerprinting style' dei portscanner piu' famosi, e tentano di 'non rispondere' mascherando la porta (e quindi il servizio). Altro tipo di scan e' il SYN: in questo caso il trucchetto di mascherare la porta non serve. Se esiste un servizio, questo verra' scoperto (o perlomeno intuito). L'unico modo per non mostrare una porta come 'OPEN' e' quella di filtrare, ossia di negare l'accesso a un range o a una classe di ip. Se un servizio e' attivo e se e' raggiungibile dall'host XYZ, allora un portscan (fatto come si deve) eseguito dall'host XYZ dara' risposta positiva, ossia servizio aperto.

Esistono ovviamente eccezioni ed eccezioni alle eccezioni.. Certo e' che la tua frase che ho citato non e' applicabile a osx in quanto ipfw non consente (che io sappia) di nascondere a un portscanner un servizio 'attivo e raggiungibile'.

Potremmo discutere piuttosto su come implementare servizi 'fittizi' (sniffer che simulano demoni) e su come spostare le porte dei servizi piu' usati o su come modificare i 'banners' di osx greppabili col synscan .. Hai qualche esperienza su darwin in proposito?

Share this post


Link to post
Share on other sites
Guest

Ora andiamo veramente sul tecnico... e non ho difficoltá ad ammettere i miei limiti (e la mia ignoranza!). Mi sono occupato di queste cose entro i limiti che mi interessavano, ma non sono andato piú in lá di questo.

Non che la cosa non sia interessante, ma ho paura che perderemmo molti per strada su questa linea: cosa ne pensano gli altri? Che sia il caso, eventualmente, di portare questa parte di discussione in un altro thread?

Share this post


Link to post
Share on other sites

stai schezando? questo thread e' il piu' interessante degli ultimi mesi, faccio i complimenti a chi l' ha creato (io..ehehehe).

per quello che penso io, la cosa diventa sempre piu' interessante.

penso che me lo salvero' pure questo thread..

quando ho fatto il thread volevo appunto entrare in discorsi tecnici, faro' il massimo per capire tutto, al massimo chiedo; ma vi prego continuate.

Share this post


Link to post
Share on other sites
Guest

Beh, mentre su altri argomenti (spam, web e protocolli vari) ho ancora qualcosa da dire, sul discorso firewall io ho piú o meno giá detto tutto quello che so... e non é né molto né del tutto esatto, come Hany correttamente puntualizzava...

Magari qualcuno vuol fare un sommario di quello che si é capito finora?

Share this post


Link to post
Share on other sites
Guest

certo che OSX ha fatto felici tutti quelli che hanno swithcciato da windows e poi si sono sentiti un po` orfani del puro e duro "smanettare" a cui erano abituati, qui pero` i risultati sono piu` consistenti credo

Share this post


Link to post
Share on other sites
Guest

Hany, e' tutto corretto.

Il problema e' che stiamo parlando in un forum mac di utenti "normali" e il problema era garantirsi la sicurezza a casa.

In questo contesto continuo a pensare che, su Mac, il consiglio migliore sia quello di disattivare i servizi non strettamente necessari e vivere tranquilli, dando magari ogni tanto una occhiata ai log.

Se poi il discorso che abbiamo fatto stimola qualcuno ad approfondire, iniziando dallo stack iso/osi, e arrivando fino alla configurazione manuale di ipfw, ben venga, ma il trafficare su queste cose senza avere le idee abbastanza chiare puo' causare piu' pericoli di quelli che cerca di eliminare.

Detto questo, io traffico con iptables su linux che e' abbastanza diverso da ipfw, anche se ovviamente la di base e' la stessa.

Un piccolo hint per qualcuno che puo' avere problemi a raggiungere la macchina di casa perche' magari, come me, al lavoro e' dietro un firewall che blocca il traffico che non sia www, ftp e mail.

Io ho risolto configurando sshd (il demone di ssh) in modo che resti in ascolto sulla porta 110 (quella di pop3) invece che su quella di default.

Banalmente, basta modificare il file /etc/sshd-conf, che oltretutto e' ben commentato.

Share this post


Link to post
Share on other sites
Guest

Ordunque, seguendo un link da un articolo di Ars Technica, ho trovato questa pagina:

SANS/FBI Top 20 List

Quello che ci interessa é nei secondi 10 "top", ovvero quelli che riguardano Unix, e come lettura é quanto mai illuminante come tutorial...

Lo stesso articolo fornisce un link ad un sistema di test gratuito: io mi sono fatto testare la mia connessione, e l'unica (parziale, grado 3 su 5) vulnerabilitá che é stata trovata riguarda Apache, ed in particolare l'attivazione di test-cgi (che peraltro NON é attivo all'installazione di OS X, ma va esplicitamente abilitato, ed io lo avevo fatto per motivi miei). Sembra quindi che, con una buona configurazione del firewall, Mac OS X abbia una relativa sicurezza intrinseca.

Qualcun altro puó postare i risultati per la propria connessione, magari anche con una configurazione "utente normale", cosí da poterli confrontare?

Share this post


Link to post
Share on other sites
Guest

SSH è più sicuro di telnet, eccome.

Con il primo puoi forzare lo stack E BASTA: non vedi le pass di altri e non puoi, intercettando il traffico internet, vedere le pass (l'hai già detto tu, vero?).

Con telnet puoi fare invece tutto ciò elencato sopra.

Riassumendo: con SSH puoi solo forzare lo stack (ma SSH è aggiornato costantemente), con telnet hai ben più modi per avere pass.

Share this post


Link to post
Share on other sites

Si ma scusa, una volta ottenuto il login forzando lo stack di sshd posso cattare /etc/shadow o /etc/passwd, spesso anche senza essere root. Oppure posso lanciare uno sniffer con il quale loggare le attivita' di rete, i cambi password, i login effettuati su altri servizi, oppure semplicemente registrare le sequenze di pressione dei tasti. Tutto questo in circa 10 secondi, installando un qualsiasi rootkit. Osx compreso. In massimo 24 ore avro' le password. Ora, un breaker se vuole sapere le pass non le cerca decrittando il traffico ssh, bensi' sfruttando tutti gli altri sistemi, ben conosciuti e strausati. Come tu ben sai la crittatura di sshd avviene sul percorso tra i due host collegati. Ma cio' che viene digitato in locale e' sempre in chiaro. Quando tu scrivi la pass di una sessione ssh, viene crittata in uscita, vero, ma se sono loggato sulla tua macchina la vedo senza problemi, in chiaro, a colori e con tanto di effetto lente..

Quando dico che sshd non e' piu' sicuro di telnetd mi riferisco proprio a questa situazione. Ottenere i privilegi di root senza fornire una password e' un gioco da ragazzi. Tutto il resto e' ancora piu' semplice. Dopodiche' e' vero che ssh si aggiorna costantemente, ma cio' non basta perche' il sysadmin medio non sa nemmeno cosa sia un exploit, quindi..

Rimango convinto che

1) i servizi inutilizzati devono essere spenti.

2) il login remoto, se necessario, conviene farlo con telnet magari sulla porta 36763 con tanto di hosts deny, logging feroce e tanta tanta pazienza nel controllare SPESSO che la dimensione & checksum di 'ls', 'ps', 'du' ecc.ecc. siano invariati.

Questa e' la mia personalissima (e, lo so, poco condivisa) opinione, ma e' dettata dalla mia esperienza quindi potrebbe essere decisamente parziale e imprecisa. Pero' da quando mi hanno forato la IRIX con l'ultimo sshd (6 mesi fa, erano miei amici per fortuna..), ho giurato eterna fedelta' al telnetd.. e alla ultra-paranoia da sysadmin in guerra.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this