TCP Flags: Their use and abuse. - Page 3
Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: TCP Flags: Their use and abuse.

  1. #21
    Gotcha, thanks again. (Sorry Tiger, hope I didn't take the thread too far off topic, just had one those one question leads to another question leads to another kinda situation.) So the TCP/IP suite as a whole spans both network and transport layers, depending on which specific protocol you're looking at. I think that's what was throwing me. So what alternatives are there to the OSI model?

    This is all very helpful. With a MIS degree that included two LAN classes, I feel rather silly not having mastered this yet, but believe it or not we only scratched the surface of this concept in my classes. We went through all the layers and described the protocols, but that was pretty much it, nothing really in-depth. So, not only did I never really get it, but I forgot most of what I did grasp once the exam was over. But, that's what happens in a state where the entire public school system is declared unconstitutional (I kid you not!).

    I'm sure I'll have some more questions shortly, but now I'm off to read my next tutorial...

  2. #22
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,429
    There is no real alternative to the OSI model, afaik. The only thing that comes close is the out-dated DOD Model.

  3. #23
    Senior Member
    Join Date
    Mar 2004
    Posts
    113
    Hi ,

    Even I am not an expert to these topics , but I think that the TCP/IP is a protocol suite , which give info about TCP and other protocols, These protocols operate at different layers of OSI model like everyone said TCP at the transport layer , IP is at the network layer, UDP again at the transport layer, similarly there are other protocols (like FTP , Telnet, HTTP) which are at the presentation layer .so what i am thinking is these protocols are a part of the OSI model, and are integrated, and hence I feel that there is no alternative to OSI model.

    MRG.

  4. #24
    Ok, and I think I may have seen that before too, Neg. Caco's saying "if looking at it from OSI persective" seemed to suggest there was an alternative. Well I think it's sinking in now, thanks.

    /edit -- DANG, I just now gathered all those tuts into one stack, and it's about half-an inch tall! (All AO tuts and SecurityFocus articles.) And they say AO doesn't have good material anymore...

  5. #25
    Ok, back with another question, and this time I'm trying tie things back in to security. The command line "ping" is an ICMP tool that sends an ICMP_ECHO datagram to another computer, right? So, what I'm gathering from hoddebub's tutorial (recently posted) is that this can be a bad thing. Basically you want to block ICMP_ECHO requests at your firewall then -- is that on the right track?

    Furthermore, I'm concluding that pinging a machine (or using nmap, various linux scanners, etc.) not only acts via SYN/ACKs, but also on the ICMP level, correct? This all ties neatly into one nice package of thought, I'm hoping... I'm trying to connect all of this together as a whole now that I'm getting the specific concepts on their own.

  6. #26
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,429
    Ping indeed is an ICMP echo-request. It can be a bad thing (ping flood,... as explained by hobbdebub), but usually there's nothing wrong with allowing your network to be pinged. If you turn it off, you'll loose the main value of echo-request: testing your own network.

    ICMP though uses IP, and is connectionless. Read: no Syn/acks. If an echo-request is sent, the target is supposed to send the echo back unaltered (sequence numbers + data).

  7. #27
    Senior Member
    Join Date
    Nov 2001
    Posts
    4,786
    "If an echo-request is sent, the target is supposed to send the echo back unaltered (sequence numbers + data)."

    like ATHO+++ which means nothing on a network but came be a pain in the can for those with certain AOpen products (and a few others) </vague statement>
    Bukhari:V3B48N826 “The Prophet said, ‘Isn’t the witness of a woman equal to half of that of a man?’ The women said, ‘Yes.’ He said, ‘This is because of the deficiency of a woman’s mind.’”

  8. #28
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    IMO, ICMP Echo_Request should be dropped at the firewall when they are inbound. You should allow them at the border router, (prior to the firewall), so that you can remotely check connectivity of the inbound T1 or whatever.

    ICMP Time_Expired should be blocked outbound, (if possible on the firewall you use), to prevent use of a TCP SYN with the appropriately crafted TTL if you use internal routers to send valid requests to servers within the DMZ or even to the trusted network. If the connection passes the border router and is direct to the server then blocking the timeout response is redundant.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  9. #29
    Member
    Join Date
    Jun 2004
    Posts
    37
    "If an echo-request is sent, the target is supposed to send the echo back unaltered (sequence numbers + data)."

    I'd like to add to that for the people that might get these confused if you're brand new to this, ICMP Sequence Numbers are completely different than that of TCP Sequence Numbers. ICMP Seq #'s are used in matching requests with replies... not in synchronizing TCP connections.

    I'd also like to add that TCP's Flag control bit 'PSH' (Push) wasn't covered as much (imo) as it could have been. PSH, when set, flushes any data buffered inside the sender OR receiver's queues then hands it to the application. This was established by the thread so far for the most part, however, many might not know the rest. The PSH bit is requested by the sending application (client) and isn't generated by TCP itself. PSH also prevents 'deadlock' and is only set when the client sends the last Byte of a complete request (for requests larger than the MSS multiple ACKS are requested inside the stream until the PSH/ACK is sent telling the app to push all the previous ACK datagrams including it's self [PSH/ACK] to the application.) If the segments don't total over the Max-Segment Size {MSS} (1460 Bytes for ethernet LAN tranmission & up to 65,495 Bytes for WAN connections) then no fragmentation needs to occur and the request can be sent as 1 whole datagram with the PSH/ACK rather than several ACKS that would conclude with a PSH/ACK (if fragmentation needs to occur in that scenario).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •