Newsgroup: it.comp.sicurezza.varie
Titolo: [X-Post] cos'è un TCP ACK PSH?

Ciao a tutti! Bloccate pure il cross-post se lo ritenete necessario :)
TCP ACK PUSH, da quello che ho trovato su google...
In particolare Push sembra essere un flag tcp, anche se non ho capito
bene quale sia la sua funzione...
Sta di fatto che un Watchguard SOHO|tc che sta da un mio cliente si
rifiuta di far passare questo tipo di pacchetto che gli arriva da una
connessione Terminal Services con un server remoto.
per la cronaca, eccovi la riga di logging del firewall:
discard from <IP ESTERNO> port 3389 to <IP INTERNO> port 29410 TCP ACK
PSH (default)
a parte la regola di default che sto cercando di capire cos'è dal
forum del produttore, <IP esterno> è l'IP pubblico al quale era stata
inviata la richiesta (che sul firewall di destinazione - stesso
modello - viene accettata) e <IP interno> è l'indirizzo dell'host che
contiene la tabella di routing per il nat sulla rete interna.
dettagli dei firewall: SOHO|tc 6 con firmware 6.1.43
Qualche idea a proposito?
Grazie a tutti!
--
Ciao!
Davide
[DAOC PG]Armorgod Troll Sciamano - Midgard Vortigern[/DAOC PG]

 bene quale sia la sua funzione...
Transmission Control Protocol
Functional Specification
The Communication of Urgent Information
  The objective of the TCP urgent mechanism is to allow the sending user
  to stimulate the receiving user to accept some urgent data and to
  permit the receiving TCP to indicate to the receiving user when all
  the currently known urgent data has been received by the user.
  This mechanism permits a point in the data stream to be designated as
  the end of urgent information.  Whenever this point is in advance of
  the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
  must tell the user to go into "urgent mode"; when the receive sequence
  number catches up to the urgent pointer, the TCP must tell user to go
  into "normal mode".  If the urgent pointer is updated while the user
  is in "urgent mode", the update will be invisible to the user.
  The method employs a urgent field which is carried in all segments
  transmitted.  The URG control flag indicates that the urgent field is
  meaningful and must be added to the segment sequence number to yield
  the urgent pointer.  The absence of this flag indicates that there is
  no urgent data outstanding.
  To send an urgent indication the user must also send at least one data
  octet.  If the sending user also indicates a push, timely delivery of
  the urgent information to the destination process is enhanced.
RFC:793.
Sul resto, purtroppo, non ti posso aiutare.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

 bene quale sia la sua funzione...
Rilevamento remoto di Sistema operativo, esiste un'implementazione di nmap a
tal proposito.
Trovi riferimento su queste url:
http://www.insecure.org/nmap/nmap-fingerprinting-article-it/stackf-4.html
http://www.insecure.org/nmap/nmap-fingerprinting-article-it/stackf-5.html
Un buon documento (una serie di slide) dall'università di Genova, spiega
alcune caratteristiche dei protocolli di trasporto (in particolare TCP)
http://www.reti.dist.unige.it/reti/lucidi/Reti_35.pdf
TCP utilizza i seguenti flag per indicare la successione delle priorita' e
degli arrivi:
URG Usato per indicare dati URGENTI (Bug di WinNuke).
ACK CONFERMA del PACHETTO RICEVUTO.
RST RESET della connessione.
SYN Sincronizzazione della sequenza con cui vengono inviati i pacchetti.
PSH I dati per l'applicazione sono urgenti
FIN CONCLUSIONE della sequenza di pacchetti.
Comunque il flag PSH indica al sistema destinatario che il pacchetto in
arrivo e' di carattere urgente per una determinata applicazione in ascolto
sulla porta presa di mira.
ian - Ivan At Network -
i...@altervista.org
--------------------------------
Inviato via 
http://usenet.libero.it

 Qualche idea a proposito?
No. Dovresti proprio vedere quale regola abbia causato questo evento.
Se il firewall di quel watchguard e' stateful anche al livello della
finestra tcp, puo' essere che si tratti di una ritrasmissione.
Fabio

finestra tcp, puo' essere che si tratti di una ritrasmissione.
A questo non avevo pensato... purtroppo se il pacchetto arrivasse a
destinazione almeno una volta non ci sarebbe questo problema :(
In compenso ho trovato altri problemi simili sul forum del produttore,
anche se purtroppo non c'è ancora la risposta al mio caso.
Grazie ugualmente :)
--
Ciao!
Davide


 linea) e disconnessione. 
