Scanning my UDP ports
You appear to only have scanned TCP and not UDP. There might also be UDP services you want to worry about :-).
UDP scanning has a number of issues that do not apply to TCP scanning. In either case, I would start by querying the OS instead: How do I list all sockets which are open to remote machines?
Port scanning is still useful as a confirmation though. Port scanning from a different host is a particularly good idea if you have set up a firewall, to confirm that the firewall is doing what you want.
Thanks. (1) Do ss and netstat report sockets, without regard to any local firewall?
Yes.
(2) What is your command for port scanning for TCP and UDP? For example, sudo
nmap -p0-65535 -sU 192.168.1.97have been running for a while. -- Tim
security udp nmap
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
add a comment |
You appear to only have scanned TCP and not UDP. There might also be UDP services you want to worry about :-).
UDP scanning has a number of issues that do not apply to TCP scanning. In either case, I would start by querying the OS instead: How do I list all sockets which are open to remote machines?
Port scanning is still useful as a confirmation though. Port scanning from a different host is a particularly good idea if you have set up a firewall, to confirm that the firewall is doing what you want.
Thanks. (1) Do ss and netstat report sockets, without regard to any local firewall?
Yes.
(2) What is your command for port scanning for TCP and UDP? For example, sudo
nmap -p0-65535 -sU 192.168.1.97have been running for a while. -- Tim
security udp nmap
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
add a comment |
You appear to only have scanned TCP and not UDP. There might also be UDP services you want to worry about :-).
UDP scanning has a number of issues that do not apply to TCP scanning. In either case, I would start by querying the OS instead: How do I list all sockets which are open to remote machines?
Port scanning is still useful as a confirmation though. Port scanning from a different host is a particularly good idea if you have set up a firewall, to confirm that the firewall is doing what you want.
Thanks. (1) Do ss and netstat report sockets, without regard to any local firewall?
Yes.
(2) What is your command for port scanning for TCP and UDP? For example, sudo
nmap -p0-65535 -sU 192.168.1.97have been running for a while. -- Tim
security udp nmap
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
You appear to only have scanned TCP and not UDP. There might also be UDP services you want to worry about :-).
UDP scanning has a number of issues that do not apply to TCP scanning. In either case, I would start by querying the OS instead: How do I list all sockets which are open to remote machines?
Port scanning is still useful as a confirmation though. Port scanning from a different host is a particularly good idea if you have set up a firewall, to confirm that the firewall is doing what you want.
Thanks. (1) Do ss and netstat report sockets, without regard to any local firewall?
Yes.
(2) What is your command for port scanning for TCP and UDP? For example, sudo
nmap -p0-65535 -sU 192.168.1.97have been running for a while. -- Tim
security udp nmap
security udp nmap
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
edited 1 hour ago
sourcejedi
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
asked 1 hour ago
sourcejedisourcejedi
25.4k445110
25.4k445110
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
That is one of the issues that might apply to UDP scanning. To be honest I have not bothered much with it. I think you can bump up the timing when you are on your nice fast local wired network. -T5 seems to work ok on loopback :-), it completed a full UDP scan in less than 3 minutes. Hint: press enter while nmap is running, and it will show a progress indicator.
If you only want to double-check your firewall protects the ports you think it does, you can just pass a list of listening ports that you saw in netstat / ss. I do not tend to have many weird network services that are listening on physical interfaces but that I need to firewall, so I can just type them in manually :-P.
A second issue is that UDP scans may also show programs which are not listening, only making requests, e.g. a program which sent a DNS request and is waiting for a reply. So some judgement is required. This is easiest when using netstat / ss, you can get them to show the program name, and then start guessing how they are using UDP :-).
The paranioa value of a real scan, is it would help people start noticing things like the Intel ME stupidity.
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script.
– Tim
1 hour ago
@Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason?
– sourcejedi
1 hour ago
Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible?
– Tim
1 hour ago
@Tim memory says thatntpddid not let you actually configure it to listen on localhost. Instead you could only configurentpdto discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/…
– sourcejedi
45 mins ago
@Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost.
– sourcejedi
43 mins ago
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f508092%2fscanning-my-udp-ports%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
That is one of the issues that might apply to UDP scanning. To be honest I have not bothered much with it. I think you can bump up the timing when you are on your nice fast local wired network. -T5 seems to work ok on loopback :-), it completed a full UDP scan in less than 3 minutes. Hint: press enter while nmap is running, and it will show a progress indicator.
If you only want to double-check your firewall protects the ports you think it does, you can just pass a list of listening ports that you saw in netstat / ss. I do not tend to have many weird network services that are listening on physical interfaces but that I need to firewall, so I can just type them in manually :-P.
A second issue is that UDP scans may also show programs which are not listening, only making requests, e.g. a program which sent a DNS request and is waiting for a reply. So some judgement is required. This is easiest when using netstat / ss, you can get them to show the program name, and then start guessing how they are using UDP :-).
The paranioa value of a real scan, is it would help people start noticing things like the Intel ME stupidity.
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script.
– Tim
1 hour ago
@Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason?
– sourcejedi
1 hour ago
Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible?
– Tim
1 hour ago
@Tim memory says thatntpddid not let you actually configure it to listen on localhost. Instead you could only configurentpdto discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/…
– sourcejedi
45 mins ago
@Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost.
– sourcejedi
43 mins ago
|
show 1 more comment
That is one of the issues that might apply to UDP scanning. To be honest I have not bothered much with it. I think you can bump up the timing when you are on your nice fast local wired network. -T5 seems to work ok on loopback :-), it completed a full UDP scan in less than 3 minutes. Hint: press enter while nmap is running, and it will show a progress indicator.
If you only want to double-check your firewall protects the ports you think it does, you can just pass a list of listening ports that you saw in netstat / ss. I do not tend to have many weird network services that are listening on physical interfaces but that I need to firewall, so I can just type them in manually :-P.
A second issue is that UDP scans may also show programs which are not listening, only making requests, e.g. a program which sent a DNS request and is waiting for a reply. So some judgement is required. This is easiest when using netstat / ss, you can get them to show the program name, and then start guessing how they are using UDP :-).
The paranioa value of a real scan, is it would help people start noticing things like the Intel ME stupidity.
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script.
– Tim
1 hour ago
@Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason?
– sourcejedi
1 hour ago
Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible?
– Tim
1 hour ago
@Tim memory says thatntpddid not let you actually configure it to listen on localhost. Instead you could only configurentpdto discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/…
– sourcejedi
45 mins ago
@Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost.
– sourcejedi
43 mins ago
|
show 1 more comment
That is one of the issues that might apply to UDP scanning. To be honest I have not bothered much with it. I think you can bump up the timing when you are on your nice fast local wired network. -T5 seems to work ok on loopback :-), it completed a full UDP scan in less than 3 minutes. Hint: press enter while nmap is running, and it will show a progress indicator.
If you only want to double-check your firewall protects the ports you think it does, you can just pass a list of listening ports that you saw in netstat / ss. I do not tend to have many weird network services that are listening on physical interfaces but that I need to firewall, so I can just type them in manually :-P.
A second issue is that UDP scans may also show programs which are not listening, only making requests, e.g. a program which sent a DNS request and is waiting for a reply. So some judgement is required. This is easiest when using netstat / ss, you can get them to show the program name, and then start guessing how they are using UDP :-).
The paranioa value of a real scan, is it would help people start noticing things like the Intel ME stupidity.
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
That is one of the issues that might apply to UDP scanning. To be honest I have not bothered much with it. I think you can bump up the timing when you are on your nice fast local wired network. -T5 seems to work ok on loopback :-), it completed a full UDP scan in less than 3 minutes. Hint: press enter while nmap is running, and it will show a progress indicator.
If you only want to double-check your firewall protects the ports you think it does, you can just pass a list of listening ports that you saw in netstat / ss. I do not tend to have many weird network services that are listening on physical interfaces but that I need to firewall, so I can just type them in manually :-P.
A second issue is that UDP scans may also show programs which are not listening, only making requests, e.g. a program which sent a DNS request and is waiting for a reply. So some judgement is required. This is easiest when using netstat / ss, you can get them to show the program name, and then start guessing how they are using UDP :-).
The paranioa value of a real scan, is it would help people start noticing things like the Intel ME stupidity.
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
edited 1 hour ago
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
answered 1 hour ago
sourcejedisourcejedi
25.4k445110
25.4k445110
Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script.
– Tim
1 hour ago
@Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason?
– sourcejedi
1 hour ago
Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible?
– Tim
1 hour ago
@Tim memory says thatntpddid not let you actually configure it to listen on localhost. Instead you could only configurentpdto discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/…
– sourcejedi
45 mins ago
@Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost.
– sourcejedi
43 mins ago
|
show 1 more comment
Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script.
– Tim
1 hour ago
@Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason?
– sourcejedi
1 hour ago
Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible?
– Tim
1 hour ago
@Tim memory says thatntpddid not let you actually configure it to listen on localhost. Instead you could only configurentpdto discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/…
– sourcejedi
45 mins ago
@Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost.
– sourcejedi
43 mins ago
Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script.
– Tim
1 hour ago
Thanks. How would you extract tcp and udp ports from ss or netstat, and pass them to nmap for tcp and udp scan? It is not easy to write such a shell script.
– Tim
1 hour ago
@Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason?
– sourcejedi
1 hour ago
@Tim I added a sentence saying that I would not need to. I would follow rules similar to those in the "Omitting localhost" section, then I have only a few services that would show up, so I can type them in manually. If possible, I would tend to configure services to listen on localhost, then I don't have to worry about the firewall for that service. Do you have many services which are not listening on localhost, for some reason?
– sourcejedi
1 hour ago
Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible?
– Tim
1 hour ago
Thanks. (1) I am not sure what rules in the "Omitting localhost" section in unix.stackexchange.com/questions/309083/…, probably because I don't quite follow the post and your reply there. (2) " If possible, I would tend to configure services to listen on localhost". When is it not possible?
– Tim
1 hour ago
@Tim memory says that
ntpd did not let you actually configure it to listen on localhost. Instead you could only configure ntpd to discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/…– sourcejedi
45 mins ago
@Tim memory says that
ntpd did not let you actually configure it to listen on localhost. Instead you could only configure ntpd to discard packets which did not come from localhost. My memory might be wrong, but at least that was a common default configuration. googleprojectzero.blogspot.com/2015/01/…– sourcejedi
45 mins ago
@Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost.
– sourcejedi
43 mins ago
@Tim " Access to private and control mode queries can be restricted in ntp.conf based on the source IP. Default installations usually prohibit these queries for every source IP except for 127.0.0.1 and ::1. This is what e.g. Ubuntu, Debian and OS X do [did?]." - this is ntpd checking the source address of each connection itself. It was not being bound to localhost.
– sourcejedi
43 mins ago
|
show 1 more comment
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f508092%2fscanning-my-udp-ports%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
