Newsgroup: it.comp.os.linux.sys
Titolo: nmap e kernel 2.4.0

[buttha: ~]$ uname -a
Linux deeptought 2.4.0 #2 ven gen 26 19:12:46 CET 2001 i686 unknown
[buttha: ~]$ nmap --version
nmap V. 2.54BETA7
[buttha: ~]$ nmap -O -p 80 localhost
Starting nmap V. 2.54BETA7 ( 
www.insecure.org/nmap/
 )
Warning:  OS detection will be MUCH less reliable because we did not
find at least 1 open and 1 closed TCP port
sendto in send_tcp_raw: sendto(3, packet, 60, 0, 127.0.0.1, 16) =>
Operazione non permessa
sendto in send_tcp_raw: sendto(3, packet, 60, 0, 127.0.0.1, 16) =>
Operazione non permessa
sendto in send_tcp_raw: sendto(3, packet, 60, 0, 127.0.0.1, 16) =>
Operazione non permessa
Interesting ports on localhost (127.0.0.1):
Port       State       Service
80/tcp     open        http                    
TCP Sequence Prediction: Class=random positive increments
                         Difficulty=1656481 (Good luck!)
No exact OS matches for host (test conditions non-ideal).
TCP/IP fingerprint:
SInfo(V=2.54BETA7%P=i686-pc-linux-gnu%D=2/8%Time=3A831062%O=80%C=-1)
TSeq(Class=RI%gcd=2%SI=1944BB)
TSeq(Class=RI%gcd=1%SI=328D75)
TSeq(Class=RI%gcd=2%SI=1946A1)
T1(Resp=Y%DF=Y%W=2D24%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=2D24%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=Y%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds
Stesso problema con queso:
[root: /home/buttha]# queso localhost
sending message: Operazione non permessa
127.0.0.1:80
	* Standard: Solaris 2.x, Linux 2.1.???, MacOS
Qualche idea?
Buttha
-- 
* Per rispondere in email rimuovere la prima i dall'indirizzo
* Noi vogliamo le vostre critiche, vogliamo ascoltare tutto cio' che
  volete dirci: che siano accuse, che siano proteste che siano grida... 
  non abbiate timore... parlate dopo il segnale acustico (C.Guzzanti)

 Qualche idea?
netfilter non gradisce il pacchetto
l'errore arriva dal net/ipv4/netfilter/ip_nat_standalone.c (75)
        /* Can't track?  Maybe out of memory: this would make NAT
           unreliable. */
        if (!ct) {
                if (net_ratelimit())
                        printk(KERN_DEBUG "NAT: %u dropping untracked
			       packet %p %u %u.%u.%u.%u -> %u.%u.%u.%u\n",
                               hooknum,
                               *pskb,
                               (*pskb)->nh.iph->protocol,
                               NIPQUAD((*pskb)->nh.iph->saddr),
                               NIPQUAD((*pskb)->nh.iph->daddr));
                return NF_DROP;
        }
come si vede il pacchetto viene scartato
si potrebbe cambiare il valore di return in NF_ACCEPT (il pacchetto
verrebbe accettato), ma non so quali potrebbero essere le contro
indicazioni
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Mi piace avere amici rispettabili;
Mi piace essere il peggiore della compagnia.

 Operazione non permessa
un errore simile me lo dava tempo fa, pero' non mi ricordo se 
avevo dimenticato qualcosa nel compilare il kernel o se avevo
problemi con la rete (ipchains? host*?)  
-- 
nebbia

 [snip]
Ho risolto in maniera drastica: ho disabilitato il connection tracking e
non uso piu' il modulo state di iptables.
Del resto, lo utilizzavo per conciliare una politica deny con l'utilizzo
di icq, ma il tutto portava a spiacevoli conseguenze... RELATED e' *molto*
pericoloso; una strategia di questo tipo:
iptables -A OUTPUT -o ppp+ -p tcp --source-port 1024: -m state --state
NEW -j ACCEPT
iptables -A OUTPUT -o ppp+ -p udp --source-port 1024: -m state --state
NEW -j ACCEPT
iptables -A INPUT -i ppp+ -m state --state ESTABLISHED,RELATED -j ACCEPT
porta a spiacevoli conseguenze.
Ad esempio, ero collegato via ssh ad una shell. Beh, a quel punto
provavo a telnettarmi a qualche porta del mio pc... potevo collegarmi a
qualsiasi porta, visto che l'IP della shell era gia' coinvolto in una
comunicazione instaurata con il mio pc, quindi rientrava nello state
RELATED.
A questo punto la cosa mi fa pensare (ma non ho verificato) che basta
parlare con qualcuno in ICQ (quindi connessione tra i due PC) ed
automaticamente quel qualcuno avra' accesso a tutto le porte del nostro
computer.
BTW, ora funziona tutto:
[root: /home/buttha]# nmap localhost -O -p 80,81
Starting nmap V. 2.54BETA7 ( 
www.insecure.org/nmap/
 )
Interesting ports on localhost (127.0.0.1):
(The 1 port scanned but not shown below is in state: closed)
Port       State       Service
80/tcp     open        http                    
TCP Sequence Prediction: Class=random positive increments
                         Difficulty=1005030 (Good luck!)
No exact OS matches for host (If you know what OS is running on it, see 
http://www.insecure.org/cgi-bin/nmap-submit.cgi
).
TCP/IP fingerprint:
SInfo(V=2.54BETA7%P=i686-pc-linux-gnu%D=2/10%Time=3A857DD8%O=80%C=81)
TSeq(Class=RI%gcd=1%SI=F5AEB)
TSeq(Class=RI%gcd=2%SI=7ACC2)
TSeq(Class=RI%gcd=1%SI=F55E6)
T1(Resp=Y%DF=Y%W=2D24%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=2D24%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=Y%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
Sě, vabbe': non ce la fa, perche' iplog fa lo sciocchino ;-)
hola
Buttha
-- 
* Per rispondere in email rimuovere la prima i dall'indirizzo
* Sottile come una lama ben affilata, ma profondo come un baratro, č il
  confine fra il semplice e il banale..

 computer.
mmmh, non penso... se non sbaglio c'e` sempre il server di mezzo, o no?
e poi icq usa pacchetti udp, quindi niente connessione (a dire il vero
non so come si comporti il modulo state in questi casi)
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
La teoria e' quando sappiamo come funzionano le cose ma non funzionano.
La pratica e' quando le cose funzionano ma non sappiamo perche'.
Abbiamo unito la teoria  e la pratica: le cose non funzionano piu' e non
sappiamo il perche'.

 modulo state in questi casi)
