I am playing around with netcat for a while. I was trying to create a reverse shell from my laptop to a virtualserver. The command I typed in was the following ncat -lkvnp 4444.
After some time, several connections were established from different ip addresses, including 185.220.101.147, 185.220.101.243 (which are both Tor Exit Routers) and 195.74.76.194 which is hosted by avast.com
I don't know much about the TOR network or how antivirus systems work. Does someone know what is going on?
This was the output one minute ago:
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 95.211.190.199.
Ncat: Connection from 95.211.190.199:29248.
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
Ncat: Connection from 185.189.167.14.
Ncat: Connection from 185.189.167.14:52399.
�
Both Ip addresses are unknown to me.
It could be just a zombie army of machines, controlled by malware, looking for another victims.
Machines running old TOR clients, can be hacked, as know vulnerabilities may be exploited by experts or just script kiddies with Metaexploit.
Your IP is part of ASN (Autonomous system).
They target anything inside that IP range.
Continuously scanning everything live that responds to knows ports, like your 4444 or 22 (SSH), 3389 (RDP), 5900 (VNC) and so on.
That's why a good and easy measure of security, is change the port number to another random one, that only you knows what.
Trying to guess what that port is, by protocol inspection, is time consuming and discourage malicious activity.
EDIT: Getting attacked by a machine owned by Avast, seems that they are searching for it intentionally with their own software. Port 4444 is not part of TOR protocol (9050 or 9150), but a known windows security flaw exploited by Msblast Worm:
https://www.microsoft.com/en-us/wdsi/threats/threat-search?query=Virus%253aDOS%252f4444
Related
I got a notification from my kaspersky antivirus on my windows 10 (which is always on)
Apparently, there was a port scan and it was blocked.
User: NT AUTHORITY\SYSTEM
User type: System user
Component: Network Attack Blocker
Result description: Blocked
Name: Scan.Generic.PortScan.TCP
Object: TCP from 104.152.52.xxx at 192.168.0.10:1701
Additional: 192.168.0.10
Databases release date: Yesterday, 1/19/2022 12:34:00 PM
192.168.0.10 is a virtual machine running debian; I have UFW on this debian and port 1701 is not in any UFW rules. (so it's not allowed)
I have done a grep on the ports of the debian VM using: sudo netstat -tulpn | grep 1701 Found nothing
I assume the port scan has been done on all the machines in my network?
How can I find out where the scan comes from?
What are the consequences? What should I do next?
So from what i understand of what you published, 104.152.52.xxx made a scan. What's odd is how could he effectively reach your machine at 192.168.0.10, so i believe you have port forwarding enabled on your router. *-{see edit}
I also assume that the IP address of your VM is bind directly to your home network 192.168.0.0\24 (and not in a sub network on Windows 10). So your router should be accessible at 192.168.0.1 (or 192.168.0.254 sometimes)
Consequences of a scan ?
most likely, none, except if you have some port opens, kaspersky blocked the 1701, but probably other ports have been scanned. So verify the configuration of your router
Is it normal ?
Yes. Every device accessible from internet is constantly scanned. Always.
What to do next ?
Make sure no port-forwarding is enabled on your router
If port forwarding is enable, and needed. Make sure the software behind it is secured and up to date. if you have a password access, the password should be strong. If you have an SSH server, deactivate the authentication by password and activate the authentication by public key.
== EDIT ==
Other possibility than port forwarding and seems to be the answer:
If the VM is in a DMZ, then all unassigned ports on the router may be (depends on the router) redirected to the VM, therefore, a scan on the public ip address, would result on a scan on the VM.
I'm working on a custom yocto Linux for a Raspberry PI 3 and try to get the WIFI connection working with SSH. However when trying to connect from my PC (Ubuntu 19.10, SSH OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 May 2019) to the PI on which Dropbear v2019.78 runs, the connection attempt times out. But only when I try this via SSH, and via wlan0. Other TCP/IP traffic works, and also using the same participants but with eth0. As this is for a robot, I would prefer to not use a tether though...
To try & debug this, I
enabled a serial console so I can work on the PI
disabled eth0
started a tcpdump on the PI (ip.host == 192.168.0.105)
started a tcpdump on the PC (ip.host == 192.168.0.106)
used a dirt-simple TCP/IP socket example written in Python (taken from https://realpython.com/python-sockets/#echo-server) to verify I can in fact communicate. The transmission is successful. I am aware that the example is lacking (no proper protocol etc), but that's not the point of it. It just works enough. The PI runs the server listening on port 2222.
attempted a SSH connection, it timed out.
I filtered the resulting PCAP down to contain just TCP, as there is other information (e.g. Dropbox discovery) that I don't think matters and might potentially be information leaking. On the host side (enp4s0-tcp-and-pi.pcap) I also filtered with ip.host == 192.168.0.105 to only contain any traffic to the PI.
Another note on my setup here: I use a TP-Link router which LAN ports the PC is connected to, and who provides the 2.4GHz WIFI for the PI. So both are part of the same subnet, and no special routing or anything is configured.
Also I stopped the dropbear daemon and adapted my Python code to use port 22. It works.
I'm only broadly aware of the inner workings of TCP, so I can't really make much sense of the things I see here. Any insights are more than welcome.
https://www.dropbox.com/s/5o4rqr5zdws2wq7/wlan0-tcp-only.pcap?dl=0
https://www.dropbox.com/s/amypjtk1nvja4qb/enp4s0-tcp-and-pi.pcap?dl=0
This is what I am trying to do:
I have a windows computer and a Linux computer (ubuntu 16.10) connected to the same wireless router. The router is not connected to the Internet, as this might raise some security concerns (and we don't want the windows computer to talk to the net).
The windows computer is running a program that is supposed to stream data to an UPD port (say port 1234). Using the Microsoft TCPView utility I can see that the windows machine opens the port. In fact, it should allow connections from any IP address and any port (that's what the *'s mean in TCPView).
View of the TCPView Utility
When I try to find the open port on the windows machine from the Linux computer using nmap this is what happens:
Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-30 16:50 EST
Nmap scan report for 192.168.0.164
Host is up (0.051s latency).
PORT STATE SERVICE
1510/udp open|filtered mvx-lm
MAC Address: 74:DE:2B:D8:26:24 (Liteon Technology)
At the very least, this tells me that the linux machine can see the windows machine (I can also ping it). However, I am not sure about the open|filtered state of the port. According to the Nmap manual:
Nmap places ports in this state when it is unable to determine whether
a port is open or filtered. This occurs for scan types in which open
ports give no response. The lack of response could also mean that a
packet filter dropped the probe or any response it elicited. So Nmap
does not know for sure whether the port is open or being filtered. The
UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.
When I try to connect to the port using Python, an error occurs. This code
import socket
UDP_IP = "192.168.0.164"
UDP_PORT = 1234
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
results in an error 'connection refused'. A little C++ client program that is supposed to read out the streamed data also fails to connect to the port. I am using Python now to test the accessibility of the port more quickly.
In contrast, connecting to TCP port 8080 works fine. Also, I have been sending data back and forth over TCP through the same router between other machines and using a range of ports.
Other important info:
The same errors occur if I switch off the firewall and virus scanner on the windows machine
I have added UDP port 1234 as an allowed connection in the advanced firewall settings of windows.
So, my questions are:
Does anybody have any suggestions about how to debug/solve this situation?
What's different between UDP and TCP that would cause TCP to work without a hiccup (in my past projects) and causes UDP to give me nightmares?
You are forgetting that UDP is not a connection-based protocol. It is a datagram protocol.
There is no way to distinguish between a server that is receiving UDP packets but not responding to them, from a server which is behind a firewall which drops those packets. This is why nmap is describing a port as open|filtered -- there is no way for it to tell the difference.
Your call to sock.bind is failing because you are trying to bind (that is, to start listening for packets!) to a port on a remote IP. This is impossible in general.
It turns out that my problems were two-fold
1) I did have a bad understanding of the UDP protocol. That's been rectified by the answers in the forum. For anyone interested in how to use UDP and Python to communicate between two computers, see this recipe: http://code.activestate.com/recipes/578802-send-messages-between-computers/
2) The windows program that I was trying to communicate with can not be used to to send data over UDP through wifi. Why? I don't know. I called the developer and that's what he told me.
Current status: the problem is not solved but is diagnosed as a combination of my lack of knowledge and an ideosyncratic windows program (see my original post above)
You are trying to bind to a non-local IP address. Use 0.0.0.0 instead of the target address you're using, and connect() or sendto() the target address.
I have an online game server running on a vps with linux centos and it keeps dropping players to 0 from time to time, i have discarded problems with the application itself because it does not crash or anything, the players just get disconnected.
I was monitoring packets on my game server port with tcpdump and i caught when that happened and i noticed that an ip adress sent packets without the numerical port like usual (i belive the ip."number" is the ip.port), but is this IP.number the port?
look at the screenshoot:
http://postimg.org/image/6c4k2sdqp/
Differently of all the other normal connections it doesn't send the numerical port, and suddenly the packet listing on the tcpdump stops and my players get dropped from the server.
I was wondering if it was that wich made the connections get dropped for some reason
What's happening here is that the smart-lm port is found in the system services list:
❯❯❯ grep smart-lm /etc/services
smart-lm 1608/udp # Smart Corp. License Manager
smart-lm 1608/tcp # Smart Corp. License Manager
And so tcpdump is showing that instead of .1608 on the end. It may be a firewall between your network and the remote side (including a firewall or router on the remote side) that's causing the problem.
I have just installed a mainframe emulator and I have problems for running it. I think the problem is my 3270 TCP port. Reading a guide I found somebody say that you can do this:
telnet 127.0.0.1 3270
but when I try the answer is:
The connection to the host it can't be opened with port 3270 more or less
(I have windows in spanish) . Error on the connection.
Do you know how can I get connection with this direction and this port?
If I understand you correctly, you are trying to eliminate issues with your 3270 emulator configuration by attempting to telnet to the mainframe from the PC. Again, if my understanding is correct, then you need to use
telnet <ip or hostname of the mainframe>
In your example, you are using the local loopback address.
It is unlikely that you should be using port 3270. 3270 connections are typically configured on port 23, which is the default telnet port.
If the connection to the mainframe is successful, you can input any character string in the terminal and then press Enter.
An error such as this:
IKJ56710I INVALID USERID,xxxx
Will validate the fact that the port is open and that your emulator issues are down to something other than network problems (probably local configuration).