User Controls
Open Ports Changing
-
2017-01-22 at 4:14 AM UTCWhat is with certain open ports changing? Right after I scan them, they change.
Not just on my phone but also on certain servers. I've noticed that there are three on my phone, and after I scan the first, it changes all three to lower port numbers. Consistently. -
2017-01-22 at 6:40 PM UTCI'm not sure what you mean, can you give an example? Are you using nmap?.
So you scan and see say 1022, 1023, and 1024. Then on the subsequnt scan you see 52, 53, and 54 open?
I haven't seen this before, it's possible servers have a nmap honey pot or something, but not your phone. Open and closed states may change depending on the applications running, but that should be relatively consistent. -
2017-01-23 at 1:03 AM UTCThe ports are always above 30,000. Im scanning using an app I made for my phone, it uses Java to attempt to connect to ports in sequential order(but I plan to change the order in which it scans).
So I start scanning and let's say it's coming up on the 50*** region, and no open ports have been detected yet. There will be ports like 52124, 52156, and 52192, all open. If I immediately go back and start a scan at 52000, no ports will have been detected open in the whole 52*** region. However, if I go back again but all the way to like 40000, three open ports will be detected in this area, but if I go back and rescan them, they are all closed and have opened somewhere else. They usually open up a little ways back(in sequential).
Like this...
I start the scan at 30000 and see that these ports are open - 52123, 52155, 52198
I start a new scan at 30000 and see that these ports are open - 49248, 49311, 49354 (The previous open ports are now closed)
I start a new scan at 30000 and see that these ports are open - 45567, 45591, 46875 (The previous open ports are now closed)
I start a new scan at 30000 and see that these ports are open - 41587, 41631, 41672 (The previous open ports are now closed)
I start a new scan at 30000 and see that these ports are open - 39874, 39912, 39945 (The previous open ports are now closed)
My phone does not have root access and is fairly new. -
2017-01-23 at 1:48 AM UTCThat's odd, can you sanity check using nmap on a different computer to scan your phone. Also on my computer I'm able to run "nmap localhost" and it is able to see the privileged <1024 ports that are open even without root, although it may be doing some fancy tricks to pull that off.
nmap -p0-65535 192.168.1.99
Mine is showing the same 2 ports open, 40k and 50k, 1 out of the ~5 or so times it showed a high numbered enhancemented port. Ok now they are all showing closed...
On your phone do this to show what is using the ports.
netstat -an
For example the following line shows I'm listening for on port 22 and it can be any address or interface on my machine (eth, wifi, localhost, etc.)
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
Other established connections and whatnot will show up, but I think only LISTEN means it will show up as "open" in a port scan. -
2017-01-23 at 4:32 AM UTCThe weirdest thing is, it's not doing it now. I know it was before, and I was literally checking over and over again. But it's not doing it now. With this new phone, I do get a strange message occasionally, and I believe it's bloatware. So maybe I just need to root and remove the bloatware.
Also, running 'netstat -an' I can see the open ports, but I can't see what program is running them. Also, I don't think 'netstat' shows all opened ports. When I browse this site on my phone, it's technically opening ports for the communication, I don't think 'netstat' shows those. Running 'cat proc/net/tcp' will show those ports though. -
2017-01-23 at 4:53 AM UTCthey're probably ftp connectback ports
-
2017-01-24 at 12:53 AM UTC
Originally posted by SBTlauien Also, running 'netstat -an' I can see the open ports, but I can't see what program is running them.
I was wrong about this, I saw the "Active UNIX doman sockets" and thought it was showing what processes were using the network, but it seems to be completely unrelated. The first part "Active Internet connections" is the relevant info, though again it doesn't show the process.Also, I don't think 'netstat' shows all opened ports. When I browse this site on my phone, it's technically opening ports for the communication, I don't think 'netstat' shows those. Running 'cat proc/net/tcp' will show those ports though.
With the "-an" flag I see both my open ports and connections to websites and other servers (same as what I see in /proc/net/tcp).
Post last edited by Merlin at 2017-01-24T00:55:54.978212+00:00 -
2017-01-24 at 7:21 AM UTCSo what exactly is in proc/net/{tcp, tcp6, udp, udp6}? How is this different than running 'netstat' aside from the way it's presented?
Also, aren't most types of Linux rootkits designed to install a new 'netstat' that won't show it's own connections? Since the proc/net/{tcp, tcp6, udp, udp6} files are updated via the Kernal, wouldn't it be much more difficult for malware to edit/change the files? -
2017-01-27 at 12:55 AM UTC
Originally posted by SBTlauien So what exactly is in proc/net/{tcp, tcp6, udp, udp6}? How is this different than running 'netstat' aside from the way it's presented?
I think that's it, though I didn't carefully compare both side by side they seem to be the same. I also see listening connections in netstat which won't show up in /proc/net.Also, aren't most types of Linux rootkits designed to install a new 'netstat' that won't show it's own connections? Since the proc/net/{tcp, tcp6, udp, udp6} files are updated via the Kernal, wouldn't it be much more difficult for malware to edit/change the files?
I've never heard that, I could believe it. But I think all those /proc files are written from the kernel for your own benefit, the system doesn't really require the file there (well other programs might), so I bet it would be feasible to have an open connection which doesn't advertise itself. -
2017-01-28 at 7:12 AM UTCOn my phone, it appears to me as if 'netstat' doesn't show nearly as much as the files in /proc/net.
Being that 'netstat' is a program that is ran to see the open connections, couldn't it be overwritten with another program? And because the files in /proc/net are directly written to via the kernel, wouldn't that be a problem for malware(if someone checks the files)? -
2017-01-28 at 7:31 AM UTC
Originally posted by SBTlauien On my phone, it appears to me as if 'netstat' doesn't show nearly as much as the files in /proc/net.
Being that 'netstat' is a program that is ran to see the open connections, couldn't it be overwritten with another program? And because the files in /proc/net are directly written to via the kernel, wouldn't that be a problem for malware(if someone checks the files)?
What if you compare the output from `sudo netstat -ap` to /proc/net? The former is much more comprehensive when i run it on my machine than the latter. The benefit of the `p` flag is seeing what processes are involved. But i suppose to see all processes on your phone you should indeed have root access. -
2017-01-29 at 3:34 AM UTC
Originally posted by SBTlauien On my phone, it appears to me as if 'netstat' doesn't show nearly as much as the files in /proc/net.
Perhaps if I have time I will parse both and see how they compare. They should really be the same, I wouldn't even be surprised if netstat read directly from the proc files.Being that 'netstat' is a program that is ran to see the open connections, couldn't it be overwritten with another program? And because the files in /proc/net are directly written to via the kernel, wouldn't that be a problem for malware(if someone checks the files)?
Yes the netstat binary could be replaced easy. I don't think a kernel can become infected, but you could get a bad download which is infected (would this still be considered a rootkit?) or the current kernel replaced with an infected one. And that could be selective about what it writes to file.
Linux Mint website/ftp was hacked once and the download was replaced with a bad one. So it could definitely happen. -
2017-01-29 at 3:37 AM UTCOh yeah and as to port scanning. Are you scanning localhost when you notice this? I was doing this with a program I wrote in C and noticed similar behavior. It would pick up 1 - 3 random high number ports sometimes that nmap never got. It's possible things are using localhost internally, maybe something will turn on for the localhost connection but not the actual ip... I don't really know, but this kind of thing is called port knocking.
-
2017-01-29 at 4:27 AM UTCTry and TelNET to the port when it appears and see what you get, if anything.
-
2017-01-29 at 6:23 AM UTC
Originally posted by Sophie But i suppose to see all processes on your phone you should indeed have root access.
Exactly. I don't currently have root access on this phone. It appears to me, as if 'netstat' in general, does not produce as much output as 'proc/net/...'.
I think I may have figured something out though, but I'm not sure. When I was checking the 'proc/net/...' files, I was also running a port scan on my device. I think this port scan was causing ports to open(it must have, to be able to check for open ports) and I was seeing some of those pop up in the /proc/net/... files. However, when checking while not running a port scan, I still see a bunch of open ports.
Now, I made the app in my phone so that I can go directly from the portscan activity, to the 'open ports' activity(this simply lists the four files /proc/net/{tcp, tcp6, udp, udp6), and it'll enhancement out everything except for the open ports that was sent from the portscan activity. Make sense? I've noticed that even though some of these ports are open on my phone, they don't have an established remote connection. -
2017-01-29 at 3:57 PM UTCYou can't open a port that's not already open, with a port scan. You can full or half connect to it, but that's it.The following users say it would be alright if the author of this post didn't die in a fire!
-
2017-01-29 at 7:18 PM UTC
Originally posted by -SpectraL You can't open a port that's not already open, with a port scan. You can full or half connect to it, but that's it.
In order to connect to a remote port, wouldn't I need to at least open a port on my device? From my understanding, a port scan tries to connect to a port to see if the connection is successful. -
2017-01-29 at 8:06 PM UTC
Originally posted by SBTlauien In order to connect to a remote port, wouldn't I need to at least open a port on my device? …
Yes, but you were talking about connecting to a remote machine and that port opening due to being scanned.
-
2017-01-29 at 10:13 PM UTC
Originally posted by -SpectraL Yes, but you were talking about connecting to a remote machine and that port opening due to being scanned.
I was? Where? The port scanning that I've been talking about, has been directed at my own device, simply to find out which ports are open. -
2017-01-29 at 11:55 PM UTCWhen you connect to a website at say niggasin.space:80 (wtf lanny no ssl?), your computer will pick a random source port to use. I don't know how it works, but these don't show up as open. I'm not really sure how it works and how these don't show open but still recieve packets. In the case of TCP it probably just ignores any new connection attempts, but how could UDP know one way or the other?
I'm seeing the same and only when I do it locally. For example a line like this showed up:
tcp 0 0 192.168.99.99:35062 192.168.99.99:35062 TIME_WAIT
Then it disappears. Same port showed up in my scan. This must have been triggered by the scan.
If I toggle my interface and then scan, so it's completely clean, I only get the expected ports. Then the next run I get a bunch of random high numbered ones.
Also the port isn't open/LISTEN according to netstat. If my program says open it's because I successfully opened a socket and did the 4 tcp handshake. And for some reason nmap enhancements these out.
I want to say it's connecting to itself/hasn't fully given up on the connection. Is this possible? It does seems like a small chance the src and dst ports would be flipped like that.
scan 1:
---src:33333 dst:4444 ---syn--->
X
X
X
scan 2:
---src:4444 dst:3333 ---syn--->
<------ acks scan 1 -------
