Problem
I have just started to scratch the surface of this topic so excuse me if I'm formulating the question a bit strange and novice. Let's say I'm on a wireless network which I am right now, and I want to see all the data that is flowing in and out of this network from other clients connected to the network. I remember reading a book about someone doing this while being connected to the Tor network and it got me thinking about how this is done.
Questions
A: what is this process called?
B: How is it done?
Wireshark can do this:
http://www.wireshark.org/
It sniffs packets in "promiscuous mode":
http://en.wikipedia.org/wiki/Promiscuous_mode
That lets you see all the packets routed through a specified network interface, not just the packets targeted to a particular client.
A: It's call packet analyzing / packet sniffing.
B: In an unswitched network (e.g. a wifi network or hub), all you need is a network card that supports promiscuous mode and some software, as mentioned by sdanzig.
In a switched environment (e.g. most modern wired networks), you need to use a Layer 3 switch and set it up to mirror the traffic you're interested in to the port to which you are connected. (Otherwise your network adapter won't 'see' the other traffic.)
Some tools:
http://www.dmoz.org/Computers/Software/Networking/Network_Performance/Protocol_Analyzers/
Related topics on SO:
https://stackoverflow.com/questions/tagged/packet-sniffers
https://stackoverflow.com/questions/tagged/packet-capture
Related
I'm very unfamiliar with Linux so forgive me if this has been answered before, I've read quite a few answers but I'm never sure if they actually relate to my question.
I have a headless raspberry pi that connects to my phone's bluetooth automatically, my phone shares its internet access by tethering. I use this initial and reliable connection to SSH to my raspberry pi, and use the desktop with VNC viewer.
I would like to connect to a WiFi network that uses a captive portal, but the browser always uses the bluetooth connection so it never redirects me to the portal page. The bluetooth connection is just to be able to use the desktop so I can get through the portal, then I would like to either disconnect bluetooth or just not use it, mainly because of the low bandwidth it provides.
I've added wlan0 as a priority interface with ifmetric, but that hasn't worked.
I was thinking that forcing all HTTP connections through the wlan0 interface could solve the problem, but there may be a simpler way, feel free to tell me.
Can you explain in "simple" terms the best way to achieve this ?
Of course, there are multiple solutions. The simplest is making sure that there is only one correct default route.
There are 3 situations:
You are only connected via bluetooth via ssh
You are connected via bluetooth and via wifi, but not yet through the splash
You are through the splash
Each will require a different network configuration.
In 1, your network config will probably be:
some IP address (let's call it IP-bt) and network mask
Default gateway is your phone
With route -n you can verify this.
In 2, the network config will depend a bit on the wifi network, but in general, your network config will be:
you'll still have IP-bt
you will have a new address on the wifi adapter (which we call IP-wifi)
the default gateway should be the gateway on the wifi network.
When you verify this with route -n, you might still see a route with destination 0.0.0.0 towards your phone. You can delete this route. Your phone should be on a directly connected network and your ssh session should therefore not break.
If the default gw is not on the wifi network, you can still remove the route that sets your phone as default gw.
Under 3, the default gw must be on the wifi network, and not on the phone. You will still be able to use your phone, because it is directly connected.
Something to watch out for in this scenario is that your phone will act as a DHCP server. That means once in a while your DHCP lease will refresh, and the bluetooth default route may re-appear. Disconnecting bluetooth will prevent this.
The second solution is to use ifmetric. Instead of making wlan0 a lower metric, make your bluetooth a higher metric. Again verify with route -n that the metrics are as you want them to be. Verify with a traceroute how the packets are moving.
A third, and most complex option would be to install Quagga and configure correct routing.
I recall reading an article about a proposed way to do this. If I recall correctly, the researchers successfully created a connection to a client on another network without port forwarding by sending HTTP packets to each other (Alice pretends that Bob is an HTTP web server while Bob pretends Alice is a web server).
I'm not sure if that makes sense, but does anyone know where I can find the article or does anyone have any other ideas how to connect two clients together without a central server or port forwarding?
Is it even possible?
Edit: I would know the IPs of both computers and port the program listens on.
It is possible. I see at least 2 parts to your question. (It is not going to be HTTP packet. It is a lot more complex than that.)
First off, I believe you might be talking about a concept called decentralized P2P network. The main idea behind a decentralized peer-to-peer network is the fact that nodes conjoint in such a network will not require central server or group of servers.
As you might already know, most common centralized peer-to-peer networks require such centralized system to exchange and maintain interconnectivity among nodes. The basic concept is such, a new node will connect to one of the main servers to retrieve information about other nodes on the network to maintain its connectivity and availability. The central system gets maintained through servers constantly synchronizing network state, relevant information, and central coordination among each other.
Decentralized network, on the other hand, does not have any structure or predetermined core. This peer-to-peer model is also called unstructured P2P networks. Any new node will copy or inherit original links from the "parent" node and will form its own list over time. There are several categories of decentralization of such unstructured networks.
Interestingly enough, the absence of central command and control system makes it solution of choice for modern malware botnets. A great example could be Storm botnet, which employed so-called Passive P2P Monitor (PPM). PPM was able to locate the infected hosts and build peer list regardless whether or not infected hosts are behind a firewall or NAT. Wikipedia's article Storm botnet is an interesting read. There is also great collaborative study called Towards Complete Node Enumeration in a Peer-to-Peer Botnet, which provides excellent conceptual analysis and techniques employed by Storm botnet network.
Second of all, you might be talking about UDP hole punching. This is a technique or algorithm used to maintain connectivity between 2 hosts behind NATed router/gateway using 3rd comment host by means of a third rendezvous server.
There is a great paper by Bryan Ford, Pyda Srisuresh, and Dan Kegel called Peer-to-Peer Communication Across Network Address Translators.
As answered, a peer-to-peer connection requires establishment of a connection between two (presumably) residential computers, which will necessitate punching holes through both of their firewalls. For a concrete example of hole punching, see pwnat: "The only tool to punch holes through firewalls/NATs without a third party". The process, put simply, goes like this:
The "server" (who doesn't know the client's IP address, but the client knows the server's) pings a very specific ICMP Echo Request packet to 1.2.3.4 every 30 seconds. The NAT, during translation, takes note of this packet in case it gets a response.
The client sends an ICMP Time Exceeded packet to the server, which is a type of packet that usually contains the packet that failed to deliver. The client, knowing in advance the exact packet that the server has been sending to 1.2.3.4, embeds that whole packet in the Data field.
The NAT recognizes the Echo Request packet and happily relays the whole Time Exceeded packet, source IP and all, to the correct user, i.e. the server. Voila, now the server knows the client's IP and port number.
Now that the server knows the address, it begins to continually send UDP packets to the client, despite the fact that the client's NAT did not expect them and will therefore ignore them all.
The client begins sending UDP packets to the server, which will be recognized by the server's NAT as a response to the server's packets and route them appropriately.
Now that the client is sending UDP packets to the server, the server's stream of UDP packets starts getting properly routed by the client's NAT.
And, in 6 easy steps, you have established a UDP connection between a client and a server penetrating two residential firewalls. Take that, ISP!
I am able to get the packets in the network by tcpdump.I want to get the device info like computer name,its model name ,OS running on it etc.
Is it possible by using tcpdump packets .
I got the mac address (by arp),IP but which layer protocol giving this above information what I want.
Can you tell me how to use this dumped data to get my required data.
Thanks
but which layer protocol giving this above information what I want
The details you mention aren't present in network data - for example there's no point in a TCP segment advertising "Windows XP emitted this.". At most you can use tools like nmap that try to guess the OS based on subtle network engine implementation differences.
I have an interesting problem. I am working on an embedded box with multiple instances of Linux running each on an ARM processor. They are connected over internal 1GBps network. I have a serial port device node attached to processor A (Lets say Linux-A running on it). I have a program running on processor B (Lets say on Linux-B) access the serial port device as if it is attached to Linux-B locally.
My program invokes term i/o type api calls on device node to control tty echo, character mode input. What I am wondering is if there is a way to create a virtual serial device that is available on Linux-B somehow talking to real serial device on Linux-A over internal network.
I am thinking something along the lines of:
Linux-B has /dev/ttyvirtual. Anything that gets written to it gets transported over network socket to Linux-A serialserver. The serial server exrcises the api calls on real device lets say /dev/ttys0.
Any data waiting on ttys0 gets transported back to /dev/ttyvirtual.
What are all the things involved to get this done fast?
Thanks
Videoguy
Update:
I found a discussion at
http://fixunix.com/bsd/261068-network-socket-serial-port-question.html with great pointers.
Another useful link is http://blog.philippklaus.de/2011/08/make-rs232-serial-devices-accessible-via-ethernet/
Take a look at openpty(3). This lets you create a pseudo-TTY (like /dev/pts/0, the sort that ssh connections use), which will respond as a normal TTY would, but give you direct programmatic control over the connections.
This way you can host a serial device (eg. /dev/pts/5) that you forward data between a network connection, and then other apps can perform serial operations on it without knowing about the underlying network bridge.
I ended up using socat
Examples can be found here: socat examples
You socat back to back on both the machines. One listens on a tcp port and forwards data to local virtual port or pty. The socat on other box uses real device as input and forwards any data to tcp port.
I'm working with a cluster of about 40 nodes running Debian 4. Each node runs a daemon which sits and listens on a multicast IP.
I wrote some client software to send out a multicast over the LAN with a client computer on the same switch as the cluster, so that each node in the cluster would receive the packet and respond.
It works great, except when I run the client software on a computer that has both LAN and WAN interfaces. If there is a WAN interface, the multicast doesn't work. So obviously, I figure the multicast is incorrectly going over the WAN interface (eth0), rather than the LAN (eth1.) So, I use the SO_BINDTODEVICE socket option to force the multicast socket to use eth1, and all is well.
But I thought that the kernel's routing table should determine that the LAN (eth1) is obviously a lower cost destination for the multicast. Is there some reason I have to explicitly force the socket to use eth1? And, is there some way (perhaps an ioctl call) that I can have the application automatically determine if a particular interface is a LAN or WAN?
If you don't explicitly bind to an
interface, I believe Linux uses the
interface for the default unicast
route for multicast sending.
Linux needs a multicast route, if none exists you will get a EHOSTUNREACH or ENETUNREACH error. The LCM project documents this possible problem. The routing will be overridden if you use the socket option IP_MULTICAST_IF or IPV6_MULTICAST_IF. You are supposed be able to specify the interface via scope-id field in IPv6 addresses but not all platforms properly support it. As dameiss points out, Stevens' Unix Network Programming book covers these details, you can browse most of the chapter on multicast via Google Books for free.
If you don't explicitly bind to an interface, I believe Linux uses the interface for the default unicast route for multicast sending. So my guess is that your default route is via the WAN interface.
Richard Stevens' "Unix Network Programming, Vol. 1", chapter 17 (at least in the 3rd edition), has some good information and examples of how to enumerate the network interfaces.