Would this setup provide adequate security? Unicorn Meta Zoo #1: Why another podcast? Announcing the arrival of Valued Associate #679: Cesar Manara Come Celebrate our 10 Year Anniversary!IMAP over SSL - Exchange 2003 ConfigurationHow to inspect remote SMTP server's TLS certificate?Why should I firewall servers?How do I deal with a compromised server?Our security auditor is an idiot. How do I give him the information he wants?Security Certificate ExceptionGiven an Amazon Web Service Security Group, how can I find out what the IP's are?How Do I Defend WebEx Security?Debugging curl FTPS connection, using Client Authentication certificates (OpenSSL)ProFTPD: The meaning of the “TLS Verify Client” and “NoCertRequest” in the TLS configuration
My admission is revoked after accepting the admission offer
Is it acceptable to use working hours to read general interest books?
Raising a bilingual kid. When should we introduce the majority language?
A Paper Record is What I Hamper
What to do with someone that cheated their way through university and a PhD program?
Could Neutrino technically as side-effect, incentivize centralization of the bitcoin network?
Are these square matrices always diagonalisable?
Why isn't everyone flabbergasted about Bran's "gift"?
What is ls Largest Number Formed by only moving two sticks in 508?
How long after the last departure shall the airport stay open for an emergency return?
What *exactly* is electrical current, voltage, and resistance?
Expansion//Explosion and Siren Stormtamer
Multiple options vs single option UI
Where did Arya get these scars?
Implementing 3DES algorithm in Java: is my code secure?
Would reducing the reference voltage of an ADC have any effect on accuracy?
How would I use different systems of magic when they are capable of the same effects?
How to not starve gigantic beasts
Mistake in years of experience in resume?
Does Feeblemind produce an ongoing magical effect that can be dispelled?
Did the Roman Empire have penal colonies?
How would this chord from "Rocket Man" be analyzed?
What was Apollo 13's "Little Jolt" after MECO?
Why did Israel vote against lifting the American embargo on Cuba?
Would this setup provide adequate security?
Unicorn Meta Zoo #1: Why another podcast?
Announcing the arrival of Valued Associate #679: Cesar Manara
Come Celebrate our 10 Year Anniversary!IMAP over SSL - Exchange 2003 ConfigurationHow to inspect remote SMTP server's TLS certificate?Why should I firewall servers?How do I deal with a compromised server?Our security auditor is an idiot. How do I give him the information he wants?Security Certificate ExceptionGiven an Amazon Web Service Security Group, how can I find out what the IP's are?How Do I Defend WebEx Security?Debugging curl FTPS connection, using Client Authentication certificates (OpenSSL)ProFTPD: The meaning of the “TLS Verify Client” and “NoCertRequest” in the TLS configuration
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
In the following scenario, I'm looking to see if I can provide adequate security as is or if there would be any tangible benefit to re-architecting things (like changing it so that the service in question would be in a DMZ, or something like that). Assume that the data I'm trying to protect is highly sensitive and it would be a major headline if it got exposed.
- On a server that has access to the internal network (because we also need to access a database or other internal services), there will be a gRPC service that listens on a specific TCP port.
- I know in advance that I only want a client from a single known, trusted IP to connect in, so we'll create a rule in the external firewall to allow incoming TCP connections from that single IP to the IP endpoint of the gRPC service.
- For encryption and authentication, we'll also be doing TLS 1.2 mutual authentication on the gRPC service.
As far as what I've been able to think of, this should be more than acceptable because the only way to be able to connect in on that port would be to either legitimately have that IP (and it's a static IP where we trust the entity that the IP has been assigned to) or to spoof it, and a potential attacker would have to know that you would have to spoof that specific IP, which seems very unlikely without insider information (and even then, you'd only be able to send in packets trying to damage things and wouldn't get responses back because they'd route to the real IP, right?). Assuming that a malicious actor were to gain control of that IP, they'd still have to have the appropriate certificate to get through the TLS piece, know the type of protocol that they're trying to exploit, potentially need application-layer credentials, etc. I only see this as a likelihood if the actual client machine that I expect to connect in gets compromised; as far as I know, it has good physical/network security around it, so I think this should be very improbable.
Additionally, what about if I didn't firewall it at all? Would the security level still be acceptably high since you'd have to either have a legitimate certificate signed by the same CA as the server's certificate, or have an exploit up your sleeve in order to get past the TLS authentication? I'd firewall it either way since there really is just a single client I want connecting in, but I'm also curious about this.
Are there other issues that I'm not thinking about, or any other good reasons that should lead me to abandon this sort of setup as insecure? Thanks in advance.
security ssl firewall dmz
asked Apr 17 at 23:30
KdawgKdawg
101
add a comment |
In the following scenario, I'm looking to see if I can provide adequate security as is or if there would be any tangible benefit to re-architecting things (like changing it so that the service in question would be in a DMZ, or something like that). Assume that the data I'm trying to protect is highly sensitive and it would be a major headline if it got exposed.
- On a server that has access to the internal network (because we also need to access a database or other internal services), there will be a gRPC service that listens on a specific TCP port.
- I know in advance that I only want a client from a single known, trusted IP to connect in, so we'll create a rule in the external firewall to allow incoming TCP connections from that single IP to the IP endpoint of the gRPC service.
- For encryption and authentication, we'll also be doing TLS 1.2 mutual authentication on the gRPC service.
As far as what I've been able to think of, this should be more than acceptable because the only way to be able to connect in on that port would be to either legitimately have that IP (and it's a static IP where we trust the entity that the IP has been assigned to) or to spoof it, and a potential attacker would have to know that you would have to spoof that specific IP, which seems very unlikely without insider information (and even then, you'd only be able to send in packets trying to damage things and wouldn't get responses back because they'd route to the real IP, right?). Assuming that a malicious actor were to gain control of that IP, they'd still have to have the appropriate certificate to get through the TLS piece, know the type of protocol that they're trying to exploit, potentially need application-layer credentials, etc. I only see this as a likelihood if the actual client machine that I expect to connect in gets compromised; as far as I know, it has good physical/network security around it, so I think this should be very improbable.
Additionally, what about if I didn't firewall it at all? Would the security level still be acceptably high since you'd have to either have a legitimate certificate signed by the same CA as the server's certificate, or have an exploit up your sleeve in order to get past the TLS authentication? I'd firewall it either way since there really is just a single client I want connecting in, but I'm also curious about this.
Are there other issues that I'm not thinking about, or any other good reasons that should lead me to abandon this sort of setup as insecure? Thanks in advance.
security ssl firewall dmz
asked Apr 17 at 23:30
KdawgKdawg
101
1
"because they'd route to the real IP, right?)" Not in case of a BGP spoof, where all traffic will go somewhere else. This is why authenticating at the TLS level is required too (but you should probably validate only one specific certificate not all from some CA, or manage your own CA). If you do not firewall it, you risk DDOS , that is no leaking of information but your service becoming unresponsive even for its legitimate user because overwhelmed with bogus TCP SYN attempts or equivalent.
– Patrick Mevzek
Apr 17 at 23:45
Your setup is very similar to what is done in the domain name industry, read tools.ietf.org/html/rfc5734. 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level.
– Patrick Mevzek
Apr 17 at 23:47
If you start now from scratch you may as well use TLS 1.3 and nothing else.
– Patrick Mevzek
Apr 17 at 23:47
@PatrickMevzek, thanks for the very helpful comments, especially the similarity between the security implemented in that RFC. I'm not entirely certain if the gRPC libraries have stable TLS 1.3 implementations already, but if they do, I will go with that. If you want to convert your comments to an answer, I'd love to give you an upvote and accept it (assuming no one else comes in with a contradictory or better answer).
– Kdawg
Apr 19 at 18:20
add a comment |
In the following scenario, I'm looking to see if I can provide adequate security as is or if there would be any tangible benefit to re-architecting things (like changing it so that the service in question would be in a DMZ, or something like that). Assume that the data I'm trying to protect is highly sensitive and it would be a major headline if it got exposed.
- On a server that has access to the internal network (because we also need to access a database or other internal services), there will be a gRPC service that listens on a specific TCP port.
- I know in advance that I only want a client from a single known, trusted IP to connect in, so we'll create a rule in the external firewall to allow incoming TCP connections from that single IP to the IP endpoint of the gRPC service.
- For encryption and authentication, we'll also be doing TLS 1.2 mutual authentication on the gRPC service.
As far as what I've been able to think of, this should be more than acceptable because the only way to be able to connect in on that port would be to either legitimately have that IP (and it's a static IP where we trust the entity that the IP has been assigned to) or to spoof it, and a potential attacker would have to know that you would have to spoof that specific IP, which seems very unlikely without insider information (and even then, you'd only be able to send in packets trying to damage things and wouldn't get responses back because they'd route to the real IP, right?). Assuming that a malicious actor were to gain control of that IP, they'd still have to have the appropriate certificate to get through the TLS piece, know the type of protocol that they're trying to exploit, potentially need application-layer credentials, etc. I only see this as a likelihood if the actual client machine that I expect to connect in gets compromised; as far as I know, it has good physical/network security around it, so I think this should be very improbable.
Additionally, what about if I didn't firewall it at all? Would the security level still be acceptably high since you'd have to either have a legitimate certificate signed by the same CA as the server's certificate, or have an exploit up your sleeve in order to get past the TLS authentication? I'd firewall it either way since there really is just a single client I want connecting in, but I'm also curious about this.
Are there other issues that I'm not thinking about, or any other good reasons that should lead me to abandon this sort of setup as insecure? Thanks in advance.
security ssl firewall dmz
asked Apr 17 at 23:30
KdawgKdawg
101
In the following scenario, I'm looking to see if I can provide adequate security as is or if there would be any tangible benefit to re-architecting things (like changing it so that the service in question would be in a DMZ, or something like that). Assume that the data I'm trying to protect is highly sensitive and it would be a major headline if it got exposed.
- On a server that has access to the internal network (because we also need to access a database or other internal services), there will be a gRPC service that listens on a specific TCP port.
- I know in advance that I only want a client from a single known, trusted IP to connect in, so we'll create a rule in the external firewall to allow incoming TCP connections from that single IP to the IP endpoint of the gRPC service.
- For encryption and authentication, we'll also be doing TLS 1.2 mutual authentication on the gRPC service.
As far as what I've been able to think of, this should be more than acceptable because the only way to be able to connect in on that port would be to either legitimately have that IP (and it's a static IP where we trust the entity that the IP has been assigned to) or to spoof it, and a potential attacker would have to know that you would have to spoof that specific IP, which seems very unlikely without insider information (and even then, you'd only be able to send in packets trying to damage things and wouldn't get responses back because they'd route to the real IP, right?). Assuming that a malicious actor were to gain control of that IP, they'd still have to have the appropriate certificate to get through the TLS piece, know the type of protocol that they're trying to exploit, potentially need application-layer credentials, etc. I only see this as a likelihood if the actual client machine that I expect to connect in gets compromised; as far as I know, it has good physical/network security around it, so I think this should be very improbable.
Additionally, what about if I didn't firewall it at all? Would the security level still be acceptably high since you'd have to either have a legitimate certificate signed by the same CA as the server's certificate, or have an exploit up your sleeve in order to get past the TLS authentication? I'd firewall it either way since there really is just a single client I want connecting in, but I'm also curious about this.
Are there other issues that I'm not thinking about, or any other good reasons that should lead me to abandon this sort of setup as insecure? Thanks in advance.
security ssl firewall dmz
security ssl firewall dmz
asked Apr 17 at 23:30
KdawgKdawg
101
asked Apr 17 at 23:30
KdawgKdawg
101
asked Apr 17 at 23:30
KdawgKdawg
101
asked Apr 17 at 23:30
KdawgKdawg
101
asked Apr 17 at 23:30
KdawgKdawg
101
101
1
"because they'd route to the real IP, right?)" Not in case of a BGP spoof, where all traffic will go somewhere else. This is why authenticating at the TLS level is required too (but you should probably validate only one specific certificate not all from some CA, or manage your own CA). If you do not firewall it, you risk DDOS , that is no leaking of information but your service becoming unresponsive even for its legitimate user because overwhelmed with bogus TCP SYN attempts or equivalent.
– Patrick Mevzek
Apr 17 at 23:45
Your setup is very similar to what is done in the domain name industry, read tools.ietf.org/html/rfc5734. 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level.
– Patrick Mevzek
Apr 17 at 23:47
If you start now from scratch you may as well use TLS 1.3 and nothing else.
– Patrick Mevzek
Apr 17 at 23:47
@PatrickMevzek, thanks for the very helpful comments, especially the similarity between the security implemented in that RFC. I'm not entirely certain if the gRPC libraries have stable TLS 1.3 implementations already, but if they do, I will go with that. If you want to convert your comments to an answer, I'd love to give you an upvote and accept it (assuming no one else comes in with a contradictory or better answer).
– Kdawg
Apr 19 at 18:20
add a comment |
1
"because they'd route to the real IP, right?)" Not in case of a BGP spoof, where all traffic will go somewhere else. This is why authenticating at the TLS level is required too (but you should probably validate only one specific certificate not all from some CA, or manage your own CA). If you do not firewall it, you risk DDOS , that is no leaking of information but your service becoming unresponsive even for its legitimate user because overwhelmed with bogus TCP SYN attempts or equivalent.
– Patrick Mevzek
Apr 17 at 23:45
Your setup is very similar to what is done in the domain name industry, read tools.ietf.org/html/rfc5734. 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level.
– Patrick Mevzek
Apr 17 at 23:47
If you start now from scratch you may as well use TLS 1.3 and nothing else.
– Patrick Mevzek
Apr 17 at 23:47
@PatrickMevzek, thanks for the very helpful comments, especially the similarity between the security implemented in that RFC. I'm not entirely certain if the gRPC libraries have stable TLS 1.3 implementations already, but if they do, I will go with that. If you want to convert your comments to an answer, I'd love to give you an upvote and accept it (assuming no one else comes in with a contradictory or better answer).
– Kdawg
Apr 19 at 18:20
1
1
"because they'd route to the real IP, right?)" Not in case of a BGP spoof, where all traffic will go somewhere else. This is why authenticating at the TLS level is required too (but you should probably validate only one specific certificate not all from some CA, or manage your own CA). If you do not firewall it, you risk DDOS , that is no leaking of information but your service becoming unresponsive even for its legitimate user because overwhelmed with bogus TCP SYN attempts or equivalent.
– Patrick Mevzek
Apr 17 at 23:45
"because they'd route to the real IP, right?)" Not in case of a BGP spoof, where all traffic will go somewhere else. This is why authenticating at the TLS level is required too (but you should probably validate only one specific certificate not all from some CA, or manage your own CA). If you do not firewall it, you risk DDOS , that is no leaking of information but your service becoming unresponsive even for its legitimate user because overwhelmed with bogus TCP SYN attempts or equivalent.
– Patrick Mevzek
Apr 17 at 23:45
Your setup is very similar to what is done in the domain name industry, read tools.ietf.org/html/rfc5734. 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level.
– Patrick Mevzek
Apr 17 at 23:47
Your setup is very similar to what is done in the domain name industry, read tools.ietf.org/html/rfc5734. 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level.
– Patrick Mevzek
Apr 17 at 23:47
If you start now from scratch you may as well use TLS 1.3 and nothing else.
– Patrick Mevzek
Apr 17 at 23:47
If you start now from scratch you may as well use TLS 1.3 and nothing else.
– Patrick Mevzek
Apr 17 at 23:47
@PatrickMevzek, thanks for the very helpful comments, especially the similarity between the security implemented in that RFC. I'm not entirely certain if the gRPC libraries have stable TLS 1.3 implementations already, but if they do, I will go with that. If you want to convert your comments to an answer, I'd love to give you an upvote and accept it (assuming no one else comes in with a contradictory or better answer).
– Kdawg
Apr 19 at 18:20
@PatrickMevzek, thanks for the very helpful comments, especially the similarity between the security implemented in that RFC. I'm not entirely certain if the gRPC libraries have stable TLS 1.3 implementations already, but if they do, I will go with that. If you want to convert your comments to an answer, I'd love to give you an upvote and accept it (assuming no one else comes in with a contradictory or better answer).
– Kdawg
Apr 19 at 18:20
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2fserverfault.com%2fquestions%2f963572%2fwould-this-setup-provide-adequate-security%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Server Fault!
- 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%2fserverfault.com%2fquestions%2f963572%2fwould-this-setup-provide-adequate-security%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
1
"because they'd route to the real IP, right?)" Not in case of a BGP spoof, where all traffic will go somewhere else. This is why authenticating at the TLS level is required too (but you should probably validate only one specific certificate not all from some CA, or manage your own CA). If you do not firewall it, you risk DDOS , that is no leaking of information but your service becoming unresponsive even for its legitimate user because overwhelmed with bogus TCP SYN attempts or equivalent.
– Patrick Mevzek
Apr 17 at 23:45
Your setup is very similar to what is done in the domain name industry, read tools.ietf.org/html/rfc5734. 3 layers of security: restricting IP address from which the client can connect and using TLS, restricting which X.509 certificate it can use, and then a login+password at the protocol (EPP) level.
– Patrick Mevzek
Apr 17 at 23:47
If you start now from scratch you may as well use TLS 1.3 and nothing else.
– Patrick Mevzek
Apr 17 at 23:47
@PatrickMevzek, thanks for the very helpful comments, especially the similarity between the security implemented in that RFC. I'm not entirely certain if the gRPC libraries have stable TLS 1.3 implementations already, but if they do, I will go with that. If you want to convert your comments to an answer, I'd love to give you an upvote and accept it (assuming no one else comes in with a contradictory or better answer).
– Kdawg
Apr 19 at 18:20