Analyzing abnormal TCP/IP traffic: Sequential IP sequence numbers - ip

My professor told me that sequential IP sequence numbers is typical behavior of most IP stacks (and showed us examples of packet sniffers), but I thought IP sequence numbers are supposed to be randomly generated to avoid attacks?
Which one is it. I am taking a digital forensics class and I need to know how to differentiate "normal" tcp/ip stack traffic from "abnormal" traffic

Linux and Solaris are the two major offenders of predictable IP id's. I unfortunately have to run to a meeting right now so I can't explain but i'll try and remember to edit this with a better explanation when I get back. Most other OS's were patched over a decade ago to have psuedo random starting IP id's.

Related

Is a netflow record equal to a session?

Because I don't very understand a session definition in network I have a puzzle that whether a netflow record equal to a session?
If I upload some files to the server through FTP at a time, and there produce 50
netflow records(same source and destination IP but ports are different). Does the process equal to 50 sessions, or the process after the server closed the connection equal to only one session?
such like this photo:
thanks a lot :)
Short answer; It all depends.
There are many factors and variables when working with network flows, whether it's Cisco's Netflow format (in various versions), IETF's IPFIX or other similar formats. If we take a very common format, Netflow v5, a flow is defined by 5 or 7 tuples (depending on how detailed the definition is). These tuples are; Source and destination IP address, source and destination port and protocol (in addition Type of Service and ingress interface index). Also Netflow v5 is a uni-directional network flow protocol, meaning it will treat connections coming from the server separately from those going to the server. So any IP packet matching that 5/7 tuple definition in one direction will constitute a network flow and result in a Netflow record. All this have to be taken into consideration when examining Netflow data and comparing it to network communication sessions (which by itself also may have different definitions based on its context).
And as if that wasn't enough, there are also implementation specific variables and limitations, that may split a session into several records. Usually flow protocols implement various timeouts to be able to efficiently collect and store data. TCP sessions may have connections open over a long time period, and makes it challenging for the flow generator to keep and maintain the flow in memory. Some network flow formats have the ability to locate such split records and merge them into one single flow record.
So, to sum up, network analysts starting to work with network flows easily fall into the trap of thinking one record equals one session. That assumption may be true sometimes, but not always.

Why not use MAC addresses instead of Local IPs?

In similar questions, the question that has been answered is:
why do we need both MAC and IP addresses on the internet? They are
both addresses. Why can't one just be used to describe a device?
The answer is along the lines of:
The two protocols are not universal, not all devices use it. IP
provides a logical address and allows routing, MAC doesn't support routing, and more.
My new question is:
That's a nice answer as to why the internet as a whole needs both types of addresses, but why do we need Local IP addresses?
Locally, on the same network, no routing is involved, I'm simply sending to the computer next to me. Why can't I just send directly to his MAC address? And the router that connects our local network to the internet - why can't he just store a table of MAC addresses to keep track of what from the outside world goes where in the "local world"?
The existence of Local IP seems unnecessary.
So lets forget for a second that all modern OS's are primarily based on IP/IPv6 and your suggestion would completely break everything. Imagine this analogy:
An IP address is like a fully qualified postal address:
I. M. Ray
1024 Megabit Dr
Somecity, State 10101
Your MAC address is your physical house. The blue one 4 house from the corner, with the big oak tree.
When someone is sending you a letter conventionally, the mail is routed to your local post office based on the full address. We will compare this with routing of IP over the internet. The post office the mail was sent from could care less about your oak tree.
In the conventional method, the post man would organize his deliveries by street, and go house to house delivering the mail. This is similar to ARP table, we have organized the houses into an easy to find and navigate index.
In your proposed method, as soon as the mail arrives at the post office, they replace the envelope with your full address to one with a description of your house on it. It is now the post mans job to remember where the Blue house with the oak tree is.
So, while your thoughts are on the right track, they are just not practical. Once you are on the same layer 2 domain (local), then you don't necessarily need routing and could in theory use just physical addresses.
I am sorry if this is a pretty far out answer. I've been reading your other questions on the topic, and it seems as though you are trying to wrap your head around this subject, and this was my best attempt at breaking it down logically. The whole idea is pretty tricky to understand at first (we've all been there), but once you figure out the parts and the role they play in the grand scheme, the more it starts to make sense.
Please feel free to ask if you have any questions, as my primary intention of posting this is to actually help you out.

