OT: IPTABLES TCP/IP ip_conntrack Record

From: Mark Sargent (powderkeg_at_snow.email.ne.jp)
Date: 08/30/05

  • Next message: Fajar Priyanto: "Re: web files with ftp vsftpd" 
    Date: Tue, 30 Aug 2005 15:44:12 +0900
To: For users of Fedora Core releases <fedora-list@redhat.com>

    Hi All,

    am studying IPTABLES and am curious about this section,

    ****************************

    As you can see, it is really quite simple, seen from the user's point of
    view. However, looking at the whole construction from the kernel's point
    of view, it's a little more difficult. Let's look at an example.
    Consider exactly how the connection states change in the
    /proc/net/ip_conntrack table. The first state is reported upon receipt
    of the first SYN packet in a connection.

    tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
         dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
         dport=1031 use=1
       

    As you can see from the above entry, we have a precise state in which a
    SYN packet has been sent, (the SYN_SENT flag is set), and to which as
    yet no reply has been sent (witness the [UNREPLIED] flag). The next
    internal state will be reached when we see another packet in the other
    direction.

    tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
         dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
         use=1
       

    Now we have received a corresponding SYN/ACK in return. As soon as this
    packet has been received, the state changes once again, this time to
    SYN_RECV. SYN_RECV tells us that the original SYN was delivered
    correctly and that the SYN/ACK return packet also got through the
    firewall properly. Moreover, this connection tracking entry has now seen
    traffic in both directions and is hence considered as having been
    replied to. This is not explicit, but rather assumed, as was the
    [UNREPLIED] flag above. The final step will be reached once we have seen
    the final ACK in the 3-way handshake.

    tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
         sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
         sport=23 dport=1031 [ASSURED] use=1
       

    *************************

    In the 1st entry, the expected source ip and destination ip,

    src=192.168.1.35 dst=192.168.1.5

    are still the expected src dest ip in the 2nd entry, syn/ack entry.
    Shouldn't they be the other way round.? Perhaps I'm misunderstanding
    it.? My understanding, is, that the syn_sent packet orignates from
    192.168.1.5 and the syn_recv packet originates from 192.168.1.35, no.?
    Cheers.

    Mark Sargent. 

    -- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
  • Next message: Fajar Priyanto: "Re: web files with ftp vsftpd"

    Relevant Pages

    • Re: NATD and Address Redirection
      ... > There was a translation table inside libalias with 3 columns in it: ... > When a packet was heading outside, ... such an entry would clone into ... I didn't know the internals. ...
      (freebsd-hackers)
    • Re: NATD and Address Redirection
      ... > packets, you need to run 2 natd, using ipfw matching. ... their internals looked rather clear. ... When a packet was heading outside, ... If an entry were found, ...
      (freebsd-hackers)
    • Re: Intermittently Unable To Send Email
      ... > The last entry into the SMTP Log is 354 go ahead. ... Unfortunately that log entry may also mean that it has already sent ... The only way to know for sure is to take a packet ... In that case perhaps you have an MTU size issue to deal with. ...
      (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
    • Re: Securty logs
      ... >>> But if such computer give a flood attack, ... >>> create the same entry. ... > In the security log of the target machine it shows just one line. ... Each packet will generate a message, ...
      (FreeBSD-Security)
    • RE: Ambiguities in TCP/IP - firewall bypassing
      ... The flag combinations with that post relate to Linux 2.2.x and Windows ... If the firewall is just a simple packet filter that blocks incoming ... For example, sending a TCP ... design of firewalls and packet filters since an improper implementation ...
      (Bugtraq)