Newsgroup: it.comp.sicurezza.varie
Titolo: Strane Porte

Perdonate la mia ignoranza... :)
Uso linux slackware 3.40 ,e facendo un'autoscanning ho notato con mio
grande stupore che vengono aperte oltre ai servizi classici,le porte
2049 e 688 corrispondenti ,evidentemente, a servizi sconosciuti.
Questi servizi ,apparentemente,non sono lanciati da inetd.
Desidererei sapere:
1)come posso fare per sapere da chi o cosa ,vengono lanciati?
2)a cosa potrebbero riferirsi?
3)Qualora fossero "backdoors",il fatto che usi le protezione classiche
dei files hosts.allow ed hosts.deny ,puo' considerarsi una sia pur
parziale protezione ,ovvero detti files operano solo sui servizi
lanciati da inetd?
Non ci giurerei,ma ho l'impressione che questa situazione si e'
verificata dopo l'installazione di un determinato logging tool.



 lanciati da inetd?
Se hai i servizi principali sotto tcpd ed hai eliminato (ergo commentato) da
inetd.conf quelli inutili (imap, pop3 ecc.) non dovresti preoccuparti.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>

 inetd.conf quelli inutili (imap, pop3 ecc.) non dovresti preoccuparti.
beh se un processo mostrato da fuser o lsof NON fosse legale, o se fuser
fallisse nel cercare in proc il processo colpevole, allora potrebbe essere
una backdoor occultata, e le ACL di tcpd intervengono di default solo sui
processi spawnati da inetd, o cmq solo dove tcpd sia chiamato come wrapper
del processo.
invy
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------

 del processo.
E' vero... e allora in questi casi? Buttofori l'utenti, telinit s e via
di controllo a raffica?


 di controllo a raffica?
meglio esser sicuri per questo. se anche /proc fosse compromesso via
chiamate di sistema, il rischio e' quello di non potersi fidare neanche di
netstat. A questo punto ci vuole un occhio mediante lsof/fuser sui
processi legali dei tuoi utenti ed uno su di uno sniffer. Uccidi le 
connessioni anomale, e passale alle rules del packet filter. 
poi procedi ...


 di controllo a raffica?
dipende ... se il sistema contiene dati importanti e non e' un
multiutente, o cmq ha una policy che lo preveda, disabilita l'interfaccia,
singlemode e confronto con binari originali da DB r-only. Per iniziare :)
Oppure controlla le porte con uno sniffer e decidi quali connessioni
piegare e rimbalzare e comincia pure i controlli.


 di controllo a raffica?
meglio esser sicuri per questo. se anche /proc fosse compromesso via
chiamate di sistema, il rischio e' quello di non potersi fidare neanche di
netstat. A questo punto ci vuole un occhio mediante lsof/fuser sui
processi legali dei tuoi utenti ed uno su di uno sniffer. Uccidi le 
connessioni anomale, e passale alle rules del packet filter. 
poi procedi ...
invy


 piegare e rimbalzare e comincia pure i controlli.
apropos di questo, sto studiando l'Ipchains-HOWTO... ma si possono davvero
far rimbalzare le connessioni su un altro indirizzo tipo uno che cerca di
usarmi come relay sulla porta 1080 per IRC posso mandarlo a fare lo stesso
su un sito a caso (
www.gdf.it
)?
thorin "che maligno, mi si aprono nuovi mondi.."
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
<<   Available PGP keys: DSS/DH                   >>

 connessioni anomale, e passale alle rules del packet filter. 
Beh quello e' facile... basta anche controllare da dove sono connessi
(console locali ecc.) e poi da li' discriminare... della serie "stare
sempre vigili e con l'occhi spalancati..."


 su un sito a caso (
www.gdf.it
)?
usando il forwarding no. per il semplice fatto che i pacchetti che ti
arrivano chiedendo della tua 1080 hanno il tuo IP come destinazione. C'e'
poco da mascherarli/forwardarli. E se da un lato tu volessi ridirottarli,
beh, appiccicheresti il tuo IP alla query remota, cosa che non sarebbe
consigliabile per 
gdf.it
 :) La cosa migliore e' come al solito lasciarli