Is given IP address assigned to some Wi-Fi Hotspot?

I'm doing a project: the goal is to find features detecting a hotspot, but I have no training set or test set for development and estimation of methods yet.
As far as I understand, there are 2 ways to build the sets:
to get a list of some of U.S. hotspots;
to find a function that checks if given IP address is connected with some hotspot (with some measure of certainty).
So what I wonder:
is there any U.S. Hotspots IP dataset?
are there any other ways or technologies to find out whether a given IP address is assigned to a Hotspot?
Any helpful ideas appreciated (criticism is appreciated too).
A few tips.
You actually want to use MAC address, not IP. IPs can change quite a bit easier than MAC addresses.
There are at least 2 sets of mac/location data sets, Skyhook and Google. Skyhook has a web site where you can learn more about their SDK, I don't think Google allows direct access of their. The cost to use Skyhook varies, but in general it is around $0.50 a device, depending on a large number of factors.

A Parallel IP address space exlusively for a P2P network?

I would like to do this because it would make peer location much more effective in my p2p network as I would know that all the addresses would be part of this network.
How could I do this while remaining compatible with current transport layer protocols such as SCTP, and the current hardware used on the big wide Internet?
Thanks,
Andreas
I suggest using IPv6.
There is enough address space that you can create up to 2^40 "unique unicast" ranges, each with 16 bits of subnet and 64 bits of host ID.
Protocols such as UDP, TCP, and SCTP already work on top of it
It already has major operating system support.
See http://www.rfc-editor.org/rfc/rfc4193.txt
Densely filling the 40-bit unique-id is discouraged. Use the random generation method mentioned in the RFC.
Put simply, you can't. IPv4 IPs are distributed by IANA to the five major IP registries: ARIN (North America), RIPE (Europe), APNIC (Asia/Pacific), LACNIC (Latin America/Carribean), and AfriNIC (Africa). These registries then distribute those out to ISPs.
There are blocks reserved for local networks, but those are not routable over the public Internet... they must be encapsulated; this is how VPNs work.
The best way to have this kind of functionality is probably to use a name lookup service, or even a peer discovery service in the protocol itself.
The fact is, no matter what you do, it is likely that you will have to get your application to perform extra work on top of the IP protocol anyway, because the IP protocol itself supports only 1 address space, you need to add another layer to add an independent address space.
It looks like you're trying to create a network inside of a P2P "world". So all the users using the P2P app would have a second IP address, say Alice has 10.0.2.40, that could be used by Bob, another user of the app, to get to Alice. Right?
With that regards, it looks like you'd want to set up a VPN on each client and use some sort of route table modifications so the VPN is only used for the address-space allocated by the the P2P program (say the 10.x.x.x network).
But there are problems with that.. for example you'll never find an address space that everyone has free to use. Home Routers use 192.168.x.x, corporate networks or enthusiasts (like myself) use 10.x.x.x, and the 172.something is used by other sysadmins for stuff I'm sure.
Disclaimer: Not a networking genius, I'm speculating here.

Detect another host with the same MAC address