Non e' che il firewall perde lo stato delle sessioni quando rimangono 
idle troppo a lungo? E' facile che su una sessione rdp, specialmente
se il client e' ridotto ad icona, non passi nulla per lungo tempo. Se
la sessione scade, ogni pacchetto inviato dal terminal server viene 
scartato dal firewall fino a che non passa di nuovo qualcosa nell'altra 
direzione (da cui la riga di log). Prova a verificare quale sia il time 
to live delle sessioni. Questo pero' non dovrebbe pregiudicare le 
prestazioni a livello di interattivita' e, quindi, non spiegherebbe 
entrambi i malfunzionamenti. I rallentamenti non potrebebro essere 
ausati da download e (soprattutto) upload di altri utenti/server che 
avvengono contemporaneamente alle sessioni rdp? Che so, l'invio di
grossi allegati di posta, ad esempio.
Fabio

grossi allegati di posta, ad esempio.
questa considerazione non è da scartare. E' anche vero che i client in
quella rete sono una decina :)
Grazie per ora, mi sei stato di grande aiuto :)



Dobbiamo usare la logica. Siamo su it.comp.sicuezza.varie e chiedono del
flag PSH su TCP ACK.
E' ovvio che la prima cosa a cui penso sia il rilevamento di OS, o no ?
So benissimo cosa sia PSH, ho chili di log che mostrano flag PSH su
pacchetti TCP destinati ad ogni tipo di applicazione, infatti dopo ho
scritto a cosa serve il flag PSH. (Forse non avevi gli occhiali ? :-)


 E' ovvio che la prima cosa a cui penso sia il rilevamento di OS, o no ?
Non esistono tecniche di fingerprinting che utilizzino i flag PSH e ACK.
Fabio

 client in quella rete sono una decina :)
Visto che sono cosi' pochi dovrebbe essere abbastanza semplice
lanciare un urlo ai colleghi nel momento del rallentamento e
chiedere cosa caz^Wdiamine stanno facendo. Nel caso fosse un
upload a pregiudicare l'interattivita' (casa probabile) dovresti
verificare se quel modello di firewall permette di configurare
delel discipline di accodamento del traffico piu' opportune.
Fabio

 non ci siano stati problemi di questo tipo)
Immagino che ipfstat sia per pf. Mi posteresti uno stralcio 
dell'output che sono curioso? Il plugin lo hai scritto tu? 
Fabio

E se il firewall si perdesse stati per strada?
[cut]
ormai non escludo più nulla :((
--
Ciao!
Davide


 
http://www.insecure.org/nmap/nmap-fingerprinting-article-it/stackf-5.html
Forse non usi un browser ?


delel discipline di accodamento del traffico piu' opportune.
Le complicazioni del caso sono generate proprio dal fatto che il
firewall sta da un cliente. Bisogna essere Parry Mason per capire come
stanno effettivamente le cose :)
Tuttavia ho già fatto diversi interventi per testare meglio il
problema che, purtroppo, incontro per la prima volta (ma qesto si era
capito :) ).


scritto a cosa serve il flag PSH.
Infatti il tuo plico l'ho salvato per una + attenta lettura in
seguito. :)
--
Ciao!
Davide



http://openit.disco.unimib.it/docs/colciago.pdf



Eh sě...
http://www.dia.uniroma3.it/~valecchi/general/attacchi_noti.htm
http://webtutor.unicam.it/sicurezza/Tesine/TesiIDS%20Ascoli.pdf
http://www.clavister.com/manuals/FWMan601a-ITA-000417.pdf


 ha scritto:

Di solito adoro che mi si contesti, perche' le critiche servono a
migliorarsi, ma forse tu non hai mai usato nmap, giusto ?
Port scanning
Un client si collega ad una porta su di un server remoto, invia un SYN, la
macchina remota risponde con un ACK, il client invia il suo ACK ed inizia la
trasmissione dati. Quindi fingerprinting con utilizzo del flag ACK.
Le due URL riguardo NMAP parlano di particolari tecniche di fingerprinting
con l'utilizzo di tutti i flag compreso PSH.
Mi spieghi come mai su 
insecure.org
 hanno commesso questo errore madornale
?(secondo le tue conoscenze).
Non mi dilungo per noia e per pigrizia.



Infatti spesso si utilizza il flag PSH per testare FW, leggi il pdf di
Colgiago, una tesi straordinaria sui firewall e IDS.


 
http://openit.disco.unimib.it/docs/colciago.pdf
Scusa, ma in questi link non trovo assolutamente nulla di pertinente.
Se ritieni che ci siano dei passi inerenti al fingerprinting attivo
con traffico avente le caratteristiche di quello postato da Davide ti
chiederei di indicarmi i punti esatti in cui si trova in questi doc,
visto che sono molto interessato al fingerprinting degli stack tcp/ip.
Fabio

 Quindi fingerprinting con utilizzo del flag ACK.
