When doing a network scan using for example NMAP with its "-A" option, what layer of the OSI model does it work on?
For reference, this is the description of the "-A" option:
-A : "Enable OS detection, version detection, script scanning, and traceroute"
The OSI model is a theoretical model with 7 layers; there are lots of resources out there describing which layers map to actual protocol layers in various network stacks, so I won't get into that. Instead, I'll give you the breakdown of what happens at each layer of the TCP/IP stack, which has 5 layers.
Physical layer. Nmap unavoidably uses this layer, though it is not usually concerned with it. It doesn't matter if you are using Cat 5 cable, 2.4 GHz radio, or coaxial cable—you can't use a network without having a physical layer. Nmap has no idea what it is, either; the firmware in your network card handles that.
Data link layer. Here again, Nmap has to use this layer or nothing gets sent to the destination. But there are some cases where Nmap is aware of what layer-2 protocols are in use. These all require root privileges to work:
On Windows, Nmap can't send raw IP packets (more on this in the next layer), so it falls back to sending raw Ethernet (layer 2) frames instead. This means that it can only work on Ethernet-like data links—WiFi is fine, but PPTP doesn't work.
There are some NSE scripts that probe layer-2 protocols: lltd-discovery, broadcast-ospf2-discovery, sniffer-detect, etc.
If the target is on the same data link, Nmap will use ARP to determine if the IP address is responsive. It will then report the MAC address of the target. For IPv6 targets, Neighbor Discovery packets are used instead.
Network layer. Nmap supports both IPv4 and IPv6 network layer protocols. For port scans (except -sT TCP Connect scan), Nmap builds the network packet itself and sends it out directly, bypassing the OS's network stack. This is also where --traceroute happens, by sending packets with varying small Time To Live (TTL) values to determine the address where each one expires. Finally, part of the input into OS detection comes from the network layer: initial TTL values, IP ID analysis, ICMP handling, etc.
Transport layer. This is where the "port scanner" core of Nmap works. A port is a transport layer address; some of them may be used by services on the target ("open" ports), and others may be unused ("closed" ports). Nmap can scan 3 different transport layers protocols: TCP, UDP, and SCTP. The majority of inputs to OS detection come from here: TCP options, sequence number analysis, window size, etc.
Application layer. This is where version detection (-sV) takes over, sending various strings of data (probes) to open services to get them to respond in unique ways. SSL/TLS is handled specially, since other services may be layered over it (in which case it provides something like an OSI Session Layer). This is also where the vast majority of NSE scripts do their work, probing services like HTTP, FTP, SSH, RDP, and SMB.
All of them? If you're asking for some sort of course, I'll leave it to you to turn this into something that answers your questions and instead focus on thinking about what's going on.
Obviously layer 1 packets are sent, but nmap isn't really aware of them
When on the same local network, nmap pays attention to MAC addresses and ARP. This helps with vendor detection, as well as giving you network distance information
layer 3 (network layer) is used for sending packets, for detecting whether the host is up.
the transport layer (layer 4) is used for things like SYN scans, and to detect which ports are open. Sequence number detection, which happens at layer 4 is important to OS detection.
Mapping OSI layers 5 and 6 session and the one I can never remember to the TCP/IP protocol stack is complex. I leave that to a long paper I'm not going to write.
layer 7(application) is involved in the scripts and in doing things like collecting info about websites. If you think HTTP is layer 6 rather than 7 (a valid world model), then some of that happens at layer 6.
As you can see, this really isn't very clear.
The -A option seems to do a few things. Since it seems to be doing TCP/UDP port detection as well as traceroute (which is ICMP) (see man nmap for more info), I would say that includes the Transport Layer as well as the Network Layer. As it seems to be checking versions of server software running, there's a good chance it's also on the Application Layer.
Related
So lets say I have a laptop which connects through a Wireless Access Point which is then connected to a router.
I'm trying to figure out if this happens as a result of an ARP response using the MAC address or, if the laptop uses the IP address to find the router. I know most models have switches built into them so lets negate that for this.
Does that mean that the laptop explicitly uses the IP address to find the router and will only use the MAC address if it needs to traverse through a switch somewhere else in the topology?
Thanks in advance. This is quite a difficult topic to find information on.
First lets rewrite your question to:
Question 1: How does a wireless lan (WiFi) connection differ from a wired connection?
Question 2: Does a WiFi connection transmit data directly to the router's IP, or does it uses the MAC address?
Question 3: Does a Laptop forward PDU's into the router through the wireless access point? does it than use the IP or MAC?
Assumption, PDU refers to Protocol Data Unit
Awnser question 1:
To understand how WIFI works, we first need to understand how a Wired network works. For this we use the OSI model.
The PDU for each of the 7 layers in the model is different and dependent on what that layer represent.
Layer 1 (Physical) is all about electrical signals, Frequencies, voltages, amplitudes and the likes. it defines how we transmit the data down a wire (or through the ether), in this layer there is no network. All communication is from node to node
(so like
"switch <=> switch"
"switch <=> Accesspoint"
"Accesspoint <=> Laptop"
Etcetera
)
This layer does not (normally) have any security or encryption.
Layer 2 (Data Link) is the layer were we start to get a network.
In this layer we start to see structures in the data (the PDU's are called frames) and we get addresses (MAC) Data can now only travel within this physical network (also known as subnet). Encryption is possible but not often implemented outside of the Enterprise networks.
Layer 3 (Network) is where we start to really get interesting. We have all the parts now to build networks and networks of networks (internet).
This layer's PDU is called a packet and its address is an IP address.
From this point on we can make connections that span over multiple hops though different networks with the so called routing scheme's.
Now to WiFi has the following changes to this standard model:
Layer 1: this is wireless (through the ether) so we get channels, bands, frequency and interference. It means that besides how to encode the bits we also have to dial a transceiver. to facilitate this there is a mechanism that uses names for humans to identify networks (SSID).
also because normally we do not have encryption anyone could just see all your data , WiFi adds an encryption scheme to this layer to ensure only authorized devices can communicate on it. (WPA for example)
Answer question 2:
WiFI is on layer 1, so it does not connected to anything but what is directly connected to itself (ergo WiFi is only on the ether), the router is on a different connection. We need at least layer 2 to communicate with it (using MAC addresses) or if we want to send data to other networks we need at least layer 3 and an IP address.
Answer question 3:
Well, for data to be transmitted to other networks (a router connects at least 2 networks) we need layer 3 and an IP address. so the only way your laptop can transmit data like this we use IP addresses.
Footnote:
To learn more about all this you could capture the data transmitted in your own network (DO not capture data on other people there network this is often illegal consult your local law proffesional!). To capture this data Wireshark is a great tool. you can see all this in action in it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I always hear about the layers of internet and i vaguely understand this. But, what confuse me most is that transport layer (including TCP protocol) lies on top of the internet layer(including IP protocol)..
What does this mean? For one who has a foggy understanding of the internet mechanism (I'm not a CS student or something I am just a hobby programmer)
The picture I have about the internet is that the network card sends/receives signals (packets) from the internet through wired connection / wifi then the OS using socket API sends/receives these packets acting as a layer between the hardware and the application which in turn uses some high-level protocol such as HTTP to interpret the data transferred - these protocol usually provided by languages e.g. python or java
.. I guess then that IP and TCP protocol are used at the level of the socket API? but I need more details ? I hope the explanation be in terms of coding/programming/implementation because abstractions used in this area confuse me.
Thank you , and sorry for my bad English
This is part of a layered solution to solve networking. Each layer has its own functionality:
IP (Internet Protocol) is in charge of delivering a packet (or datagram) from one interface, in one machine, with an IP address assigned to another interface in the same or other machine (node). Both nodes can be in the same LAN or different LAN connected through different paths (LAN's and routers). Basically it will make the packet get from source IP to destination IP. It provides a best-effort services, it doesn't assure the IP packet is going to arrive, it can be lost in the middle.
Above layer 3 or IP in the so-called TCP/IP stack, there is the transport layer. Its main functionality is to multiplex the lower layer (IP) service (take a packet from src to dst) among different applications. This is why in all transport layer protocols there is the concept of port or more generically Transport Service Access Point (TSAP). UDP, TCP, SCTP do that. UDP provides an unreliable service to the application. TCP provides a connected, reliable transport service to the application. This layer will make a message sent from application A in node Y reach application A1 in node Z, either reliably or unreliably (while IP only takes care of carrying the packet from node Y to node Z).
You will need to read a little about the OSI layered model and the TCP/IP layered model.
If you need to get more info I can address you to a training I have about IPv6 with a good introduction to networking: http://www.slideshare.net/rodolk/networking-tcpip-stack-introduction-ipv6
TCP is a protocol, known as "Transmission Control Protocol" - by specification it has features in place which makes sure that transmitted data is checked. On the other hand, there are things such as UDP, aka "User Datagram Protocol" which also works on top of IP - by specification this method does not check any transmitted data, so it's less useful where files must be fully intact (more utilised for video streaming, where some lost frames is acceptable, as opposed to binary file transfers where incorrect data means corruption and the whole file would be useless).
On to IP, IP is an addressing protocol, allowing a network to address and communicate with any machine that lives within it. IP stands for Internet Protocol, and it defines the fundamental way that two machines communicate over the "internet". It does not define how communications are handled, in ways such as being checked for data integrity, etc.
So, to summarise, the TCP and UDP are just extensions of IP. It is entirely possible, however, to have a socket based TCP or UDP connection, and I expect it's also possible to have some sort of MAC address protocol (as opposed to an IP address protocol). I don't know of any protocols which are similar to IP, but I imagine they do exist. In reality, using TCP over something other than IP is entirely unlikely. If you're going to the effort to create a custom protocol, chances are you'll want it fully custom and won't want to stick to design specifications designed for another protocol layer.
Note that calling it a "TCP/IP" connection is probably only ever used for legacy reasons. A lot of terms like this still exist because before the technology "bubble" growth, there were competing alternatives to IP. Even today, there is IPv6 which is technically an alternative to IPv4. It's also possible that we might one day outgrow IPv6, and at that point in time, there could be something other than IP to worry about.
I have a machine, with no external IP address, it will need to send UDP packets to the outside world. Only NAT access.
Will this work?
It is really hard to prototype this in our environment.
It is still really under construction.
Any thoughts on how I can prototype this?
Most of the home network configurations in the world are made of a PC with an internal IP and a router with a public IP that NAT the internal one. (Independently of UDP/TCP or whatever protocol that needs to go out)
I see no troubles with it
It should work.
Ensure that for the socket created, set the TTL (time-to-live) to a value that is sufficiently large to cover the possible number of router hops to reach the destination. Running traceroute to the destination IP will give you a rough idea on the number of hops. Note that this value can change depending on network conditions. So it's best to set this to a larger value. Refer to sockets IOCtl API documentation for the syntax for setting TTL.
Finally, remember that UDP is not a reliable protocol. So even after taking the necessary steps above, the packet may not reach its destination. However, if the entire network, including the intermediary routers, is within a controlled environment, such as a corporate intranet, chances of packet drop are minimal.
If you want to add reliability on top of UDP, you can adopt a NAK based algorithm where packets are stamped with a sequence number. Various resources might advise you that if you need to add reliability over UDP you should consider TCP, but my experience has been that if your app runs in a controlled environment with very minimal chance of packet drops and you need fast connection setup and tear down, adding a lightweight reliability over UDP has its merits. Also TCP connections take up valuable space in the OS kernel whereas UDP don't. This could also be a consideration if you want to support very large number of 'connections' in a constrained environment.
At the end of the day you need to experiment a little to figure out what works best for you.
To prototype, I would set up a NAT server using something like Linux and then start working from there. Real world traffic scenarios that you want to simulate will determine where the client and server are to be located on either side of the NAT. That is, if the traffic should go through an ISP or all within a controlled environment.
HTH
I am reading about TCP sockets which require a connection to be set up between a client and a server. Is it possible to have TCP sockets working on a wireless connection?
Perhaps you are interpreting 'connection' to mean 'physical link' (as in, wires). This is incorrect.
'physical' in networking extends to all data transfer mediums. In the case of wireless, this is the radio waves. In terms of TCP a 'connection' is made when one computer is listening on a network and responds to a second computer who makes a request.
TCP doesn't care what physical medium it is travelling through.
With regards to your question it may help to think of the OSI model. In this model TCP sits at level 4. What this should mean is that it can be mostly oblivious to what happens above and below it.
The actual physical layer is level 1 of the OSI model, so TCP should not have to care what is happening there. Thus, whether you are using wires, wireless, fiber or pieces of paper to send the TCP packets is irrelevant, so long as the protocol is enacted as described.
Short answer - Yes.
Read more at wiki
I hope so - I am using mobile broadband. And web access uses TCP/Sockets.
The network technology is organized in so called layers.
Physical transmission of signals is responsibility of the first layer. It can be copper cable, optical fiber, radio signals, homing pigeons, whatever technology there is to get zeros and ones between the machines.
TCP is a fourth layer protocol. It relies on the bottom three layers to route packets of data from the source to the destination. It's responsibility is to make sure that the packets arrive in an orderly fashion.
The whole point of this layered structure is that when you program networking drivers, you don't need to worry what kind of data the user will send on the network. When you program web application you don't need to worry if the user is connected with an ethernet CAT-5 cable, or a cable TV modem.
Does anyone know why should I use Winpcap and not just .Net sockets to sniff packets on my local pc?
TY
Sockets (.NET, Winsock, etc.) normally collect at layer 7, the Application layer. That is, whatever is sent by the sender is what is received by the receiver. All of the various headers that are added automatically on the sending side are stripped off by the time the receiver reads the data from the socket.
It is possible to configure a socket to be a raw socket, in which case, you can see all of the headers down to layer 3, the Network layer. Further still, you can put the raw socket in promiscuous mode, which allows you to see all of the traffic on the network, not just the packets destined for your machine. But even this is limited. For example, when you configure the raw socket, you specify the protocol type to use, e.g., IP, ICMP, etc. This limits the socket to "seeing" packets that adhere to that protocol. I have been unable to figure out how to make the socket see all packets at layer 3 regardless of protocol.
Winpcap operates as a device driver at layer 2, the Data Link layer. In this case, you see literally all of the packets on the network with full headers down to layer 2. Winpcap also offers filtering capability so you can narrow down the packets that are reported to you based on whatever criteria you provide.
As far as choosing between them, it really boils down to the requirements of your specific task. If you are trying to implement any kind of realistic network analysis capability, you'll be hardpressed to do that with just sockets. Winpcap makes more sense in that case. However, if you are only interested in IP packets, for example, then sockets will work fine for that.
As far as I understanf .Net sockets are an IPC to communicate between 2 processes. While winpcap is a library that help you to access the data link layer an sniff pacquets going through your network hardware (or virtual) devices on your machine. Data link layer allow to get the data on any socket (.Net or not) created on your system.