The title pretty much describes the question: if I send a packet containing, I don't know, some text inside it, from a python program to an other, if there's a hacker sniffing packets on the network, would they be able to see the content of the packet?
If you use a plain TCP or UDP socket then the data you write into this socket are transferred in clear on the wire and can be sniffed unless the OS employs encryption at the network layer or lower layers, i.e. VPN technologies like IPSec, OpenVPN or similar.
If instead you are using an SSL wrapped socket then the data will be encrypted inside the application and thus protected against sniffing provided that the SSL socket was created with secure settings (strong ciphers, proper certificate validation).
Related
I'm implementing client-server communication using UDP that's used for FTP. First off, you don't need to tell me that UDP is unreliable, I know. My approach is: client asks for a file, server blasts the client with udp packets with sequence numbers, then says "what'd you miss?", resending those. On a local network, packet loss is < 1%. I'm pretty new to socket programming, so I'm not familiar with all the socket options (of which most examples found on google are for tcp).
My problem is why my client's receiving of this data.
PACKET_SIZE = 9216
mysocket.sendto('GO!', server_addr)
while True:
resp = mysocket.recv(PACKET_SIZE)
worker_thread.enqeue_packet(resp)
But by the time it gets back up to .recv(), it's missed a few udp packets (that I've confirmed are being sent using wireshark). I can fix this by making the server send slightly slower (actually, including logging statements is enough of a delay to make everything function).
How can i make sure that socket.recv doesn't miss anything in the time it takes to process a packet? I've tried pushing the data out to a separate thread that pushes it into a queue, but it's still not enough.
Any ideas? select, recv_into, setblocking?
While you already know, that UDP is not reliable, you maybe missed the other advantages of TCP. Relevant for you is that TCP has flow control and automatically scales down if the receiver is unable to cope with the senders speed (e.g. packet loss). So for normal connections TCP should be preferred for data transfer. For high latency connections (satellite link) it behaves too bad in the default configuration, so that some people design there custom transfer protocols (mostly with UDP), while others just tune the existing TCP stack.
I don't know why you use UDP, but if you want to continue to use it you should add some kind of back channel to the sender to inform it from current packet loss, so that it can scale down. Maybe you should have a look at RTCP, which accompanies RTP (used for VoIP etc).
Using a Lantronix UDS-1100 serial to IP converter. The goal is to write a small proof of concept piece in Python to capture serial data output by this device over IP.
I've done a couple test projects using sockets in python, but they were all done between python processes (python > python): listen() on one end, and connect(), sendall() etc on the other.
I think I can use sockets for this project, but before I invest a bunch of time into it, wanted to make sure it is a viable solution.
Can python sockets be used to capture IP traffic when the traffic is originating from a non-python source? I have full control over the IP and port that the device sends the serial data to, but there will be no python connect() initiated by the client. I can pre-pend then serial data with some connect() string if needed.
If sockets won't work, please recommend another solution...guessing it will be REST or similar.
Of course. TCP/IP is supposed to be cross-platform and cross-language, so in theory you should be able to communicate with every kind of device as long as you manage to process and send the expected protocol.
This is the problem I'm trying to solve,
I want to write an application that will read outbound http request packets on the same machine's network card. This would then be able to extract the GET url from it.On basis of this information, I want to be able to stop the packet, or redirect it , or let it pass.
However I want my application to be running in promiscuous mode (like wireshark does), and yet be able to eat up (stop) the outbound packet.
I have searched around a bit on this..
libpcap / pcap.h allows to me read packets at the network card, however I haven't yet been able to figure out a way to stop these packets or inject new ones into the network.
Certain stuff like twisted or scapy in python, allows me set up a server that is listening on some local port, I can then configure my browser to connect to it, using proxy configurations. This app can then do the stuff.. but my main purpose of being promiscuous is defeated here..
Any help on how I could achieve this would be greatly appreciated ..
I'd suggest that you approach this at the application layer and use a transparent proxy (e.g. squid) and iptables based interception of outbound port-80 traffic.
The reason I suggest this is that that it will avoid issues with the request being split between packets.
However, if you still want to go ahead with packet interception, you can do it in userspace using netfilters in netlink. I believe there are python wrappers for libnl around.
Essentially you create an iptables rule pointing to "QUEUE" for the traffic you want to intercept and write a program using a netlink library to process the queue, accepting, rejecting and/or modifying packets.
Using pcap you cannot stop the packets, if you are under windows you must go down to the driver level... but you can stop only packets that your machine send.
A solution is act as a pipe to the destination machine: You need two network interfaces (without address possibly), when you get a packet that you does not found interesting on the source network card you simply send it on the destination network card. If the packet is interesting you does not send it, so you act as a filter. I have done it for multimedia performance test (adding jitter, noise, etc.. to video streaming)
You are confusing several things here:
"Promiscuous" usually refers to a mode of a hardware ethernet network card where it delivers all packets in its collision domain up to the kernel network stack and have it sort out delivery (vs. just unicast to given MAC, subscribed multicast, and broadcast in normal operating mode of the card). This is on the receive path.
All the data outbound from your machine will go through (one of) the network cards on the machine, so "promiscuous" does not at all apply here.
You are working on filtering TCP-based protocol (HTTP), but talk in terms of packets. This is wrong. TCP connection is a stream that could be (as far as socket readers and writers are concerned) arbitrarily split into IP datagrams. That URL from HTTP request header could be split across multiple link-layer frames. You would have to stitch them back together and parse the stream anyway. Then you have no chance even at that if SSL is in use.
If you are interested in HTTP filtering then read HTTP RFCs, and read existing open-source code, e.g. squid, nginx, etc.
If you are digging through network stack for better understaning then read W. Richard Stevens books, look into existing code in open-source operating systems, check out BPF and netlink.
Hope this clears it a little.
I have implemented this module in Windows by using two separate NICs and using a socket/pipe(whatever you like) between them in this thread
I have a big problem, and I am having a hard time solving it. I have a custom made game controller, which outputs some data from it's sensors via serial communication and is connected to PC via serial port. I do the callculation of the current controller position in a Matlab script. I am building a web application that will display the data (position) of the device in a web browser, but can't seem to work out, how to connect my device to the browser. Matlab script sends all the position data to a UDP port with a sampling fequency of 100HZ (100 samples per second). I need to make a persistent connection between a web browser and my matlab script so I will be able to display the data. I am thinking about using web sockets API. but it does not "speak" UDP. So my idea was to somehow read the data with from UDP with a custom Python server and then create a websocket on that Python server and send data received via UDP port to web browser. Oh, and it would be nice if I could communicate in both directions. Will this work? Any ideas on how to do it? How is this usually done, I mean how can one connect let's say some temperature sensor to web browser to display data in real time?
Any answer will be gladly appreciated.
Thanks,
Leon
Note that although the WebSockets protocol is built on TCP sockets, the WebSockets protocol is not raw TCP sockets. A WebSockets connection has an HTTP friendly handshake (with some CORS functionality built-in). WebSockets are also message based (rather than streaming like TCP) so each message has a couple of bytes of framing headers.
You might look at websockify (disclaimer: I made websockify). Websockify is a python server that bridges/proxies between WebSockets and plain TCP sockets. I don't think it would be particularly difficult to adapt it to handle UDP sockets on the backend.
WebSockify (designed to be used together with the included include/websock.js front-end library) supports binary data even over the older Hixie versions of the protocol. This allows it to work with iOS (iPhone,iPad) devices which still only support the older version of the protocol.
Is there any way to send ARP packet on Windows without the use of another library such as winpcap?
I have heard that Windows XP SP2 blocks raw ethernet sockets, but I have also heard that raw sockets are only blocked for administrators. Any clarification here?
There is no way to do that in the general case without the use of an external library.
If there are no requirements on what the packet should contain (i.e., if any ARP packet will do) then you can obviously send an ARP request if you're on an Ethernet network simply by trying to send something to any IP on your own subnet (ensuring beforehand that the destination IP is not in the ARP cache by running an external arp -d tar.get.ip.address command), but this will probably not be what you want.
For more information about raw socket support see the TCP/IP Raw Sockets Docs page, specifically the Limitations on Raw Sockets section.
You could use the OpenVPN tap to send arbitrary packets as if you where using raw sockets.