Forse non ci intendiamo sul significato di fingerprinting.
Fabio

 Non mi dilungo per noia e per pigrizia.
e' altro, credimi.
-- 
HappyCactus - Linux User #209744 - 
http://pngstego.sourceforge.net
 
 
www.google.com
 - 
groups.google.com
/* Ci sono 10 categorie di persone al mondo: quelle che capiscono */
/* il sistema binario e quelle che non lo capiscono.              */

> leggi il pdf di Colgiago, una tesi straordinaria sui firewall e IDS.
                                                                  ^^^
Si, mi ricordo.
http://www.google.it/groups?threadm=bhAw9.104881%24%25M1.2671605%
40twister2.libero.it
L'ho letta nell'intervallo di pranzo. Contiene alcuni errori, come 
avrai sicuramente notato anche tu, alcuni su parti non irrilevanti 
dell'argomento trattato. Le considerazioni personali sono un po' 
semplicistiche, non trovi? Tra l'altro non fornisce le definizioni 
degli oggetti di cui parla. Difficile, per esempio, interpretare i 
commenti sulla rilevabilita' delle tecniche presentate senza definire 
cosa intende per IDS. Alcuni termini vengono utilizzati in modo 
improprio. Avrebbe potuto rendere merito, o maggior merito, agli autori 
di alcune tecniche o tool, specie se italiani. La bibliografia IMHO 
lascia molto a desiderare. Direi una lettura da newbie, nel complesso. 
Noto due grandi assenti: il fingerprinting e gli IDS. Entrambi citati
qua e la, ma mai trattati.
Fabio

 ... ommmioddio :-( Dimmi che hai sbagliato a scrivere, ti prego.
Se vuoi posso scendere nello specifico della creazione di una connessione
TCP, lo volevo evitare, per mancanza di voglia e di tempo
macchina 1 manda un SYN pari a 1 e un ACK pari a 0 - macchina 2 risponde con
un SYN pari a 1 e un ACK pari a 1
macchina 1 replica con SYN pari a 0 e ACK pari a 1
bit ACK pari a 1 per tutta la trasmissione dati
Prima di chiudere la connessione macchina 1 invia un FIN pari a 1 e ACK pari
a 1
macchina 2 risponde con ACK pari a 1
Fine della trasmisssione dati.
Il port scanning e il fingerprinting si basano anche su questa logica.
(anche, non 'solo')


 qua e la, ma mai trattati.
C'e' un suo documento, sempre sullo stesso server che tratta i due
argomenti.
Non trovo che la sua lettura sia tanto newbie, piuttosto e' la classica
tesi, quindi uno scritto di chi passa esclusivamente dal tunnel della teoria
universitaria.
Quello che studi durante le lezioni di "reti" non e' quasi mai applicabile
nella pratica se non nelle implementazioni dei vari protocolli, lo scopo di
quelle lezioni e' quasi esclusivamente orientato a darti un metodo, poi lo
skill devi creartelo da solo.


 Fine della trasmisssione dati.
15:08:15.223432 192.168.1.2.32897 > 192.168.1.1.21: . [tcp sum ok] ack
56 win 5840 <nop,nop,timestamp 2067206 43461551> (DF) (ttl 64, id 48351,
len 52) 
15:08:15.224956 192.168.1.1.21 > 192.168.1.2.32897: F [tcp sum
ok] 56:56(0) ack 6 win 16060 <nop,nop,timestamp 43461551 2067206> (DF)
(ttl 64, id 52184, len 52) 
15:08:15.248435 192.168.1.2.32897 > 192.168.1.1.21: F [tcp sum ok]
6:6(0) ack 57 win 5840<nop,nop,timestamp 2067209 43461551> (DF) (ttl 64,
id 48352, len 52) 
15:08:15.248535 192.168.1.1.21 > 192.168.1.2.32897: . [tcp sum ok] ack
7 win 16060 <nop,nop,timestamp 43461554 2067209> (DF)(ttl 64, id 52185,
len 52)
Cazzo, deve essersi rotto qualche cosa.
HappyCactus "chi sale in cattedra deve essere impeccabile".


 universitaria.
E' vero, ma questo giudizio si scontra con il termine <<straordinario>>
che hai utilizzato per esprimere il giudizio precedente. Direi che sia
piu' adeguato un giudizio tipo <<onorevole>>. Rimangono i marchiani 
errori, e mi stupisco che il professore e la commissione non se ne siano
accorti. Se diamo per scontata la loro competenza, non mi rimane che
considerare la cosa come l'ennesima prova che le tesi non vengono lette.
Fabio

 (anche, non 'solo')
Cosa intendi per fingerprintng? Per me il fingerprinting e' rilevare
il sistema operativo a cui appartiene uno stack tcp/ip.
Fabio

tutte le altre connessioni di procedere.
[cut]
ovvero se il firewall natta quello che è già stato nattato le
connessioni "established" realmente viste sono corrispondenti a 1, con
il caos generato di conseguenza...
Grazie a tutti :)


 il caos generato di conseguenza...
