what is the required ports to be opened on the firewall?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Currently I'll be installing one AIX server behind a firewall, I just asked to open port 443 to use the SSH protocol to access this UNIX server.
I already changed the default ssh port to be 443 instead of 22 to log in and manage the server.
My question: is this enough to access and manage this server which is behind the firewall or is there any additional ports that should be included in the firewall rules?
ssh firewall aix
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
add a comment |
Currently I'll be installing one AIX server behind a firewall, I just asked to open port 443 to use the SSH protocol to access this UNIX server.
I already changed the default ssh port to be 443 instead of 22 to log in and manage the server.
My question: is this enough to access and manage this server which is behind the firewall or is there any additional ports that should be included in the firewall rules?
ssh firewall aix
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
4
Using 443 seems a bad move as that port will get barrages of dud requests because it's the standard https port. Probably not a big deal, but if the duds are going to be rejected anyway, you might as well reject them more efficiently by leaving 443 closed too and choosing something more arbitrary.
– goldilocks
Jul 19 '13 at 0:26
add a comment |
Currently I'll be installing one AIX server behind a firewall, I just asked to open port 443 to use the SSH protocol to access this UNIX server.
I already changed the default ssh port to be 443 instead of 22 to log in and manage the server.
My question: is this enough to access and manage this server which is behind the firewall or is there any additional ports that should be included in the firewall rules?
ssh firewall aix
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
Currently I'll be installing one AIX server behind a firewall, I just asked to open port 443 to use the SSH protocol to access this UNIX server.
I already changed the default ssh port to be 443 instead of 22 to log in and manage the server.
My question: is this enough to access and manage this server which is behind the firewall or is there any additional ports that should be included in the firewall rules?
ssh firewall aix
ssh firewall aix
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
edited Jul 18 '13 at 23:58
Gilles
546k12911101624
546k12911101624
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
asked Jul 18 '13 at 22:50
Maged RamezMaged Ramez
21112
21112
4
Using 443 seems a bad move as that port will get barrages of dud requests because it's the standard https port. Probably not a big deal, but if the duds are going to be rejected anyway, you might as well reject them more efficiently by leaving 443 closed too and choosing something more arbitrary.
– goldilocks
Jul 19 '13 at 0:26
add a comment |
4
Using 443 seems a bad move as that port will get barrages of dud requests because it's the standard https port. Probably not a big deal, but if the duds are going to be rejected anyway, you might as well reject them more efficiently by leaving 443 closed too and choosing something more arbitrary.
– goldilocks
Jul 19 '13 at 0:26
4
4
Using 443 seems a bad move as that port will get barrages of dud requests because it's the standard https port. Probably not a big deal, but if the duds are going to be rejected anyway, you might as well reject them more efficiently by leaving 443 closed too and choosing something more arbitrary.
– goldilocks
Jul 19 '13 at 0:26
Using 443 seems a bad move as that port will get barrages of dud requests because it's the standard https port. Probably not a big deal, but if the duds are going to be rejected anyway, you might as well reject them more efficiently by leaving 443 closed too and choosing something more arbitrary.
– goldilocks
Jul 19 '13 at 0:26
add a comment |
3 Answers
3
active
oldest
votes
This is security by obscurity, and you have chosen a port that in my experience is more often scanned. Just leave ssh on port 22 and get that opened. If you do plan to use security by obscurity, it is best not to pick a well known port. Scanning rates on them tends to be higher than other ports.
An alternative approach is to ssh into an already accessible system and connect from there. ssh can be programmed to automatically forward you to another system.
The only ports that need to be open to any network are those that are used. The list of outbound ports is usually different than inbound. You may want to retrieve patches from your vendor (often on port 80), while not allowing incoming HTTP requests.
Email should generally go to a relay server which will route it appropriately.
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
1
Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
– goldilocks
Jul 19 '13 at 0:22
2
@goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to securessh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.
– BillThor
Jul 19 '13 at 0:27
1
Ifsshisn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.
– goldilocks
Jul 19 '13 at 0:36
@goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
– BillThor
Jul 19 '13 at 0:56
Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Putsshback on the port it belongs and set up fail2ban to deal with scanners and brute force attacks.
– Shadur
Jul 19 '13 at 6:27
add a comment |
If you're only interested in remoting into this server using SSH on port 443, then what you've done is sufficient.
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
add a comment |
to see what ports are being listened to (blocked by a firewall or otherwise)
as root, run
netstat -lp
This will list all open ports, and what applications are listening. then you can open the ports you need in your firewall.
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
answered Jul 18 '13 at 23:03
lordbraylordbray
513
add a 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%2f83575%2fwhat-is-the-required-ports-to-be-opened-on-the-firewall%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is security by obscurity, and you have chosen a port that in my experience is more often scanned. Just leave ssh on port 22 and get that opened. If you do plan to use security by obscurity, it is best not to pick a well known port. Scanning rates on them tends to be higher than other ports.
An alternative approach is to ssh into an already accessible system and connect from there. ssh can be programmed to automatically forward you to another system.
The only ports that need to be open to any network are those that are used. The list of outbound ports is usually different than inbound. You may want to retrieve patches from your vendor (often on port 80), while not allowing incoming HTTP requests.
Email should generally go to a relay server which will route it appropriately.
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
1
Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
– goldilocks
Jul 19 '13 at 0:22
2
@goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to securessh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.
– BillThor
Jul 19 '13 at 0:27
1
Ifsshisn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.
– goldilocks
Jul 19 '13 at 0:36
@goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
– BillThor
Jul 19 '13 at 0:56
Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Putsshback on the port it belongs and set up fail2ban to deal with scanners and brute force attacks.
– Shadur
Jul 19 '13 at 6:27
add a comment |
This is security by obscurity, and you have chosen a port that in my experience is more often scanned. Just leave ssh on port 22 and get that opened. If you do plan to use security by obscurity, it is best not to pick a well known port. Scanning rates on them tends to be higher than other ports.
An alternative approach is to ssh into an already accessible system and connect from there. ssh can be programmed to automatically forward you to another system.
The only ports that need to be open to any network are those that are used. The list of outbound ports is usually different than inbound. You may want to retrieve patches from your vendor (often on port 80), while not allowing incoming HTTP requests.
Email should generally go to a relay server which will route it appropriately.
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
1
Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
– goldilocks
Jul 19 '13 at 0:22
2
@goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to securessh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.
– BillThor
Jul 19 '13 at 0:27
1
Ifsshisn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.
– goldilocks
Jul 19 '13 at 0:36
@goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
– BillThor
Jul 19 '13 at 0:56
Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Putsshback on the port it belongs and set up fail2ban to deal with scanners and brute force attacks.
– Shadur
Jul 19 '13 at 6:27
add a comment |
This is security by obscurity, and you have chosen a port that in my experience is more often scanned. Just leave ssh on port 22 and get that opened. If you do plan to use security by obscurity, it is best not to pick a well known port. Scanning rates on them tends to be higher than other ports.
An alternative approach is to ssh into an already accessible system and connect from there. ssh can be programmed to automatically forward you to another system.
The only ports that need to be open to any network are those that are used. The list of outbound ports is usually different than inbound. You may want to retrieve patches from your vendor (often on port 80), while not allowing incoming HTTP requests.
Email should generally go to a relay server which will route it appropriately.
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
This is security by obscurity, and you have chosen a port that in my experience is more often scanned. Just leave ssh on port 22 and get that opened. If you do plan to use security by obscurity, it is best not to pick a well known port. Scanning rates on them tends to be higher than other ports.
An alternative approach is to ssh into an already accessible system and connect from there. ssh can be programmed to automatically forward you to another system.
The only ports that need to be open to any network are those that are used. The list of outbound ports is usually different than inbound. You may want to retrieve patches from your vendor (often on port 80), while not allowing incoming HTTP requests.
Email should generally go to a relay server which will route it appropriately.
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
answered Jul 19 '13 at 0:07
BillThorBillThor
7,7531426
7,7531426
1
Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
– goldilocks
Jul 19 '13 at 0:22
2
@goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to securessh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.
– BillThor
Jul 19 '13 at 0:27
1
Ifsshisn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.
– goldilocks
Jul 19 '13 at 0:36
@goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
– BillThor
Jul 19 '13 at 0:56
Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Putsshback on the port it belongs and set up fail2ban to deal with scanners and brute force attacks.
– Shadur
Jul 19 '13 at 6:27
add a comment |
1
Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
– goldilocks
Jul 19 '13 at 0:22
2
@goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to securessh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.
– BillThor
Jul 19 '13 at 0:27
1
Ifsshisn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.
– goldilocks
Jul 19 '13 at 0:36
@goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
– BillThor
Jul 19 '13 at 0:56
Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Putsshback on the port it belongs and set up fail2ban to deal with scanners and brute force attacks.
– Shadur
Jul 19 '13 at 6:27
1
1
Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
– goldilocks
Jul 19 '13 at 0:22
Port 22 is often scanned for the same reason, so recommending someone "leave it on 22" instead of using 443 is sort of meaningless -- the point about using a genuinely obscure port is better.
– goldilocks
Jul 19 '13 at 0:22
2
2
@goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to secure
ssh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.– BillThor
Jul 19 '13 at 0:27
@goldilocks When I was monitoring scanning on ports 22 and 443, it was 443 that was scanned more frequently. That is one of the reasons I said to leave in on 22. There are a number of ways to secure
ssh, and I apply a stack of them. The preferable option, is to use an already open server as a gateway, but failing that security by obscurity generally isn't secure.– BillThor
Jul 19 '13 at 0:27
1
1
If
ssh isn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.– goldilocks
Jul 19 '13 at 0:36
If
ssh isn't secure to start with, there's probably not much you can do about it. WRT to 443 vs. 22, I agree 443 will get scanned more often, but my point was if you don't want or need to use the standard port, then don't -- "You might as well" just seems wishy-washy logic.– goldilocks
Jul 19 '13 at 0:36
@goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
– BillThor
Jul 19 '13 at 0:56
@goldilocks It has been my experience that using an obscure port is seen as having secured the service. As a result not much thought goes into properly securing it. It is better to secure the service well, in which case an obscure port invites forgetting which obscure port it is on, or forgetting that it is running. As soon as your custom entry for secure-ssh gets dropped form /etc/services tools like netstat won't make open connections obvious.
– BillThor
Jul 19 '13 at 0:56
Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Put
ssh back on the port it belongs and set up fail2ban to deal with scanners and brute force attacks.– Shadur
Jul 19 '13 at 6:27
Security by obscurity is a damn stupid policy anyway because it tends to lull you into a false sense of security "hurr hurr, they'll never guess this is here". Put
ssh back on the port it belongs and set up fail2ban to deal with scanners and brute force attacks.– Shadur
Jul 19 '13 at 6:27
add a comment |
If you're only interested in remoting into this server using SSH on port 443, then what you've done is sufficient.
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
add a comment |
If you're only interested in remoting into this server using SSH on port 443, then what you've done is sufficient.
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
add a comment |
If you're only interested in remoting into this server using SSH on port 443, then what you've done is sufficient.
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
If you're only interested in remoting into this server using SSH on port 443, then what you've done is sufficient.
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
answered Jul 18 '13 at 23:56
slm♦slm
255k71541687
255k71541687
add a comment |
add a comment |
to see what ports are being listened to (blocked by a firewall or otherwise)
as root, run
netstat -lp
This will list all open ports, and what applications are listening. then you can open the ports you need in your firewall.
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
answered Jul 18 '13 at 23:03
lordbraylordbray
513
add a comment |
to see what ports are being listened to (blocked by a firewall or otherwise)
as root, run
netstat -lp
This will list all open ports, and what applications are listening. then you can open the ports you need in your firewall.
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
answered Jul 18 '13 at 23:03
lordbraylordbray
513
add a comment |
to see what ports are being listened to (blocked by a firewall or otherwise)
as root, run
netstat -lp
This will list all open ports, and what applications are listening. then you can open the ports you need in your firewall.
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
answered Jul 18 '13 at 23:03
lordbraylordbray
513
to see what ports are being listened to (blocked by a firewall or otherwise)
as root, run
netstat -lp
This will list all open ports, and what applications are listening. then you can open the ports you need in your firewall.
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
answered Jul 18 '13 at 23:03
lordbraylordbray
513
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
41.9k1483142
answered Jul 18 '13 at 23:03
lordbraylordbray
513
answered Jul 18 '13 at 23:03
lordbraylordbray
513
answered Jul 18 '13 at 23:03
lordbraylordbray
513
513
add a comment |
add a 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%2f83575%2fwhat-is-the-required-ports-to-be-opened-on-the-firewall%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
4
Using 443 seems a bad move as that port will get barrages of dud requests because it's the standard https port. Probably not a big deal, but if the duds are going to be rejected anyway, you might as well reject them more efficiently by leaving 443 closed too and choosing something more arbitrary.
– goldilocks
Jul 19 '13 at 0:26