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 proto:port (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
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 proto:port (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
2018 goals: Security+, CCNA CyberOps (Cohort #6), eJPT, CCNA R&S 2019 goals: RHCE ????, OSCP || CISSP
Comments
-
Nik 99
Member Posts: 154 ■■■□□□□□□□
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. -
ITSpectre
Member Posts: 1,040 ■■■■□□□□□□
Good Question. I would like to see the responses to your question.In the darkest hour, there is always a way out - Eve ME3 :cool:
“The measure of an individual can be difficult to discern by actions alone.” – Thane Krios -
phatrik
Member Posts: 71 ■■□□□□□□□□
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?2018 goals: Security+, CCNA CyberOps (Cohort #6), eJPT, CCNA R&S 2019 goals: RHCE ????, OSCP || CISSP -
Nik 99
Member Posts: 154 ■■■□□□□□□□
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?