Dipende da come e' fatto il primo nat, ma darei per scontato che il
secondo veda tante sessioni quanti sono i lcient connessi. Per esempio, 
queste sono due connessioni allo stesso server ftp fatte da due macchine 
in lan conla porta sorgente forzata a 1035 sul lato client in entrambi i  
casi:
tcp      6 431941 ESTABLISHED src=<ip interno1> dst=<server> sport=1035 
dport=21 src=<server> dst=151.36.98.221 sport=21 dport=10
35 [ASSURED] use=1
tcp      6 431960 ESTABLISHED src=<ip interno2> dst=<server> sport=1035 
dport=21 src=<server> dst=151.36.98.221 sport=21 dport=10
24 [ASSURED] use=1
Netfilter ha usato la stessa porta src usata dal client per la prima 
connessione ma ha fatto un cambio di porta per la seconda, vedendo che
la porta era gia' in uso per la connessione a quel server. Questo e'
il comportamento corretto di un nat perche', altrimenti, non sarebbe
possibile per piu' macchine nattate connettersi allo stesso server: sul 
lato server le connessioni non sarebbero distinguibili e la seconda
verrebbe resettata al primo SYN. Darei per scontato che anche il tuo 
primo nat, pur non sapendo cosa sia, funzioni cosi'. Di conseguenza le 
sessioni sono tutte distinte da una porta sorgente diversa, quando viste 
dal secondo nat, e quindi il traffico di una non puo' influenzare 
l'altra. In particolare un RST o dei FIN su una non possono chiudere 
l'altra.
Fabio

 
http://www.clavister.com/manuals/FWMan601a-ITA-000417.pdf
Per ora, hai solo dimostrato di saper usare google. Pensavi anche di
leggerli i documenti che porti a sostegno di tesi (un po` scellerate,
diciamolo), con tanta "pompa"?
Perche` dal punto di vista di un osservatore casuale, pare che tu stia
accumulando figure su figure. E sondare in lungo e in largo il web,
forse non aiuta.
Serenamente, eh, non ti arrabbiare.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Microsoft - Just say No.

l'altra.
insomma il mio ragionamento è sbagliato :(
il nat più interno è gestito direttamente da un win2000 server mentre
il secondo dal firewall Watchguard SOHO. 


 il fingerprinting)
la so! ACK. Alcuni ignorano (perchè non ha senso), altri rispondono con 
RST. Almeno mi pare di ricordare una cosa del genere. Fino all'esame di 
Reti di Elaboratori, comunque, non sono tenuta a saperne niente, e dopo 
sarò tenuta a (e felice di) dimenticare tutto, quindi, eh, mannaggia, è 
tardissimo! /me si eclissa fischiettando
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.1. C, C++ and ASM developers
                               and beta testers are welcome!

 Vergognati!
lassa sta', che dovrò anche dare esami su NS e SNMP


RST. Almeno mi pare di ricordare una cosa del genere.
Si, ok per la teoria, ma la pratica.. mannaggia!
BTW ho scoperto l'arcano... sono pacchetti che manda terminal server
in presenza di connessioni "zombie" ovvero disconnesse e sostitute da
altre rinnovate (il perchè devo ancora scoprirlo).
Non ho ancora capito a cosa sono dovute le disconnessioni continue, ma
il problema comunque esula da questo newsgroup.
Grazie a tutti per il vostro aiuto :)


 wrote in message
news:MPG.1951728a2...@powernews.libero.it...


 questo msg
Potresti estrinsecare meglio questo pensiero? quotando, magari?


 wrote in message
news:20030618101611.78...@vene.ws...


 Non vedo perche'.

 ma mi impegno....posso quotare la mia stupidità in certe risposte??
quota quel che vuoi, basta che quoti.


 wrote in message
news:20030619133229.3d...@vene.ws...
