Re: Port Scan for UDP
# netstat -anp|less that works for me all the time Without the darkness, how would you recognize the light? -Original Message- From: Ben Staffin [EMAIL PROTECTED] Date: Sat, 20 Oct 2001 23:27:09 -0500 Subject: Re: Port Scan for UDP On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp port returns the process(es) listening on the named UDP port. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: If you had actually read what I'd written, you'd see I didn't mention anywhere that nmap only scans ports listed in /etc/services. I said that nmap only scans ports mentioned in ITS OWN services file, which I assumed most people would be intelligent enough to realize was the nmap- services file (as documented in the manpage, if anyone would bother to read it). You're right that I neglected to mention that it also scans anything from 1 to 1024 even if it's not listed in the services file, though. You could have spared the TCP/UDP diff lecture since the question wasn't directed to that... The question was EXACTLY directed to that. The gentleman was asking why every UDP port scanned was being listed as open. I explained the reason for it; the firewall was dropping the UDP packets, and the way portscans work with UDP is central to that. I fail to see the lack of relevance. jc: If you own the box and *don't* have any reason to assume/think you've been compromised (Just checking) you can check locally using nice tools like: netstat -an --ip for both udp and tcp or netstat -an --udp[--tcp] for either one. lsof -i -n nmap localhost -p 1-[HigherPortNumber] fuser and the list goes on =) -- Craig McPherson Information Technology Coordinator Baptist Collegiate Ministry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: If you had actually read what I'd written, you'd see I didn't mention anywhere that nmap only scans ports listed in /etc/services. I said that nmap only scans ports mentioned in ITS OWN services file, which I assumed most people would be intelligent enough to realize was the nmap- services file (as documented in the manpage, if anyone would bother to read it). You're right that I neglected to mention that it also scans anything from 1 to 1024 even if it's not listed in the services file, though. You could have spared the TCP/UDP diff lecture since the question wasn't directed to that... The question was EXACTLY directed to that. The gentleman was asking why every UDP port scanned was being listed as open. I explained the reason for it; the firewall was dropping the UDP packets, and the way portscans work with UDP is central to that. I fail to see the lack of relevance. jc: If you own the box and *don't* have any reason to assume/think you've been compromised (Just checking) you can check locally using nice tools like: netstat -an --ip for both udp and tcp or netstat -an --udp[--tcp] for either one. lsof -i -n nmap localhost -p 1-[HigherPortNumber] fuser and the list goes on =) -- Craig McPherson Information Technology Coordinator Baptist Collegiate Ministry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
# netstat -anp|less that works for me all the time Without the darkness, how would you recognize the light? -Original Message- From: Ben Staffin [EMAIL PROTECTED] Date: Sat, 20 Oct 2001 23:27:09 -0500 Subject: Re: Port Scan for UDP On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp port returns the process(es) listening on the named UDP port. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/
Re: Port Scan for UDP
Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: If you had actually read what I'd written, you'd see I didn't mention anywhere that nmap only scans ports listed in /etc/services. I said that nmap only scans ports mentioned in ITS OWN services file, which I assumed most people would be intelligent enough to realize was the nmap- services file (as documented in the manpage, if anyone would bother to read it). You're right that I neglected to mention that it also scans anything from 1 to 1024 even if it's not listed in the services file, though. You could have spared the TCP/UDP diff lecture since the question wasn't directed to that... The question was EXACTLY directed to that. The gentleman was asking why every UDP port scanned was being listed as open. I explained the reason for it; the firewall was dropping the UDP packets, and the way portscans work with UDP is central to that. I fail to see the lack of relevance. jc: If you own the box and *don't* have any reason to assume/think you've been compromised (Just checking) you can check locally using nice tools like: netstat -an --ip for both udp and tcp or netstat -an --udp[--tcp] for either one. lsof -i -n nmap localhost -p 1-[HigherPortNumber] fuser and the list goes on =) -- Craig McPherson Information Technology Coordinator Baptist Collegiate Ministry
Re: Port Scan for UDP
Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: If you had actually read what I'd written, you'd see I didn't mention anywhere that nmap only scans ports listed in /etc/services. I said that nmap only scans ports mentioned in ITS OWN services file, which I assumed most people would be intelligent enough to realize was the nmap- services file (as documented in the manpage, if anyone would bother to read it). You're right that I neglected to mention that it also scans anything from 1 to 1024 even if it's not listed in the services file, though. You could have spared the TCP/UDP diff lecture since the question wasn't directed to that... The question was EXACTLY directed to that. The gentleman was asking why every UDP port scanned was being listed as open. I explained the reason for it; the firewall was dropping the UDP packets, and the way portscans work with UDP is central to that. I fail to see the lack of relevance. jc: If you own the box and *don't* have any reason to assume/think you've been compromised (Just checking) you can check locally using nice tools like: netstat -an --ip for both udp and tcp or netstat -an --udp[--tcp] for either one. lsof -i -n nmap localhost -p 1-[HigherPortNumber] fuser and the list goes on =) -- Craig McPherson Information Technology Coordinator Baptist Collegiate Ministry
Re: Port Scan for UDP
Hi! Take a look at /etc/inetd.conf. There are some services you are looking for. Try to comment thoose services and make a restart of the inetd daemon. (Something as `/etc/init.d/inetd stop` `/etc/init.d/inetd start') Bye -- --- Javier Coso Gutierrez Centrocom: http://www.centrocom.es E-mail: [EMAIL PROTECTED] Agencia de Comunicación Interactiva --- ningún copo de nieve se siente responsable en una avalancha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
Hi, On Sun, Oct 21, 2001 at 05:47:11PM +0200, Petre Daniel [EMAIL PROTECTED] wrote: also netstat -n -p -t --listening | grep :PORT sure, but it shows you only tcp connections. regards, Volker VD You can also use netstat -pan to find out which process is listening on VD which port. -- Volker Dormeyer * [EMAIL PROTECTED] PGP signature
Re: Port Scan for UDP
thanks for your explanation. regards, Volker On Sun, Oct 21, 2001 at 10:45:28AM -0500, Craig McPherson [EMAIL PROTECTED] wrote: I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that the TCP handshake sequence to open a connection completed), CLOSED (meaning that the target sent a port closed ICMP message), or FILTERED (meaning that no response was received at all: this is also called stealthed by so-called security experts like Steve Gibson but it's a good idea to ignore him just on general principles). UDP is a completely stateless protocol, though. Even if you send a UDP packet to a port that a valid daemon is listening on, the system isn't obligated to send anything back to you at all: there is no handshake sequence to establish a connection. So making a determination is harder than with TCP. If you receive a port closed ICMP message, the port can be safely listed as CLOSED, but if you receive nothing at all, that could mean that the port is either OPEN or FILTERED -- it's pretty much impossible to tell the difference. NMAP assumes that every UDP port that it doesn't receive a responsee from is OPEN, which means that if you have your firewall DROP all UDP connections, every UDP port will appear as open. If you want to fix this, have your firewall REJECT instead of DROP, and the ports will appear correctly as CLOSED to a port scan. DROPing connections without a response is in violation of the RFCs, too, if you care about that sort of thing. Having the local machine portscan itself will also tell you which UDP ports are *actually* open, because I assume you don't have your firewall set to DROP packets from itself. Also, did you know that by default, nmap only scans ports listed in its services file? So although it scans commonly-used ports, it's not scanning the entire system. If you have enough time (this will make the scan very slow, especially over a slow network link), use the -p 1- argument to every scan to force nmap to scan every port from 1 to 65535 instead of just the maybe 400 or 500 ports that it has listed in its services file. That's the only way you can get a complete picture of what your box looks like from the outside. I'm doing portscans on a system I'm working to learn more about securing hosts and setting up iptables. My tcp portscan reported what I expected, only www, ssh and smtp listening. The udp portscan reported a huge list of 'open' ports. I really didn't know what to expect for this scan, so I want to know if this is normal. Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. If this isn't secure behaviour, perhaps I can add an iptables entry like: iptables -A INPUT -p udp -j drop However, I don't have any applications running using udp, so the 'open' port doesn't have anywhere to go, as far as I know. Again, if someone can confirm this, I'd really appreciate it. thanks, jc -- Craig McPherson Information Technology Coordinator Baptist Collegiate Ministry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Volker Dormeyer * [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
Wow! Craig...you are the MAN! This explains a number of other questions I had too. Thank you very much! jc Craig McPherson, 2001-Oct-21 10:45 -0500: I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that the TCP handshake sequence to open a connection completed), CLOSED (meaning that the target sent a port closed ICMP message), or FILTERED (meaning that no response was received at all: this is also called stealthed by so-called security experts like Steve Gibson but it's a good idea to ignore him just on general principles). UDP is a completely stateless protocol, though. Even if you send a UDP packet to a port that a valid daemon is listening on, the system isn't obligated to send anything back to you at all: there is no handshake sequence to establish a connection. So making a determination is harder than with TCP. If you receive a port closed ICMP message, the port can be safely listed as CLOSED, but if you receive nothing at all, that could mean that the port is either OPEN or FILTERED -- it's pretty much impossible to tell the difference. NMAP assumes that every UDP port that it doesn't receive a responsee from is OPEN, which means that if you have your firewall DROP all UDP connections, every UDP port will appear as open. If you want to fix this, have your firewall REJECT instead of DROP, and the ports will appear correctly as CLOSED to a port scan. DROPing connections without a response is in violation of the RFCs, too, if you care about that sort of thing. Having the local machine portscan itself will also tell you which UDP ports are *actually* open, because I assume you don't have your firewall set to DROP packets from itself. Also, did you know that by default, nmap only scans ports listed in its services file? So although it scans commonly-used ports, it's not scanning the entire system. If you have enough time (this will make the scan very slow, especially over a slow network link), use the -p 1- argument to every scan to force nmap to scan every port from 1 to 65535 instead of just the maybe 400 or 500 ports that it has listed in its services file. That's the only way you can get a complete picture of what your box looks like from the outside. -- Jeff CoppockNortel Networks Systems Engineerhttp://nortelnetworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap. NOTE! Comes with nmap! usually located in /usr/local/share/nmap/nmap-services. You could have spared the TCP/UDP diff lecture since the question wasn't directed to that... Although you were correct about UDP and it's difficulty when it comes to remote scanning. jc: If you own the box and *don't* have any reason to assume/think you've been compromised (Just checking) you can check locally using nice tools like: netstat -an --ip for both udp and tcp or netstat -an --udp[--tcp] for either one. lsof -i -n nmap localhost -p 1-[HigherPortNumber] fuser and the list goes on =) -xbud - [EMAIL PROTECTED] I only drink to make other people interesting - On Sunday 21 October 2001 09:45 am, Craig McPherson wrote: I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that the TCP handshake sequence to open a connection completed), CLOSED (meaning that the target sent a port closed ICMP message), or FILTERED (meaning that no response was received at all: this is also called stealthed by so-called security experts like Steve Gibson but it's a good idea to ignore him just on general principles). UDP is a completely stateless protocol, though. Even if you send a UDP packet to a port that a valid daemon is listening on, the system isn't obligated to send anything back to you at all: there is no handshake sequence to establish a connection. So making a determination is harder than with TCP. If you receive a port closed ICMP message, the port can be safely listed as CLOSED, but if you receive nothing at all, that could mean that the port is either OPEN or FILTERED -- it's pretty much impossible to tell the difference. NMAP assumes that every UDP port that it doesn't receive a responsee from is OPEN, which means that if you have your firewall DROP all UDP connections, every UDP port will appear as open. If you want to fix this, have your firewall REJECT instead of DROP, and the ports will appear correctly as CLOSED to a port scan. DROPing connections without a response is in violation of the RFCs, too, if you care about that sort of thing. Having the local machine portscan itself will also tell you which UDP ports are *actually* open, because I assume you don't have your firewall set to DROP packets from itself. Also, did you know that by default, nmap only scans ports listed in its services file? So although it scans commonly-used ports, it's not scanning the entire system. If you have enough time (this will make the scan very slow, especially over a slow network link), use the -p 1- argument to every scan to force nmap to scan every port from 1 to 65535 instead of just the maybe 400 or 500 ports that it has listed in its services file. That's the only way you can get a complete picture of what your box looks like from the outside. I'm doing portscans on a system I'm working to learn more about securing hosts and setting up iptables. My tcp portscan reported what I expected, only www, ssh and smtp listening. The udp portscan reported a huge list of 'open' ports. I really didn't know what to expect for this scan, so I want to know if this is normal. Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. If this isn't secure behaviour, perhaps I can add an iptables entry like: iptables -A INPUT -p udp -j drop However, I don't have any applications running using udp, so the 'open' port doesn't have anywhere to go, as far as I know. Again, if someone can confirm this, I'd really appreciate it. thanks, jc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
On Sun, Oct 21, 2001 at 09:49:02AM -0600, orly-fu wrote: First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap. NOTE! Comes with nmap! usually located in /usr/local/share/nmap/nmap-services. Hmmm. If you'd bothered to read his post, you'd have seen that he claimed that he never claimed that nmap only checked ports listed in */etc/services*, but nmap's own services database. Don't believe me? Here's the quote (emphasis mine): Also, did you know that by default, nmap only scans ports listed in *its* services file? NOTE! No mention of /etc/services! Leaving out the detail about ports 1024 is true, but that that was not his point. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html PGP signature
Re: Port Scan for UDP
On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. Adding or removing lines in /etc/services doesn't open or close ports... this is a common misconception. Removing what's listening on a particular port is what closes that port. -- Marc Wilson [EMAIL PROTECTED] [EMAIL PROTECTED] pgpXe8pcYQxjr.pgp Description: PGP signature
Re: Port Scan for UDP
On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp port returns the process(es) listening on the named UDP port. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ pgpaNM6YoSBtN.pgp Description: PGP signature
Re: Port Scan for UDP
tony mancill, 2001-Oct-20 21:22 -0700: On Sat, 20 Oct 2001, Marc Wilson wrote: On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. Adding or removing lines in /etc/services doesn't open or close ports... this is a common misconception. Removing what's listening on a particular port is what closes that port. A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). Hmmm, so I was under that misconception. I've started looking into what processes own these 'open' ports and using lsof -i I'm not seeing processes owning these ports. It's listing port numbers for protocols I've never heard of, let alone would use. Like 1356:cuillamartin, 2024:CAIlic and a bunch way up high. I know I'm not running these apps, but I haven't checked them all yet, although there are hundreds listed. I'm wondering if my portscan was not right: nmap -sU -P0 host -- Jeff CoppockNortel Networks Systems Engineerhttp://nortelnetworks.com
Re: Port Scan for UDP
Hi, On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2001, Marc Wilson wrote: Adding or removing lines in /etc/services doesn't open or close ports... this is a common misconception. Removing what's listening on a particular port is what closes that port. A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). You can also use netstat -pan to find out which process is listening on which port. regards, Volker -- Volker Dormeyer * [EMAIL PROTECTED] pgpGr1EqzpSUn.pgp Description: PGP signature
Re: Port Scan for UDP
Hi! Take a look at /etc/inetd.conf. There are some services you are looking for. Try to comment thoose services and make a restart of the inetd daemon. (Something as `/etc/init.d/inetd stop` `/etc/init.d/inetd start') Bye -- --- Javier Coso Gutierrez Centrocom: http://www.centrocom.es E-mail: [EMAIL PROTECTED] Agencia de Comunicación Interactiva --- ningún copo de nieve se siente responsable en una avalancha
Re: Port Scan for UDP
Hi, On Sun, Oct 21, 2001 at 05:47:11PM +0200, Petre Daniel [EMAIL PROTECTED] wrote: also netstat -n -p -t --listening | grep :PORT sure, but it shows you only tcp connections. regards, Volker VD You can also use netstat -pan to find out which process is listening on VD which port. -- Volker Dormeyer * [EMAIL PROTECTED] pgpUzJJBXRgKZ.pgp Description: PGP signature
Re: Port Scan for UDP
I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that the TCP handshake sequence to open a connection completed), CLOSED (meaning that the target sent a port closed ICMP message), or FILTERED (meaning that no response was received at all: this is also called stealthed by so-called security experts like Steve Gibson but it's a good idea to ignore him just on general principles). UDP is a completely stateless protocol, though. Even if you send a UDP packet to a port that a valid daemon is listening on, the system isn't obligated to send anything back to you at all: there is no handshake sequence to establish a connection. So making a determination is harder than with TCP. If you receive a port closed ICMP message, the port can be safely listed as CLOSED, but if you receive nothing at all, that could mean that the port is either OPEN or FILTERED -- it's pretty much impossible to tell the difference. NMAP assumes that every UDP port that it doesn't receive a responsee from is OPEN, which means that if you have your firewall DROP all UDP connections, every UDP port will appear as open. If you want to fix this, have your firewall REJECT instead of DROP, and the ports will appear correctly as CLOSED to a port scan. DROPing connections without a response is in violation of the RFCs, too, if you care about that sort of thing. Having the local machine portscan itself will also tell you which UDP ports are *actually* open, because I assume you don't have your firewall set to DROP packets from itself. Also, did you know that by default, nmap only scans ports listed in its services file? So although it scans commonly-used ports, it's not scanning the entire system. If you have enough time (this will make the scan very slow, especially over a slow network link), use the -p 1- argument to every scan to force nmap to scan every port from 1 to 65535 instead of just the maybe 400 or 500 ports that it has listed in its services file. That's the only way you can get a complete picture of what your box looks like from the outside. I'm doing portscans on a system I'm working to learn more about securing hosts and setting up iptables. My tcp portscan reported what I expected, only www, ssh and smtp listening. The udp portscan reported a huge list of 'open' ports. I really didn't know what to expect for this scan, so I want to know if this is normal. Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. If this isn't secure behaviour, perhaps I can add an iptables entry like: iptables -A INPUT -p udp -j drop However, I don't have any applications running using udp, so the 'open' port doesn't have anywhere to go, as far as I know. Again, if someone can confirm this, I'd really appreciate it. thanks, jc -- Craig McPherson Information Technology Coordinator Baptist Collegiate Ministry
Re: Port Scan for UDP
thanks for your explanation. regards, Volker On Sun, Oct 21, 2001 at 10:45:28AM -0500, Craig McPherson [EMAIL PROTECTED] wrote: I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that the TCP handshake sequence to open a connection completed), CLOSED (meaning that the target sent a port closed ICMP message), or FILTERED (meaning that no response was received at all: this is also called stealthed by so-called security experts like Steve Gibson but it's a good idea to ignore him just on general principles). UDP is a completely stateless protocol, though. Even if you send a UDP packet to a port that a valid daemon is listening on, the system isn't obligated to send anything back to you at all: there is no handshake sequence to establish a connection. So making a determination is harder than with TCP. If you receive a port closed ICMP message, the port can be safely listed as CLOSED, but if you receive nothing at all, that could mean that the port is either OPEN or FILTERED -- it's pretty much impossible to tell the difference. NMAP assumes that every UDP port that it doesn't receive a responsee from is OPEN, which means that if you have your firewall DROP all UDP connections, every UDP port will appear as open. If you want to fix this, have your firewall REJECT instead of DROP, and the ports will appear correctly as CLOSED to a port scan. DROPing connections without a response is in violation of the RFCs, too, if you care about that sort of thing. Having the local machine portscan itself will also tell you which UDP ports are *actually* open, because I assume you don't have your firewall set to DROP packets from itself. Also, did you know that by default, nmap only scans ports listed in its services file? So although it scans commonly-used ports, it's not scanning the entire system. If you have enough time (this will make the scan very slow, especially over a slow network link), use the -p 1- argument to every scan to force nmap to scan every port from 1 to 65535 instead of just the maybe 400 or 500 ports that it has listed in its services file. That's the only way you can get a complete picture of what your box looks like from the outside. I'm doing portscans on a system I'm working to learn more about securing hosts and setting up iptables. My tcp portscan reported what I expected, only www, ssh and smtp listening. The udp portscan reported a huge list of 'open' ports. I really didn't know what to expect for this scan, so I want to know if this is normal. Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. If this isn't secure behaviour, perhaps I can add an iptables entry like: iptables -A INPUT -p udp -j drop However, I don't have any applications running using udp, so the 'open' port doesn't have anywhere to go, as far as I know. Again, if someone can confirm this, I'd really appreciate it. thanks, jc -- Craig McPherson Information Technology Coordinator Baptist Collegiate Ministry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Volker Dormeyer * [EMAIL PROTECTED]
Re: Port Scan for UDP
Wow! Craig...you are the MAN! This explains a number of other questions I had too. Thank you very much! jc Craig McPherson, 2001-Oct-21 10:45 -0500: I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that the TCP handshake sequence to open a connection completed), CLOSED (meaning that the target sent a port closed ICMP message), or FILTERED (meaning that no response was received at all: this is also called stealthed by so-called security experts like Steve Gibson but it's a good idea to ignore him just on general principles). UDP is a completely stateless protocol, though. Even if you send a UDP packet to a port that a valid daemon is listening on, the system isn't obligated to send anything back to you at all: there is no handshake sequence to establish a connection. So making a determination is harder than with TCP. If you receive a port closed ICMP message, the port can be safely listed as CLOSED, but if you receive nothing at all, that could mean that the port is either OPEN or FILTERED -- it's pretty much impossible to tell the difference. NMAP assumes that every UDP port that it doesn't receive a responsee from is OPEN, which means that if you have your firewall DROP all UDP connections, every UDP port will appear as open. If you want to fix this, have your firewall REJECT instead of DROP, and the ports will appear correctly as CLOSED to a port scan. DROPing connections without a response is in violation of the RFCs, too, if you care about that sort of thing. Having the local machine portscan itself will also tell you which UDP ports are *actually* open, because I assume you don't have your firewall set to DROP packets from itself. Also, did you know that by default, nmap only scans ports listed in its services file? So although it scans commonly-used ports, it's not scanning the entire system. If you have enough time (this will make the scan very slow, especially over a slow network link), use the -p 1- argument to every scan to force nmap to scan every port from 1 to 65535 instead of just the maybe 400 or 500 ports that it has listed in its services file. That's the only way you can get a complete picture of what your box looks like from the outside. -- Jeff CoppockNortel Networks Systems Engineerhttp://nortelnetworks.com
Re: Port Scan for UDP
Excuse your arrogance, but let me correct you in some points you made! First of all nmap does not scan only the services listed in /etc/services, if you were to have bothered reading the manual before answering you would have read, and I quote: The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap. NOTE! Comes with nmap! usually located in /usr/local/share/nmap/nmap-services. You could have spared the TCP/UDP diff lecture since the question wasn't directed to that... Although you were correct about UDP and it's difficulty when it comes to remote scanning. jc: If you own the box and *don't* have any reason to assume/think you've been compromised (Just checking) you can check locally using nice tools like: netstat -an --ip for both udp and tcp or netstat -an --udp[--tcp] for either one. lsof -i -n nmap localhost -p 1-[HigherPortNumber] fuser and the list goes on =) -xbud - [EMAIL PROTECTED] I only drink to make other people interesting - On Sunday 21 October 2001 09:45 am, Craig McPherson wrote: I can't believe nobody has answered this correctly yet. UDP is different than TCP in that it is a stateless protocol, and that means you have to understand a few things to interpret UDP port scan results correctly. With TCP scans, you get one of three results: OPEN (meaning that the TCP handshake sequence to open a connection completed), CLOSED (meaning that the target sent a port closed ICMP message), or FILTERED (meaning that no response was received at all: this is also called stealthed by so-called security experts like Steve Gibson but it's a good idea to ignore him just on general principles). UDP is a completely stateless protocol, though. Even if you send a UDP packet to a port that a valid daemon is listening on, the system isn't obligated to send anything back to you at all: there is no handshake sequence to establish a connection. So making a determination is harder than with TCP. If you receive a port closed ICMP message, the port can be safely listed as CLOSED, but if you receive nothing at all, that could mean that the port is either OPEN or FILTERED -- it's pretty much impossible to tell the difference. NMAP assumes that every UDP port that it doesn't receive a responsee from is OPEN, which means that if you have your firewall DROP all UDP connections, every UDP port will appear as open. If you want to fix this, have your firewall REJECT instead of DROP, and the ports will appear correctly as CLOSED to a port scan. DROPing connections without a response is in violation of the RFCs, too, if you care about that sort of thing. Having the local machine portscan itself will also tell you which UDP ports are *actually* open, because I assume you don't have your firewall set to DROP packets from itself. Also, did you know that by default, nmap only scans ports listed in its services file? So although it scans commonly-used ports, it's not scanning the entire system. If you have enough time (this will make the scan very slow, especially over a slow network link), use the -p 1- argument to every scan to force nmap to scan every port from 1 to 65535 instead of just the maybe 400 or 500 ports that it has listed in its services file. That's the only way you can get a complete picture of what your box looks like from the outside. I'm doing portscans on a system I'm working to learn more about securing hosts and setting up iptables. My tcp portscan reported what I expected, only www, ssh and smtp listening. The udp portscan reported a huge list of 'open' ports. I really didn't know what to expect for this scan, so I want to know if this is normal. Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. If this isn't secure behaviour, perhaps I can add an iptables entry like: iptables -A INPUT -p udp -j drop However, I don't have any applications running using udp, so the 'open' port doesn't have anywhere to go, as far as I know. Again, if someone can confirm this, I'd really appreciate it. thanks, jc
Re: Port Scan for UDP
On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. Adding or removing lines in /etc/services doesn't open or close ports... this is a common misconception. Removing what's listening on a particular port is what closes that port. -- Marc Wilson [EMAIL PROTECTED] [EMAIL PROTECTED] PGP signature
Re: Port Scan for UDP
On Sat, 20 Oct 2001, Marc Wilson wrote: On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. Adding or removing lines in /etc/services doesn't open or close ports... this is a common misconception. Removing what's listening on a particular port is what closes that port. A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). [EMAIL PROTECTED] | An ounce of perception, http://www.debian.org | a pound of obscure... |(Peart) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp port returns the process(es) listening on the named UDP port. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ PGP signature
Re: Port Scan for UDP
tony mancill, 2001-Oct-20 21:22 -0700: On Sat, 20 Oct 2001, Marc Wilson wrote: On Sat, Oct 20, 2001 at 07:18:25PM -0700, Jeff Coppock wrote: Just for grins, I removed every udp listing in /etc/services and restarted inetd and the scan came back the same. I figure this is normal, but if someone can confirm this behaviour, I'd really appreciate it. Adding or removing lines in /etc/services doesn't open or close ports... this is a common misconception. Removing what's listening on a particular port is what closes that port. A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). Hmmm, so I was under that misconception. I've started looking into what processes own these 'open' ports and using lsof -i I'm not seeing processes owning these ports. It's listing port numbers for protocols I've never heard of, let alone would use. Like 1356:cuillamartin, 2024:CAIlic and a bunch way up high. I know I'm not running these apps, but I haven't checked them all yet, although there are hundreds listed. I'm wondering if my portscan was not right: nmap -sU -P0 host -- Jeff CoppockNortel Networks Systems Engineerhttp://nortelnetworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Port Scan for UDP
Hi, On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2001, Marc Wilson wrote: Adding or removing lines in /etc/services doesn't open or close ports... this is a common misconception. Removing what's listening on a particular port is what closes that port. A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). You can also use netstat -pan to find out which process is listening on which port. regards, Volker -- Volker Dormeyer * [EMAIL PROTECTED] PGP signature
