When i try to capture FTP packets tcpdump only captures packets which have not text from transmitted .txt file - they are only contains information about my command, directory etc.
I've used this command:
tcpdump src x.x.x.x and dst x.x.x.x and port ftp
try
tcpdump 'src x.x.x.x and dst x.x.x.x and (port ftp or ftp-data)'
(per http://www.tcpdump.org/tcpdump_man.html )
Related
elasticsearch==7.10.0
I wish to ping local host '5601' to ensure kibana is running or not but apparently unable to ping.
Note: I am aware that elastic search has in-built function to ping but I still wish to ping using cmd line for a specific reason in my project.
C:\User>ping 5601
Pinging f00:b00:f00:b00 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
Ping statistics for f00:b00:f00:b00:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
C:\User>ping http://localhost:5601
Ping request could not find host http://localhost:5601. Please check the name and try again.
Could someone help me?
You can use netstat to check if the port exposed by the Kibana UI, 5061 is in LISTEN mode
$ netstat -tlpn | grep 5601
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp6 0 0 :::5601 :::* LISTEN -
Or if you want to establish a connection to destination port 5601 you can use nc
$ nc -vz localhost 5601
Connection to localhost 5601 port [tcp/*] succeeded!
Sending a UDP packet from Ruby client to Ruby server using the server address 192.168.1.30 works as expected, but only if client and server are on the same host. If the client runs on a different machine, the UDP packet finds its way to the server, but my server process won't notice.
Server:
require 'socket'
sock = UDPSocket.new()
sock.bind('', 8999)
p sock
while true do
p sock.recvfrom(2000)
end
sock.close
Client:
require 'socket'
sock = UDPSocket.new
p sock.send("foo", 0, "192.168.1.30", 8999)
sock.close
After starting the server, netstat -n --udp --listen approves that the socket is open:
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:8999 0.0.0.0:*
After running the client twice (on 192.168.1.30 and on .23), server output shows only one incoming packet, missing the one from 192.168.1.23:
#<UDPSocket:fd 7, AF_INET, 0.0.0.0, 8999>
["foo", ["AF_INET", 52187, "192.168.1.30", "192.168.1.30"]]
while Wireshark indicates that two packets were noticed
No Time Source Destination Proto Length Info
1 0.000000000 192.168.1.30 192.168.1.30 UDP 47 52187 → 8999 Len=3
2 2.804243569 192.168.1.23 192.168.1.30 UDP 62 39800 → 8999 Len=3
Which probably obvious detail am I missing?
Check if you have any firewall rules active:
sudo iptables -L
sudo ufw status
I have a file called test1.pcap which contains ICMP, ARP, and UDP messages. I want to read test1.pcap and write to test2.pcap with only UDP messages.
I tried the following:
tcpdump -r test1.pcap udp -w test2.pcap
but the non udp messages - ICMP and ARP still show up in test2.pcap. I used wireshark to view the results.
Any suggestions?
I need to sniff voip traffic on 5060 port.
And at the same time I need to exclude all packets where src port 5060 and dst port 5061
I need something like:
tcpdump -i any -vvv -s0 port 5060 and (not src port 5060 and not dst port 5061)
but the second part of the filter should be related to a single packet, not all traffic. How can I do that?
Try
port 5060 and not (src port 5060 and dst port 5061)
I am using LFTP to transfer files from a server, which unfortunately does not recognize the PORT command. I do not have control over the server (do not know in detail what server is) and I have to use the active mode.
This is the command line as:
lftp -e 'debug 10;set ftp:passive-mode off; set ftp:auto-passive-mode no; ls; bye;' -u user,password ftp://ftp.site.com
This is the debug output:
<--- 200 Using default language en_US
---> OPTS UTF8 ON
<--- 200 UTF8 set to on
---> OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
<--- 200 OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
---> USER xxxxx
<--- 331 Password required for xxxxx
---> PASS xxxxxx
<--- 230 User xxxxx logged in
---> PBSZ 0
<--- 200 PBSZ 0 successful
---> PROT P
<--- 200 Protection set to Private
---> PORT 172,16,133,11,146,168
<--- 500 Illegal PORT command
---> LIST
---> ABOR
---- Closing aborted data socket
---- Chiusura del socket di controllo
It seems that LFTP renounces to connect to data socket because the remote server does not support the PORT command. Is there a way to convince LFTP can still connect to port 20? By FTP manual obviously no problem.
The issue, I think, is not that the FTP server doesn't support the PORT command (it does), but rather, it doesn't like the IP address/port that your FTP client is sending in the PORT command.
PORT 172,16,133,11,146,168
...tells the server to connect to address 172.16.133.11, port 37544*. The interesting part here is the IP address: it's an RFC 1918 address (i.e. it's a private network address). That, in turn, suggests that your FTP client is in a LAN somewhere, and is connecting to an FTP server using a public IP address.
That remote FTP server cannot connect to a private network address; by definition, RFC 1918 address are not publicly routable.
Thus it very well could be that the FTP server is trying to make a connection to the address/port given in your PORT command, fails, thus that is why the FTP server fails the command, saying:
500 Illegal PORT command
To make a PORT command work with that FTP server, you would need to discover the public IP address that that server can connect to, to reach your client machine. Let's say that this address is 1.2.3.4. Then you would need to tell lftp to use that address in its PORT command, using the ftp:port-ipv4 option.
Chances are, though, that public IP address is the address of a NAT/router/firewall, and that that NAT/router/firewall will not allow connections, from the outside world to a high numbered port (e.g. 37544), to be routed to a machine within the LAN. This is one of the issues with active FTP data transfers, i.e. FTP data transfers which use the PORT (or EPRT) commands: they are not considered "firewall-friendly".
Hope this helps!
* - why 146,168 translates to port 37544?
According to FTP's RFC959 those parameters are:
(...) 16-bit TCP port address. This address information is broken into
8-bit fields and the value of each field is transmitted as a decimal
number (in character string representation).
146 dec = 10010010 bin = A
168 dec = 10101000 bin = B
A B
10010010 10101000 bin = 37544 dec