Newsgroup: it.comp.os.linux.sys
Titolo: slackware: navigare sicuro

ciao a tutti,
finalmente sono riuscito a configurare la mia linux box (slackware 8.0, 
2.2.19) per navigare con la nuova linea adsl. sono soddisfatto però
ho un dubbio sulla sicurezza. ho impostato ALL:ALL su /etc/hosts.deny
e poi ho tolto tutti i servizi che non servono sia da /etc/rc.d/.... sia
da /etc/inetd.conf.
ora il risultato di netstat -nat è questo:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State   
 
tcp        0      0 
10.0.0.141:1025
 
10.0.0.138:1723
 
ESTABLISHED 
tcp        0      0 
0.0.0.0:1024
            0.0.0.0:*               LISTEN  
 
tcp        0      0 
0.0.0.0:6000
            0.0.0.0:*               LISTEN  
 
tcp        0      0 
0.0.0.0:113
             0.0.0.0:*               LISTEN  
 
dove ovviamente il 10.0.0.138 è l'indirizzo del modem/router adsl.
in questa situazione ho bisogno di ulteriore protezione?
grazie.
-- 
bye paolo,

 in questa situazione ho bisogno di ulteriore protezione?
si. tanto per cominciare avvia X in modo tale che non rimanga in ascolto 
sulla porta 6000. (hint: alias startx='startx -- -nolisten tcp'). poi 
hai il servizio auth in ascolto sulla tua macchina.
verifica il demone inetd (file di conf inetd.conf) e togli tutto quello 
che non ti serve (praticamente puoi anche commentare tutto o 
disabilitare il demone). poi, la porta 1024 non so a che servizio 
corrisponda... prova a verificare con
# fuser -v 1024/tcp
se il modem router adsl non fa anche da firewall, conviene forse che tu 
ne metta uno sulla tua slack.
ciao!
-- 
signature: No such file or directory

paolo wrote:

Mah, secondo me chiudere i servizi inutili è sicuramente importante. 
Fondamentale è invece chiudere tutte le porte. Immagino su slackware si usi
iptables... (cerca su google)
-- 
Lucius in fabula
--www.lucius.it--

Denny wrote:

ciao
con fuser mi da questo output
                     USER        PID ACCESS COMMAND
1024/tcp             acme        153 f....  kdeinit
è qualcosa a che fare con kde (che uso come window manager)
ma non capisco cosa.
-- 
bye paolo,

 usi iptables... (cerca su google)
si, in realtà con red hat usavo iptables ma poi mi sono scocciato e
sono passato a slackware.
io credo che se sulla linux box non ci sono porte aperte, di iptables se
ne potrebbe fare anche a meno. al limite utilizzo un ids.
-- 
bye paolo,

 
la mia era solo una considerazione.
-- 
bye paolo,

 ne potrebbe fare anche a meno. al limite utilizzo un ids.
Dicevo immagino, perchè, ad es., mi è capitato di dare un'occhiata a Suse,
dove mi pare di aver visto che il sistema usa un frontend un po' diverso
(non so se di iptables o netfilter).
Cmq credo tu abbia un po' di confusione:
Un ids non filtra proprio nulla (Detection System appunto), a meno che tu
non gli attacchi qualcos'altro (che sempre su iptables lavora). V.Snort col
plugin di modifica regole (non mi ricordo il nome). Cmq mi è capitato di
provare molti frontend di iptables, ma secondo me:1.richiedono la
conoscenza dello stesso per essere usati con intelligenza. 2. iptables è
molto razionale e quindi semplice da usare, una volta capitii i meccanismi.
Naturalmente imho, poi vedi tu...


 
Sei sicuro? Se poi ti si apre un servizio di cui non ti accorgi?
Ogni volta che installi qcs devi stare attento. E se si scopre una
vulnerabilità su protocolli che non usano porte (v icmp) e tu non lo sai?
Mah...


 in questa situazione ho bisogno di ulteriore protezione?
Beh, X lo lancierei in modalita` "no-listen-tcp", in debian e` default.
Identd (la porta 113) se non ti serve, lo puoi pure eliminare.
cosa ti tiene aperto la 1024? rpc? portmap? se non hai da usare share
nfs togli.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
In God we trust. (All others pay cash.)

 non gli attacchi qualcos'altro (che sempre su iptables lavora).
Non e` vero. _tipicamente_ un ids e` uno strumento "passivo", ma molti
sono anche attivi. E` il caso di portsentry, ma anche dello stesso
snort.
E non e` vero che fanno cose "con iptables". Dipende come lo configuri
(un caso classico di portsentry e` un drop della route che quindi non ha
nulla a che vedere con iptables).
PS:
Chi mi conosce, sa bene quanto ritenga "deprecabile" l'uso di ids
attivi, ma questo non significa che non esistano.


 icmp) e tu non lo sai?  Mah...
Questo non vuol dire nulla. Seguendo lo stesso filo logico, se si scopre
una vulnerabilita` per iptables e tu non lo sai?
Una macchina che non offre servizi, e` intrisecamente piu` sicura di una
che ne offre protetta da un firewall, e` un dato oggettivo.


 iptables... (cerca su google)
Sciocchezza, non ha senso chiudere una porta che non esiste. Fai
lavorare il doppio il sistema per fare una cosa che lo stack tcp/ip
farebbe gią nativamente (impedire la connessione).
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 
-- 
Lucius in fabula
--www.lucius.it--

 che ne offre protetta da un firewall, e` un dato oggettivo.
Ma questo è naturale. Forse mi sono spiegato male. Io non dicevo di lasciare
aperti servizi inutili e chiuderli col firewall, anzi: però secondo me è un
dato oggettivo che una macchina che non offre servizi ed è protetta da un
firewall, è intrinsecamente più sicura di una che non è protetta.Tutto qui.
E che quando si pensa alla sicurezza è sempre buona norma chiudere tutto e
aprire esplicitamente ciò che serve. 
Dixi (imho)


 farebbe già nativamente (impedire la connessione).
Prego? Ma che firewall usi? Non si parlava di iptables/netfilter? Come si fa
a chiudere una porta che non esiste? e sopra tutto, come si fa a usare cpu
per farlo?
Netfilter è fatto a catene, ognuna con una policy di default... Se un
pacchetto in transito nella catena matcha una richiesta si infila nella
relativa catena e così via ... fino ad un ACCEPT , DROP, REJECT, etc. 
Non credo sinceramente (correggimi se sbaglio) che ci sia una gran
differenza di di cicli tra un ACCEPT e un DROP.
E comunque è buona norma quando si mette su un firewall, impostare a DROP
tutte le policies di default, e poi aprire quel che serve (specialmente
quando si parla di firewalls/gateways).
Tutto imho.


 netfilter/iptables.
Anzi, riperdonatemi il doppio post: da man iptables:
iptables - administration tool for IPv4 packet filtering and NAT
[...]
Iptables  is  used  to  set  up, maintain, and inspect the tables of IP
       packet filter rules in the Linux kernel.
[...]

 tcp/udp, in formato numerico, e il processo che le apre.
uh. e io che continuavo ad usare fuser e lsof :) tnx!


 
no non č una share nfs bensi č il processo kdeinit: kxmlrp.
-- 
bye, paolo
/bin/fiatrun -offset(stilo,jtd,gniik-gniik,/dev/scrik,115cv,33,RM)

lucio wrote:

la mia era solo una considerazione. usare iptables implica
una conoscenza specifica e se usato in maniera errata non apporta benefici, 
imho. 
riguardo alle vulnerabilità penso che più si riesce a tenere aggiornato il 
sistema meno rischi si corrono. poi non credo esista un sistema sicuro al 
100%.
 
-- 
bye, paolo

 Naturalmente imho, poi vedi tu...