appesi in attesa di timeout per mancanza di ICMP_UNREACH mediante DENY ...


 sempre vigili e con l'occhi spalancati..."
non solo :) il problema e' proprio questo. se non ti puoi fidare di /proc
perche' hanno modificato una system call puoi anche scommettere che last,
w, who, finger e co. bella non riportino nulla :) perche' avranno toccato
anche quelli. In quel caso una tabella sinottica processi, porte, utenti
legali e mostrabili coi suddetti binari per discriminare ...


 poco da mascherarli/forwardarli. E se da un lato tu volessi ridirottarli,
Ho capito... beh allora continuo comunque a leggere l'HOWTO perche' mi
interessa moltissimo imparare come si usa... In effetti penso che gli omini
in grigio si incacchierebbero non poco con me vedendo che mando loro dei
deficienti che vogliono usarli come relay per IRC..


 w, who, finger e co. bella non riportino nulla :) perche' avranno toccato
Mmmh deve essere una situazione non proprio semplice... spero proprio di non
trovarmici :-) Penso che alla fine uno faccia prima ad usare i backup di /home
e ripristinare tutto dopo aver reinstallato tutto from scratch :)


 deficienti che vogliono usarli come relay per IRC..
ehehehe credo anche io :)


 e ripristinare tutto dopo aver reinstallato tutto from scratch :)
purtroppo e' quello che bisogna fare a volte dopo taluni break-in :O ....
d'altronde e' la immediata reperibilita' di tools e rootkit a dare la
possibilita' anche ad illitterati di unix di nascondersi un minimo ...


 ehehehe credo anche io :)
Non ci metterebbero molto a venirmi ad offrire un paio di braccialetti :)


 possibilita' anche ad illitterati di unix di nascondersi un minimo ...
Beh si ma sicuramente non alla stessa portata degli ignoranti pseudo-sysadmin
che si trovano sui sistemi della nota casa :-)


legali e mostrabili coi suddetti binari per discriminare ...
Ma non si puo' fare un programma che calcoli i checksum dei programmi
in /bin e /sbin e li controlli ad ogni avvio ?!?
... ci stavo pensando ... e stavo pensando che forse si potrebbe
fare qualcosina per rilevare quell'aggeggio che mi hai mandato
per posta che va a modificare la testata degli ELF :-)

in /bin e /sbin e li controlli ad ogni avvio ?!?
Si chiama tripwire, ma ci sono anche alternative migliori.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

Si chiama tripwire, ma ci sono anche alternative migliori.
Potresti indicarne alcune dato che volevo provare tripwire, ma in questo caso
vorrei sapere anche le alternative.
Grazie mille da Obe.

 per posta che va a modificare la testata degli ELF :-)
probabilmente si. concettualmente di sicuro. :)



sotto debian c'e' debsum
-- 
Andrea Fanfani
and...@toglimi.linux.it
"togliere toglimi per il reply"

esser state modificate.
E allora o il kernel o le librerie risulteranno modificate. Per altro,
in un sistema davvero cattivo, root non puo' modificare files binari e
non puo' scrivere su mezzo sistema, tranne che in single user mode con
tutte le interfacce di rete disattivate.
Leonardo
".signature": bad command or file name

vorrei sapere anche le alternative.
Non ricordo, cerca negli archivi di bugtraq.


 tutte le interfacce di rete disattivate.
vedi sopra. unix si usa molto in due campi : in uno almeno, quello del
sistema ad ELEVATO numero di utenti, spesso root non fa capo ad una
persona sola e non puo' permettersi di dover gestire accesso fisico a
binari e dir in single mode ....
nei sistemi davvero cattivi :) root o chi per esso non puo' fare tutto
come invece in unix ....


e non parliamo di dove tale db vada messo, vero ? :)
Su un floppy protetto in scrittura avvitato dentro il case, ovvio!


 Su un floppy protetto in scrittura avvitato dentro il case, ovvio!
bellino, ma non duraturo :) (esperienza personale :O) .... oggi uso
proficuamente (spero ancora per un po') un cdrom non riscrivibile in un
lettore ATAPI inserito in baia estraibile :)
