Open ports on my box, can they be explained?

SuperDude123 · 11-02-2008, 01:08 AM

I just ran an port scanning tool on my Mac (nmap 4.76...good/bad?) and it found the following ports on my Damn Small Linux box:

PORT STATE SERVICE VERSION
3659/udp open|filtered unknown
6970/udp open|filtered unknown
16498/udp open|filtered unknown
16838/udp open|filtered unknown
19022/udp open|filtered unknown
20004/udp open|filtered unknown
28973/udp open|filtered unknown
49213/udp open|filtered unknown

So what should I do if I plan on having the system on the web as a sftp server?

Also, its odd, but this scan didn't show port 22 witch should be open if I'm connecting to the system via ssh.

win32sux · 11-02-2008, 01:14 AM

Quote:

Originally Posted by SuperDude123

I just ran an port scanning tool on my Mac (nmap 4.76...good/bad?) and it found the following ports on my Damn Small Linux box:

PORT STATE SERVICE VERSION
3659/udp open|filtered unknown
6970/udp open|filtered unknown
16498/udp open|filtered unknown
16838/udp open|filtered unknown
19022/udp open|filtered unknown
20004/udp open|filtered unknown
28973/udp open|filtered unknown
49213/udp open|filtered unknown

So what should I do if I plan on having the system on the web as a sftp server?

From man nmap:

Quote:

open|filtered
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.

Quote:

UDP scan works by sending an empty (no data) UDP header to every targeted port. If an ICMP port unreachable error (type 3, code 3) is
returned, the port is closed. Other ICMP unreachable errors (type 3, codes 1, 2, 9, 10, or 13) mark the port as filtered. Occasionally, a
service will respond with a UDP packet, proving that it is open. If no response is received after retransmissions, the port is classified as
open|filtered. This means that the port could be open, or perhaps packet filters are blocking the communication. Versions scan (-sV) can be
used to help differentiate the truly open ports from the filtered ones.

Quote:

Originally Posted by SuperDude123

Also, its odd, but this scan didn't show port 22 witch should be open if I'm connecting to the system via ssh.

Maybe post the actual command you used to scan?

SuperDude123 · 11-02-2008, 01:26 AM

I used the feature called "Slow Comprehensive scan"

I just ran a "Intense scan, all TCP ports" and this is what I got:

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.6.1p2 Debian 1:3.6.1p2-9 (protocol 1.99)
|_ SSH Protocol Version 1: Server supports SSHv1
68/tcp open tcpwrapped
MAC Address: ##:##:A#:##:AA:## (Cameo Communications)
Device type: general purpose
Running: Linux 2.4.X
OS details: Linux 2.4.18 - 2.4.32 (likely embedded)
Uptime guess: 0.058 days (since Sun Nov 2 01:57:39 2008)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=193 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux

Would you worry about "Network Distance" or "TCP Sequence Prediction" ?

win32sux · 11-02-2008, 01:37 AM

Quote:

Originally Posted by SuperDude123

I used the feature called "Slow Comprehensive scan"

I just ran a "Intense scan, all TCP ports" and this is what I got:

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.6.1p2 Debian 1:3.6.1p2-9 (protocol 1.99)
|_ SSH Protocol Version 1: Server supports SSHv1
68/tcp open tcpwrapped
MAC Address: ##:##:A#:##:AA:## (Cameo Communications)
Device type: general purpose
Running: Linux 2.4.X
OS details: Linux 2.4.18 - 2.4.32 (likely embedded)
Uptime guess: 0.058 days (since Sun Nov 2 01:57:39 2008)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=193 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux

Would you worry about "Network Distance" or "TCP Sequence Prediction" ?

Unless you aren't one hop away (in other words, that you aren't on the same LAN as the box you scanned) then there isn't anything wrong with that distance. You can read about TCP sequence prediction in chapter 8 of the book. "Good luck!" means that you seem to be in good shape, but you'll need to check other things to be certain, as is explained in the book.

BTW, going back to the question about the "open|filtered" UDP ports: If wanna see what UDP ports you have open for real, a quick and easy way is to simply change your policy to REJECT and then run the UDP scan again. Any UDP port which you have open will show as open that way.

PS/EDIT: If you don't need SSHv1 then you really should disable it. The report you posted indicates you have it enabled, but I don't know if it's a false positive or not. You should check.