mah, io ho già aggiornato il kernel e ricompilato per utilizzare iptables. 
è molto probabile che abbia fatto un pò di confusione nella mia prima
risposta al mio precedente post.
-- 
bye, paolo

 
provvederò
-- 
bye, paolo

 quando si parla di firewalls/gateways).
Questa è appunto la sciocchezza che contesto.
Se ti arriva una richiesta di connessione sulla porta - che so - 80 ma
tu non hai un web server, in condizioni normali lo stack tcp/ip non ha
servizi attivi sulla porta 80 e rigetta autonomamente la richiesta. CPU
usata: niente di più che quella per la gestione dello stack tcp/ip.
Il genio di turno invece che pensa: "moh chiudo col firewall la porta
80". Succede che lo stack tcp/ip lavora come avrebbe lavorato prima, ma
in più la richiesta viene passata al netfilter, che ha la regola in
DROP e cassa il pacchetto.
Perché far tutto questo lavoro in più? Non guadagni NIENTE.


 aprire esplicitamente ciò che serve. 
Yep. E` una questione di "priorita`". Specie in nuovi utenti, chiedono
"devo installare un firewall per la sicurezza della mia macchina". E`
sbagliato. _Tu_ lo sai perche` non sei un "nuovo utente", ma loro no.
Spesso "loro" (i nuovi utenti) hanno esperienze su Windows dove non ti
e` _permesso_ chiudere i servizi (un po` di roba rimane aperta,
netbios-sarcazzi su tutti). Quindi _ti_serve_un_firewall_. Ma questo e`
solo un malcostume Microsoft.
Inoltre, spesso un firewall (come un antivirus), pone l'utente in una
situazione di "falso senso della sicurezza": tanto c'e` il firewall!
Il firewall, l'antivirus, sono _strumenti_, e non si sostituiscono
all'utente. Ecco perche` e` piu` importante imparare a governare _bene_
la propria macchina che non ad utilizzare un firewall (che detto tra
noi, in questo senso, spesso si riduce nell'utilizzare uno script di
altri).
Per capirci: _tutti_ i miei server in dmz _non_ hanno firewall. Serve a
non permettere alla mia pigrizia di installare software buggy, non
testato o altro, e a tenere la soglia di attenzione _alta_.[*]
Dai tuoi messaggi, emergeva che _deve_ installare un firewall a
prescindere, come "prima cosa". Io sostengo che "come prima cosa" invece
deve fare quello che stava facendo: conoscere i propri servizi, e
disabilitare quelli inutilizzati. Se poi ci sono servizi che
_deve_/_vuole_ offrire, _allora_ ha senso ragionare su un firewall (e
nemmeno sempre).
[*]
pero` per correttezza dell'info, ho un po` di sensori perimetrali, un
bastion-host, un firewall sul border-router e uno sll'inner... :)
Ma i server escono full-ip.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Hardware, n.: The parts of a computer system that can be kicked.

 no non č una share nfs bensi č il processo kdeinit: kxmlrp.
