+ Reply to Thread
Results 1 to 5 of 5
  1. Member
    Join Date
    Aug 2012
    Location
    Toronto, ON
    Posts
    69

    Certifications
    RHCSA (RHEL6), CCENT, ITIL Foundations v3 (ITSM)
    #1

    Question Header manipulation attacks: Question about Wirekshark, transport & app layer

    I'm reading about 'Header manipulation attacks' and came across a statement which has me scratching my head. First I'm going to transcribe the statement and following that I have a few questions.



    What I read: "TCP/IP packages data into packets before sending them over a network. These packets have headers, which include different types of information depending on the header type. For example, TCP headers include port numbers to identify the protocol, and IP headers include source and destination IP address."

    The first thought that came to mind was, port numbers don't mean anything when it comes to identifying a protocol. I understand TCP headers include a port number but the part that really has me asking question is "to identify the protocol". The transport protocol is identified in the previous layer (IP) however the transport layer itself doesn't identify what to expect in the application layer protocol as far as I can tell. If I wanted, I could run a web server (http 1.1) on port 6667 so obviously we can't really depend on ports to identify an application layer protocol.



    1. Am I missing something, or is my understanding of things as explained above correct?

    2. Question about wireshark: The field 'hypertext transfer protocol' which is highlighted in blue, am I correct to assume that's Wireshark's analysis of what I'm looking at (and not an actual field) and everything else which is indented is what's actually found within that layer?

    3. I see there's a field which reads 'GET / HTTP/1.1\r\n'. I am aware of the fact that HTTP 2.0 also exists so I guess it's reasonable for web servers and web browsers to tell each other which protocol they're speaking. My question is, do applications ALWAYS have to tell each other what protocol/version they're talking? Considering the traffic is always guaranteed to go to the correct protoort (socket?), isn't it a bit redundant to always announce the application layer protocol and version of that protocol (unless I guess we're dealing with an application which has multiple
    versions of its protocol, such as http which has 1.1 and 2.0)


    TIA

    Attached Images Attached Images
    Last edited by phatrik; 08-07-2017 at 01:17 AM. Reason: Forgot to add the image
    2017 goals: Security+ (working on it)
    2018 goals: eJPT, CCNA R&S, RHCSA v7,
    2019 goals: RHCE v7, CCNA CyberOps, CSA+
    ????: OSCP || CISSP
    Reply With Quote Quote  

  2. SS -->
  3. Senior Member
    Join Date
    May 2016
    Location
    UK
    Posts
    118

    Certifications
    A+, Network+, Sec+
    #2
    Can't help you with 2 and 3. I'm not entirely sure I understand your question on number 1. TCP / UDP ports do identifiy the protocol. Sure things don't have to match up to well-known ports, but they should do most of the time right? In the case of firewalls if you add an allow rule for SMB traffic, its the packets with TCP 445 in TCP header that are going to be allowed through. At the same time when it comes to your own local machine the port numbers tell it which application that packet is meant for. Least this is my understanding of it all.
    Reply With Quote Quote  

  4. Darth Lord of the Sith ITSpectre's Avatar
    Join Date
    May 2016
    Location
    The Normandy/ DMV
    Posts
    997

    Certifications
    Sec+, MTA, MCP
    #3
    Good Question. I would like to see the responses to your question.
    In the darkest hour, there is always a way out - Eve ME3
    “The measure of an individual can be difficult to discern by actions alone.” – Thane Krios
    Reply With Quote Quote  

  5. Member
    Join Date
    Aug 2012
    Location
    Toronto, ON
    Posts
    69

    Certifications
    RHCSA (RHEL6), CCENT, ITIL Foundations v3 (ITSM)
    #4
    Quote Originally Posted by Nik 99 View Post
    Can't help you with 2 and 3. I'm not entirely sure I understand your question on number 1. TCP / UDP ports do identifiy the protocol. Sure things don't have to match up to well-known ports, but they should do most of the time right?

    What if I'm running my web server on a non-standard port? Look at the packet capture I posted (screenshot) pretend I'm running my webserver on port 4545 and ignore anything below [SEQ/ACK Analysis]. How could you tell it's the HTTP protocol?
    2017 goals: Security+ (working on it)
    2018 goals: eJPT, CCNA R&S, RHCSA v7,
    2019 goals: RHCE v7, CCNA CyberOps, CSA+
    ????: OSCP || CISSP
    Reply With Quote Quote  

  6. Senior Member
    Join Date
    May 2016
    Location
    UK
    Posts
    118

    Certifications
    A+, Network+, Sec+
    #5
    My current level of knowlegde says you can't identifiy it at that point. Theres a type field in the layer 2 header which identifies the layer 3 protocol (IPv4, IPv6, ARP) but aside from that if your running a random port instead of the well known theres no means to tell what protocol your running. I think at this point it becomes security through obscurity, if your hiding what applications your running on your server by hiding the protocol in use.

    Someone correct me if I'm wrong about any of this. Also to the best of my knowledge wouldn't you need to configure clients to use the alternate port to communicate with your server if you change what port it's listening on? Actually I've got a question now. If you forward port 80 to said web server using port 4545 for HTTP will that port info be passed along during the three way hand shake? If yes, would the client use the alternate port at that point till end of the session?
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks