RE: [Non-intrusion Q] Is this normal FTP and TCP"underneath it" behavior?
"Bill Royds" <[email protected]>
| Newsgroups | gmane.comp.security.intrusions |
|---|---|
| Message-ID | <[email protected]> |
Remember that in standard FTP (not passive with PASV), the data connection is initiated by the server with the FTP client as listener (reversing the standard client-server relationship). So what you are seeing is the server (as client in the data connection) sending the reset saying it is out of synch and your client (as server) agreeing with indication of last data received (or sent). -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stef Sent: Saturday, September 18, 2004 12:48 PM To: Intrusions List (GCIA Practicals) Subject: [Intrusions] [Non-intrusion Q] Is this normal FTP and TCP"underneath it" behavior? This is a non-intrusion question, which, though, I have thought of being worth debating with you - TCP/IP gurus. I have an odd behavior of an FTP server-client communication, which I call "odd" because I have not found anything in the RFCs I tried, or in Steven's book, explaining the following: - in a scheduled (every hour) ftp "conversation" between a client and a server (which conversation consists in a simple upload and download of some files, each one taking approximately 2 minutes), every once in a while such a session fails with the following last packets: server --> client packet: flags: RST, ACK=0 (! - the ACK in those RSTs is always 0) client --> server packet: flags: RST(!!! -as if there is a standard to force a RST from the client, in response to a RST from server?!?) and SEQ = "number", ACK = "number" (!! - the ACK in the client "reply" RSTs is always equal to its own sequence number, and not related to the SEQ of the server) NOTE1: the above is always happening over the data connections (never over the control one) NOTE2: normal traffic ends ... well, normally: FIN --> ACK --> FIN --> ACK Could anyone tell me what they think of this, or point me to the place where the above may be explained?!? TIA, Stef _______________________________________________ Intrusions mailing list [email protected] http://www.dshield.org/mailman/listinfo/intrusions _______________________________________________ Intrusions mailing list [email protected] http://www.dshield.org/mailman/listinfo/intrusions