La connessione c'e', ed e' tcp.
hola
Buttha
-- 
* Per rispondere in email rimuovere la prima i dall'indirizzo
* Litighiamo così spesso. A volte mi chiedo perché mai ci siamo sposati, 
  anche se so benissimo il perché. E' la solita legge degli opposti che 
  si attraggono. Lei era incinta, e io no. (Daniele Luttazzi)

 writes:
Buttha> iptables -A OUTPUT -o ppp+ -p tcp --source-port 1024: -m state
Buttha> --state NEW -j ACCEPT iptables -A OUTPUT -o ppp+ -p udp
Buttha> --source-port 1024: -m state --state NEW -j ACCEPT iptables -A
Buttha> INPUT -i ppp+ -m state --state ESTABLISHED,RELATED -j ACCEPT
Ti crederei se non avessi le prove del contrario :-)
Ma la policy dell'INPUT è DROP o hai una riga di REJECT/DROP finale? e
hai provato la cosa in altri modi?
Buttha> porta a spiacevoli conseguenze.  Ad esempio, ero collegato via
Buttha> ssh ad una shell. Beh, a quel punto provavo a telnettarmi a
Buttha> qualche porta del mio pc... potevo collegarmi a qualsiasi
Buttha> porta, visto che l'IP della shell era gia' coinvolto in una
Buttha> comunicazione instaurata con il mio pc, quindi rientrava nello
Buttha> state RELATED.  A questo punto la cosa mi fa pensare (ma non
No, il RELATED ovviamente si applica solo a tutto ciò che è
_veramente_ relativo a quella connessione:
marco@aieie$ ssh XXX
...
marco@XXXX$ ssh IP-MIO
Secure connection to IP-MIO refused.
Dando un occhio ai sorgenti mi sembra di notare che l'unica
connessione permessa in senso opposto sia a il classico ftp-data di
ip_conntrack_ftp.
iptables -A ppp-in -m state --state RELATED,ESTABLISHED -j ACCEPT
....
iptables -A ppp-in -j REJECT # DROP per gli amici
Ciao
Marco

 La connessione c'e', ed e' tcp.
ok, ma il modulo state dovrebbe funzionare cosi`:
Io apro una connessione verso un'altro utente;
l'utente apre una connessione verso di me; il firewall capisce che non
e` una connessione nuova ma l'altra meta` di una connessione bi-di e
l'accetta.
Se questo stesso utente tenta una nuova connessione il firewall dovrebbe
bloccarlo, visto che questa non corrisponderebbe ad una gia` avviata
(il tutto ovviamente imho, il codice di netfilter l'ho letto solo a
sprazzi)
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Un apostolo vedendo Gesu' camminare sulle acque:
- Cazzo se e' buono 'sto fumo!!!

 Ma la policy dell'INPUT č DROP o hai una riga di REJECT/DROP finale?
Questo e' la configurazione che utilizzavo:
<---------------------------------->
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i ppp+ -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i ppp+ -p tcp --destination-port 23 -m state --state
NEW -j ACCEPT
iptables -A INPUT -i ppp+ -p tcp --destination-port 12345 -m state
--state NEW -j ACCEPT
iptables -A OUTPUT -o ppp+ -p tcp --source-port 1024: -m state --state
NEW -j ACCEPT
iptables -A OUTPUT -o ppp+ -p udp --source-port 1024: -m state --state
NEW -j ACCEPT
iptables -A OUTPUT -o ppp+ -p tcp --destination-port 22 -m state --state
NEW -j ACCEPT
iptables -A OUTPUT -o ppp+ -p icmp -j ACCEPT
iptables -A OUTPUT -o ppp+ -m state --state ESTABLISHED,RELATED -j
ACCEPT
<---------------------------------->
Questi i fatti:
se accedevo ad una shell (via ssh) e da questa shell mi telnettavo, per
esempio, alla porta 110 (aperta sul mio pc), iptables permetteva il
collegamento.
Se invece, provavo a farlo da una shell che non era correlata in alcun
modo a me (ssh verso una prima shell e da questa ssh verso una seconda
shell che, in questo modo, di RELATED non ha nulla) allora il tentativo
di collegamento veniva bloccato.
ciao
Buttha
-- 
* Per rispondere in email rimuovere la prima i dall'indirizzo


 writes:
[...]
Buttha> iptables -A INPUT -i ppp+ -p tcp --destination-port 12345 -m
Buttha> state --state NEW -j ACCEPT 
Sìsì.
Buttha> iptables -A OUTPUT -o ppp+ -p tcp --source-port 1024: -m state
Buttha> --state NEW -j ACCEPT
Buttha> iptables -A OUTPUT -o ppp+ -p udp --source-port 1024: -m state
Buttha> --state NEW -j ACCEPT
Buttha> iptables -A OUTPUT -o ppp+ -p tcp --destination-port 22 -m
Buttha> state --state NEW -j ACCEPT
Buttha> iptables -A OUTPUT -o ppp+ -p icmp -j ACCEPT iptables -A
Buttha> OUTPUT -o ppp+ -m state --state ESTABLISHED,RELATED -j ACCEPT
Boh, non vedo niente di strano. L'ho anche provate queste regole, ma
l'esito è contrario a quello da te riportato. Bisogna indagare ancora:
parametri del kernel? non c'è da dire molto.
Ho provato con variazioni sul tema, ma il risultato è lo stesso.
Tant'è che ho voluto/dovuto aprire auth "a mano"...
Ciao,
Marco

 parametri del kernel? non c'e` da dire molto.
potrebbe essere il Fast Switching compilato nel kernel
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"L'abilita' politica e' l'abilita' di prevedere quello che
 accadra' domani, la prossima settimana, il prossimo mese e
 l'anno prossimo. E di essere cosi' abili, piu' tardi,
 da spiegare  perche' non e' accaduto."

> ancora: parametri del kernel? non c'e` da dire molto.
Kronos> potrebbe essere il Fast Switching compilato nel kernel
Non il mio kernel.
Ciao
Marco

 Non il mio kernel.
no, quello di Buttha
Fast Switching e packet filtering non vanno d'accordo
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Il coraggio non mi manca.
E' la paura che mi frega...

 Fast Switching e packet filtering non vanno d'accordo
Non la trovo mica quell'opzione.
Sotto che voce di "make menuconfig" (o che nome ha nel file di
configurazione) questo settaggio?
hola
Buttha
-- 
* Per rispondere in email rimuovere la prima i dall'indirizzo
* Non prendete la vita troppo sul serio, comunque vada non ne uscirete
  vivi.

 configurazione) questo settaggio?
Networking options -> Fast Switching (terzultima opzione)
in .config e` CONFIG_NET_FASTROUTE
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Non sempre quello che viene dopo e' progresso.
Alessandro Manzoni

 in .config e` CONFIG_NET_FASTROUTE
La terzultima opzione che ho e' Appletalk protocol support.
Inoltre:
[root: /usr/src/linux]# grep CONFIG_NET_FASTROUTE buttha 
[root: /usr/src/linux]# grep FASTROUTE buttha
(buttha e' il mio file di configurazione)
In poche parole, il fastswitching non e' un'opzione del kernel che
utilizzo.
hola
Buttha
-- 
* Per rispondere in email rimuovere la prima i dall'indirizzo
* Un conto e' la malavita e i suoi sporchi affari e un conto e' lo
  stato: le sue responsabilita', la sua centralita' politica, sociale e
  morale. Mi faccia due fatture separate. (Corrado Guzzanti)