Non utilizzo kde, ergo non so dirti se quel demone e` importante per
l'uso di kde o meno, aspetto consigli da "conoscitori" di kde.
Certo che quel "rp", che suppongo stia per "remote procedure" non e`
proprio il massimo.
Se puoi eliminarlo (leggi, se non attiene al funzionamento di kde nella
tua situazione), eliminalo. Diversamente dovrai filtrarlo (informati se
supporta tcp_wrappers che potrebbe esssere una risposta veloce e poco
overkill).
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 nemmeno sempre).
Ok, mi sono spiegato decisamente male. Non volevo dire questo. Alla domanda
"Ok, ho chiuso tutto, sono sicuro?", volevo ricordare che non si è mai
troppo sicuri...


 
Mah, secondo me la cosa è da approfondire. Se è attivo netfilter, credo che
qualunque pacchetto che arriva sulla macchina venga filtrato,
indipendentemente dalle porte aperte. Cioè se la 80 è chiusa, ed io lascio
ACCEPT, il pacchetto cmq si scorre la catena, viene accettato e poi
rigettato (credo con l'equivalente del tcp reset...). Se sai darmi una
spiegazione più dettagliata te ne sono grato, ad ogni modo mi metto in
cerca ed approfondisco l'argomento. Voglio anche vedere qual è l'effettivo
carico sulla cpu di netfilter.
Saluti


lucio wrote:
Prova del fatto, è che volendo è ancora possibile usare ipchains per
modficare le regole di netfilter,E ipchains è un tool diverso da iptables.


 carico sulla cpu di netfilter.
Sulle CPU moderne penso insignificante, ma se ti trovi un 486 che vuoi
reimpiegare come server/firewall, lo può fare benissimo, ma i servizi
vanno scelti e configurati ACCURATAMENTE...


 iptables.
Non sono stessa cosa, a livello kernel intendo.
Ciao.
-- 
***  Per E-mail rimuovi ModE dall'indirizzo  ***
  *** Linux user # 198661 --- ICQ 33500725 ***
*** homepage 
http://web.tiscalinet.it/kailed
 ***
            *** Powered by Linux ***

 
Si certo, ma lavorano tutti e due su netfilter.
Ciao


 vanno scelti e configurati ACCURATAMENTE...
Certo, ma se ci metti il firewall, cioè i moduli netfilter, imho è
impossibile che un pacchetto non venga processato... sinceramente non vedo
come. D'altro canto se vuoi anche solo mettere su un server senza firewall,
mi pare un suicidio.E se c'è su netfilter, i pacchetti vengono tutti
processati. Se vuoi ottimizzare al massimo le prestazioni (molto molto
imho, qui vado per congetture), devi pensare all'ordine delle catene. Cioè
se hai la 80 chiusa, forse è proprio il caso di aggiungere in testa alla
catena INPUt un drop sulla 80, perchè statisticamente la maggior parte
delle richieste dal web su un server arriveranno su quella porta, e se
vengono riconosciute in testa alla catena, non devono ogni volta
scorrersele tutte. Tutto questo a discapito di un filo di ram in più (una
catena in più) che però è veramente irrilevante.


 impossibile che un pacchetto non venga processato... 
Se non ci sono catene in cui infilarlo, non vorrei fare proposte oscene
su dove lo può infilare lo stack tcp/ip... :-bbbbbbbbbbbbbb


 su dove lo può infilare lo stack tcp/ip... :-bbbbbbbbbbbbbb
Le catene ci sono per forza, se c'è netfilter, perchè qualunque pacchetto
finisce di default nella INPUT o nella FORWARD, per cui entra in catena, se
poi non ce ne sono altre, vale il discorso del post precedente.
Poi si, lo stack tcp gioiosamente accoglie...:-) 


 Ma i server escono full-ip.
Scusa, non ho capito bene. Il firewall sul border-router filtra anche i
pacchetti della dmz? O ho capito male?
Se ho capito male, per curiosità, come ti regoli per syn-flood, icmp smurf
etc.?
Grazie


 Se ho capito male, per curiosità, come ti regoli per syn-flood, icmp smurf
su icmp smurf c'e` poco di cui regolarsi: il mio router e` configurato
bene. Se qualcuno mi smurfa, mi smurfa, c'e` poco da fare. C'e` solo da
sperare di avere piu` banda dello smurfer.
Stessa cosa dicasi per il flooder.
Perche` tu pensi di occupare meno banda con un reset, o un drop?
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If it's already broken, force it.

 Perche` tu pensi di occupare meno banda con un reset, o un drop?
A questo punto vado molto a naso... Cmq credo che un drop, lasciando morire
il pacchetto, ne occupi meno. Sicuramente non col reject. Attendo eventuali
delucidazioni.


 delucidazioni.
Per saturarti la banda, devo saturarti la banda in "entrata", e mandarti
in dos, perche` tu non riesca piu` a ricevere nulla.
Il fatto che tu mi risponda, o meno, cambia poco-nulla, ed incide sulla
tua banda in "uscita", che non e` l'obbiettivo _tipico_ del dos.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If you lie to the compiler, the compiler will get its revenge.