How can I detect if another host is using the same MAC address as the current host, e.g. because the other host is spoofing?
I'm working in an embedded environment, so looking for answers on a protocol level, rather than “use such and such a tool”.
Edit: RARP does not solve this problem. For RARP to get any reply at all, there has to be at least one host on the segment which supports RARP. Since RARP is obsolete, modern operating systems don't support it. Furthermore, all RARP can do is tell you your own IP address - the response won't be any different if there’s another host on the segment with the same MAC, unless that host has itself used a different IP address.
This question is too interesting to put down! After several false starts I started thinking about the essential components of the problem and scoured the RFCs for advice. I haven't found a definitive answer, but here's my thought process, in the hope that it helps:
The original question asks how to detect another device with your MAC address. Assuming you're on an IP network, what's required to accomplish this?
The passive method would be simply to listen to traffic and look for any packets that you didn't transmit but have your MAC address. This may or may not occur, so although it can tell you definitively if a duplicate exists, it cannot tell you definitively that it doesn't.
Any active method requires you to transmit a packet that forces an impostor to respond. This immediately eliminates any methods that depend on optional protocols.
If another device is spoofing you, it must (by definition) respond to packets with your MAC address as the destination. Otherwise it's snooping but not spoofing.
The solution should be independent of IP address and involve only the MAC address.
So the answer, it seems, would be to transmit either a broadcast (ethernet) packet or a packet with your MAC address as its destination, that requires a response. The monkeywrench is that an IP address is usually involved, and you don't know it.
What sort of protocol fits this description?
Easy Answer:
If your network supports BOOTP or DHCP, you're done, because this authoritatively binds a MAC address to an IP address. Send a BOOTP request, get an IP address, and try to talk to it. You may need to be creative to force the packet onto the wire and prevent yourself from responding (I'm thinking judicious use of iptables and NAT).
Not-so-easy Answers:
A protocol that's independent of IP: either one that doesn't use the IP layer, or one that allows broadcasts. None comes to mind.
Send any packet that would normally generate a response from you, prevent yourself from responding, and look for a response from another device. It would seem sensible to use your IP address as the destination, but I'm not convinced of that. Unfortunately, the details (and, therefore the answer) are left as an exercise for the OP ... but I hope the discussion was helpful.
I suspect the final solution will involve a combination of techniques, as no single approach seems to guarantee a dependable determination.
Some information is available at http://en.wikipedia.org/wiki/ARP_spoofing#Defenses
If all else fails, you may enjoy this: http://www.rfc-editor.org/rfc/rfc2321.txt
Please post a follow-up with your solution, as I'm sure it will be helpful to others. Good luck!
You could send an ARP request for each possible ip in the subnet.
Of course the source address of the ARP request must be ff:ff:ff:ff:ff:ff, otherwise you might not see the response.
I forged a packet like this with bittwiste and replayed it with PReplay and all the hosts on the network got the response. (I don't know if these forged ARP packets are legal or not... some OSes might ignore them)
Here is what the forged package looked like:
Here is what the reply looked like:
If you watch the responses and see your MAC address in one of the packets (in the red rectangle) , than someone has the same MAC address as you do...
Unfortuantely I couldn't test the theory fully because none of my (Windows) machines care about me trying to set the nic's MAC address...
Two hosts using same MAC address on a single network segment would probably make switches go nuts and you could probably detect it by having an extremely unreliable network connection (as the switches would send some portion of packets that belong to your host to the second one, depending on which one of you sent the last packet in their direction).
This is very late, and a non-answer, but I wanted to follow up with exactly what I did in case anyone else is interested.
I was working with some very weird embedded hardware that doesn’t have a MAC address assigned at manufacture. That means we needed to assign one in software.
The obvious solution is to have the user pick a MAC address that they know is available on their network, preferably from the locally-administered range, and that’s what I did. However, I wanted to pick a reasonably safe default, and also attempt to warn the user if a conflict occurred.
In the end I resorted to picking a random-ish default in the locally-administered range, chosen by making some hardware readings that have moderate entropy. I deliberately excluded the beginning and end of the range on the assumption that those are moderately more likely to be chosen manually. The chances are that there will only be one of these devices on any given network, and certainly less than 20, so the chances of a conflict are very low, albeit not as low as they could be due to the somewhat predictable random numbers.
Given the low chances of there being a problem, and despite the excellent answers above, I decided to dispense with the conflict detection and make do with a warning to the user to look out for MAC conflict problems.
If I did decide to implement conflict detection, then given that I control the whole network stack, I would probably look out for excessive unknown or missing packets, and then trigger a change of MAC address or warn the user when that happens.
Hopefully that will help someone else somewhere – but probably not!

Resources