Newsgroup: it.comp.reti.ip-admin
Titolo: sapete interpretare questo log di iptables?

iptables sul firewall in dmz mi logga una discreta quantitï¿œ di attivitï¿œ 
del tipo che vi riporto sotto (dalle quali ho eliminato la mia porzione 
di MAC per tutela).
il log viene tracciato dalla catena INPUT per protocollo TCP con porta 
diversa da 80.
sono da 5 (di notte) a 15(di giorno) righe all'ora
inizialmente mi sembrava una attivitï¿œ di sniffing ma non sono tranquillo 
di essere in al sicuro (non vorrei aver sbagliato qualcosa nella 
configurazione del firewall)
sulla macchina risiedono apache php mysql e ha un'interfaccia di rete 
sulla rete locale (al momento senza forward) sulla quale  php interroga 
una database su un server interno
la mia paura ï¿œ che da fuori qualcuno veda delle risposte che io credo di 
aver droppato; e che si tratti in realtï¿œ sempre dello stesso che camuffa 
l'ip.
voi che dite?
Oct 27 04:06:53
kernel:	[647881.964964]
IN=eth2
OUT=
MAC=....00:03:6f:e0:8b:24:08:00
SRC=110.9.129.72
DST=192.168.0.2
LEN=60	TOS=0x00
PREC=0x00
TTL=51
ID=58065
DF
PROTO=TCP
SPT=37576
DPT=21
WINDOW=5840
RES=0x00
SYN
URGP=0																																																																				 
 
 
 
 
 
 
 
 
 
 
 
 
 
Oct 27 04:21:18
kernel:	[648745.427531]
IN=eth2
OUT=
MAC=....00:03:6f:e0:8b:24:08:00
SRC=118.123.5.224
DST=192.168.0.2
LEN=40
TOS=0x00
PREC=0x00
TTL=104
ID=256
PROTO=TCP
SPT=6000
DPT=9415
WINDOW=16384
RES=0x00
SYN
URGP=0

 URGP=0
IP cinese che cerca di contattare la tua porta 9415.
Cosa si aspettino di trovarci non ï¿œ dato sapere
L'uso di porta sorgente 6000 pare correlare a questo:
http://isc.sans.edu/diary.html?storyid=7924
E in linea di massima, puoi correlare la riga rossa di questo...
http://isc.sans.edu/port.html?port=6000
...con la riga verde di questo...
http://isc.sans.edu/port.html?port=9415
In pratica, stai vedendo una piccola parte del "rumore di fondo" dello
spazio IPv4...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

grazie skull.
 > In pratica, stai vedendo una piccola parte del "rumore di fondo" dello
 > spazio IPv4...
quindi mi viene da pensare che sto registrando nei log un eccesso di 
roba innoqua. forse devo raffinare meglio le regole di LOG per evitare 
di ritrovarmi una riga importante dentro ad un milione di righe inutili.
una curiositï¿œ: il MAC che mi viene indicato ï¿œ sempre lo stesso i primi 6 
byte sono quelli della mia scheda, poi ci sono 8 byte sempre uguali che 
non sembrano appartenere alla mia macchina; ï¿œ possibile che sia 
l'interfaccia router del provider? ndr:fastweb. in questo caso non vedrï¿œ 
mai il mac dell'interfaccia che genera quel rumore.
ciao


 mai il mac dell'interfaccia che genera quel rumore.
Il mac-address ï¿œ una componente di layer 2, ovvero ha un senso solamente
all'interno della *singola* rete.
Un router ï¿œ quel "coso" che collega una rete ad altre (in questo caso ad
Internet): tutto il traffico che invii/ricevi con queste ultime avviene
-nella tua rete- tra la tua macchina e il router in questione.
Il tuo gateway poi provvederï¿œ a mantenere analoghe comunicazioni con
altri router, dialogando con essi attraverso il *suo* mac-address.
E nemmeno con quello che vedi tu: il mac-address ï¿œ proprio della singola
interfaccia di rete e userï¿œ pertanto quello dell'interfaccia che lo
collega questi altri gateway, che non ï¿œ la stessa che lo collega a te[1].
[1] questa ï¿œ una semplificazione: non tutte le tipologie di connessione
hanno qualcosa che assomigli al concetto di mac-address...


quindi se c'ï¿œ un "appestato" che si mette a fare una serie di richieste 
mascherando di volta in volta l'IP (si puï¿œ fare no?) non ho modo di 
identificarne le varie richieste come provenienti dalla medesima 
sorgente analizzando i pacchetti nei livelli di rete e di trasporto?
comunque per ora mi tranquillizzo (ho droppato tutto eccetto TCP80) 
quando dovro aprirmi ssh vedrï¿œ di perfezionare un po la sicurezza.


 comunque per ora mi tranquillizzo (ho droppato tutto eccetto TCP80)
Che ï¿œ la porta piï¿œ pericolosa :-P
Il 90% dei "buchi diretti"[1] su server, di questi tempi, avviene
giusto-giusto di lï¿œ, per tramite di applicazioni web insicure.
Aver bloccato tutto il resto via iptables aiuta poco...
[1] nel senso che una parte ancor piï¿œ grande ï¿œ il "buco indiretto",
ovvero accedendo ai server sfruttando credenziali raccattate dopo aver
bucato il client che le usava lecitamente.
Cfr: 
http://bit.ly/deAozj


ho letto il tuo articolo sul blog.
se non ho capito male, perï¿œ, non ï¿œ sulla porta 80. Per fare danni deve 
connettersi alla 21 (che ho droppato).


 connettersi alla 21 (che ho droppato).
Se gli utenti accedono in FTP, vero.
Se accedono via webdav...
Il senso ï¿œ: "ho tutte le porte chiuse tranne X" non ï¿œ necessariamente
segnale di una sicurezza ottimale.
Ci sono parecchi altri fattori, dalla presenza di SW insicuro nell'unica
porta aperta agli possibilitï¿œ accessi "indebitamente autorizzati", come
il caso di quell'articolo.
Bloccare via packet-filter una porta che -magari- ï¿œ giï¿œ chiusa in quanto
non c'ï¿œ SW in ascolto, non aggiunge sostanzialmente nulla...


 nulla...
anche se ti ripara "la schiena" nel caso in cui venga avviata (da
te o ... chi altri <g>) un'applicazione che si metta in ascolto su tale
porta; a quel punto avendo una regola di filtraggio la porta sar�
comunque non raggiungibile dall'esterno