I am trying to capture ftp packets using scapy. I need to capture the ftp file listing packet when I type the ftp command "ls".
I searched online and found that file listing should be done in passive mode, but that means server port will change; it will not be 21 which I use in scapy to recognize the ftp packets from other packets.
Is there a way I can list the files in active mode? Or another way to capture the listing package in scapy while the server port is a variable "not 21"?
Thank you in advance.
If you have a complete control over the FTP connection, you can use both passive and active mode to retrieve the directory listing.
Though with active mode, the server has to be able to connect to your machine, what is often not possible due to ubiquitous firewalls and NATs. Read my article on network setup needed for FTP active and passive connection modes.
In active mode, the server should use outgoing port 20 for the directory listing. Though if firewall/NAT is involved, the real port, that your client (and Scapy) will see, can be completely different anyway. So it may not help in the end.
With passive mode, you would have to inspect the main (control) connection and detect what port will be used for the listing/data connection and start inspecting that port too. Scapy may even have that functionality (or part of it) built-in, I'm not familiar with Scapy.
Related
I have a server application in .NET 6/VS2022 which creates a TCP listener, and a python 3 application which creates a socket to connect to the server application.
Rather than hopping back and forth between VS2022 and PyCharm with breakpoints in each, is there any way I can view the network communication, including contents with bytes and ASCII decode, source and remote endpoint, and source and remote process names and ids?
Solution
A simple way is to use the Wireshark GUI application. On devices that do not allow the installation of the GUI, the network data can be recorded using tshark to a file, transferred to a PC with GUI Wireshark and viewed in detail.
https://www.wireshark.org/
(On windows, the tshark is part of the Wireshark installation. In Linux, it is installed separately from the SW repository.)
Wireshark allows you to view everything you want from the captured data. It is necessary to correctly choose the interface from which the data is recorded. If the server and client are on the same PC, you must choose the localhost interface (the loopback i/f with the address 127.0.0.1).
Addition
The problem arises if the network communication is encrypted (SSL, e.g. HTTPS). Wireshark then displays the packets, but the payload is unreadable. Even this case has a solution, but significantly more complex. It is necessary to use keys/certificates from communicating peers in Wireshark.
I'm trying to setup a network to simulate an Edge computing scenario with LTE. But the question here is more pertaining to IP tables and raw sockets on the server.
I have the following setup:
PC-A is the Tower, PC-C is the LTE Core, PC-B is acting as intermediary and routing data using proxy ARPs
Cell phone wants to connect to a TCP server on PC-B(IP: 172.17.1.3)
Cell phone(IP:192.172.0.2) sends packets to PC-A(IP: 172.17.1.1)
The data from PC-A(172.17.1.1) generally has to reach LTE-EPC on 172.17.1.4 which is connected via PC-B(172.17.1.2 - 172.17.1.3 with proxy ARPs). And the data comes in the form of UDP packets to PC-B(IP: 172.17.1.2)
I use NAT table and python script with raw sockets to send all of these UDP packets to a local port, do some filtering, decapsulate the GTP headers and send the TCP/IP packet to the TCP server on PC-B interface(172.17.1.3). I use the below iptables settings to do this
iptables -t nat -A PREROUTING -p udp -d 172.17.1.4 --dport 2152 -j DNAT --to-destination 172.17.1.2:7000
Until here everything works, the extracted TCP/IP packet also reaches the TCP server on 172.17.1.3. The server responds to these packets. For example, for the SYN packet from the cell phone, the server now sends out SYN, ACK. However, the server responds to the original source address 192.172.0.2.
I want to catch these response TCP/IP packets from the TCP server 172.17.1.3 to 192.172.0.2 and do some GTP encapsulation before sending them back to PC-A.
Can anyone tell me how I can use the iptables to tell the kernel to stop dropping these martian packets with destination address 192.172.0.2, but instead forward to a local ip and port, so I can read the same.
I can see the SYN, ACK responses from the server on wireshark. But I assume that these are dropped as I already tried to route it to local ip:port using a similar iptables rule from above.
Any help is much appreciated, Thank you.
It sounds like a tun/tap interface could be useful here. Here's the official Linux kernel documentation.
Both these interface types allow a program to create a virtual network interface. This is designed for tunnels and VPNs and it seems like that is exactly what you are creating.
According to the linked documentation, you may create an interface by opening /dev/net/tun (O_RDWR) and issuing this ioctl to initialize it:
struct ifreq req;
memset(&req, 0, sizeof(req));
req.ifr_flags = IFF_TUN; // or IFF_TAP
strncpy(req.ifr_name, "tunnel%d", IFNAMSIZ); // optional; leave it blank to get a default name; you don't have to have a %d
ioctl(fd, TUNSETIFF, &req); // error check omitted for demonstration
// req.ifr_name now contains the name that was actually selected
After the ioctl you have a virtual network interface in your system. You can configure IP addresses, routes, whatever.
Any time the kernel sends a packet out through your interface it will go into a queue and you'll be able to read it. Any time you write to the interface the kernel will process it as if it's a real packet that just arrived.
You will need to configure networking like it's a real interface. Set up a static route so that 192.172.0.0/16 (or whatever your subnet is) is reached through the tunnel interface. I'm not sure if Linux will let you do this without giving it an address; you might have to give it a dummy address like 192.172.255.254. Or a completely unrelated address like 1.2.3.4 and then let Linux think there's another router in front of your cellphone subnet. Or maybe it will just work without an address - not sure.
The difference between "tun" and "tap" is whether Ethernet processing happens or not (IP tunnel vs Ethernet tap). I expect tun is right for your application. If you choose tap then Linux will also use ARP and so on, and the interface will certainly need an address.
You might find it convenient to use the tunnel interface in both directions, or just one. IP packets aren't required to take the same route in both directions. This is the "correct" way to implement a tunnel, so you might find that a lot of mysterious bugs go away by using it.
It's the first time I use monitor mode in pcap. I think I start the monitor mode successfully since I can see that there is an "eye" symbol on wifi.
However, I still cannot capture packets not sent to me :(
I use handle but not sure how it works and how can I capture those packets not sent to me.
Generally will the router just send the packets to you which are addressed to you. This includes packets to you directly or broadcast messages. The messages sent to other devices in the network are not reaching your machine at all, therefore it's impossible to capture it.
If you really have to monitor the whole network traffic you need to get somewhere inbetween the router and the network. Or you could try a man in the middle attack on your wifi.
PCAP will only display traffic sent to you. This is true of any sniffer, the software needs to be able to see the traffic. In order to see WiFi traffic that is not sent to you, you will need a WiFi adapter that supports monitor mode. Approx 90% of WiFi adapters, or more, do not support monitor mode. Both the hardware has to be capable to enter the RFMON mode and the driver for the adapter needs to support monitor mode. If monitor mode is set up correctly, you will see 802.11 management traffic (beacons, probes, etc). I don't think monitor mode will show you actual data traffic but I am not sure and maybe it's only my adapter that doesn't show it. If you can see data where the source and dest MAC address are not the MAC address of your adapter and not FF:FF:FF:FF:FF:FF (broadcast) than you are using monitor mode. I don't know which OS you are using and I don't know what handle is (program name?) so I can't help there. I would suggest that you set the adapter into monitor mode and than verify by running wireshark on the device and look at the traffic. If that works you can go back to PCAP and debug from there.
If you are using Linux and your adapter supports monitor mode, you can enable it by running the following commands as root
ip link set wlan0 down
iwconfig wlan0 mode monitor
ip link set wlan0 promisc on
ip link set wlan0 up
Note that if a adapter is in monitor mode, it cannot be connected to a local WiFi network. The adapter would need to be in managed mode where the WiFi AP manages what type of data an adapter receives (frequency, channel, etc). If you are connected to a local WLAN via the adapter than you are not in monitor mode.
Oh! I think I remember hearing somewhere that WinPCAP doesn't support monitor mode. I don't use Windows so you may want to verify that.
I need to transfer data via pyzmq through two computers connected by an ethernet cable. I have already set up a script that runs on the same computer correctly, but I need to find the tcp address of the other computer in order to communicate. They both run Ubuntu 14.04. One of them should be a server processing requests while the other sends requests. How do I transfer data over tcp through ethernet? I simply need a way to find the address.
EDIT: (Clarification) I am running a behavioural study. I have a program called OpenSesame which runs in python and takes python scripts. I need a participant to be able to sit at a computer and be able to ask another person questions (specifically for help in a task). I need a server (using pyzmq preferably) to be connected by ethernet and communicate with that computer. It wrote a script. It works on the same computer, but not over ethernet. I need to find the address
Tcp is a protocol that uses an internet connection to Transfer data, through an IP address and specific port, you have to ensure that those ip directions are in the same range and uses the same port. For example: one pc 192.168.1.50 and another pc 192.168.1.60 in 502 port. The easiest way is using a Modem and set an statical address for each pc.
In the following link, you can find easily in which ip direction is connected your Computer. http://www.howtogeek.com/howto/17012/how-to-find-your-ip-address-in-ubuntu/
Maybe you could periodically send datagram message containing peer's ip address (or some other useful information) to broadcast address, to allow other peers to discover it. And after peer's address is dicovered you can estabish connection via ZeroMQ or other kind... connection. :)
I'm running Python 2.6.5 on ec2 and I've replaced the old ftplib with the newer one from Python2.7 that allows importing of FTP_TLS. Yet the following hangs up on me:
from ftplib import FTP_TLS
ftp = FTP_TLS('host', 'username', 'password')
ftp.retrlines('LIST') (Times out after 15-20 min)
I'm able to run these three lines successfully in a matter of seconds on my local machine, but it fails on ec2. Any idea as to why this is?
Thanks.
It certainly sounds like a problem related to whether or not you're in PASSIVE mode on your FTP connection, and whether both ends of the connection can support it.
The ftplib documentations suggests that it is on by default, which is a shame, because I was going to suggest that you turn it on. Instead, I'll suggest that you set_debuglevel to where you can see the lower levels of the protocol happening and see what mode you're in. That should give you information on how to proceed. Either you're in passive mode and the other end can't deal with it properly, or (hopefully) you'd not, but you should be.
FTP and FTPS (but not SFTP) can be configured so that the server makes a backwards connection to the client for the actual transfers or so that the client makes a second forward connection to the server for the transfers. The former, especially, is prone to complications whenever network address translation is involved. Without the TLS, some firewalls can actually rewrite the FTP session traffic to make it magically work, but with TLS that's impossible due to encryption.
The fact that are presumably authenticating and then timing out when you try to transfer data (LIST requires a 2nd connection in one direction or the other) is the classic symptom, usually, of a setup that either needs passive mode, OR, there's this:
Connect as usual to port 21 implicitly securing* the FTP control connection before authenticating. Securing the data connection requires the user to explicitly ask for it by calling the prot_p() method.
ftps.prot_p() # switch to secure data connection
ftps.retrlines('LIST') # list directory content securely
I don't work with FTPS often, since SFTP is so much less problematic, but if you're not doing that, the far end server might not be cooperating.
*note, I suspect this sentence is trying to say that FTP_TLS "implicitly secures the FTP control connection" in contrast with the explicit securing of the data connection.
If you're still having trouble could you try ruling out Amazon firewall problems. (I'm assuming you're not using a host based firewall.)
If your EC2 instance is in a VPC then in the AWS Management Console could you:
ensure you have an internet gateway
ensure that the subnet your EC2 instance is in has a default route (0.0.0.0/0) configured pointing at the internet gateway
in the Security Group for both inbound and outbound allow All Traffic from all sources (0.0.0.0/0)
in the Network ACLs for both inbound and outbound allow All Traffic from all sources (0.0.0.0/0)
If your EC2 instance is NOT in a VPC then in the AWS Management Console could you:
in the Security Group for inbound allow All Traffic from all sources (0.0.0.0/0)
Only do this in a test environment! (obviously)
This will open your EC2 instance up to all traffic from the internet. Hopefully you'll find that your FTPS is now working. Then you can gradually reapply the security rules until you find out the cause of the problem. If it's still not working then the AWS firewall is not the cause of the problem (or you have more than one problem).