UFW deny specific port access over HTTPS?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












We're running a dev server on some IP and have our API exposed on port 5000 and nginx listening on 80. However, the entire backend will crash when one makes an HTTPS request to port 5000. Thus, I noticed a vulnerability, that when one accesses https://SERVER_IP:5000, since it can't handle the HTTPS request, the request hangs and the entire backend stalls (so the API hangs for any other requests as well). I just want that request to never reach the backend.



I have the following rules set up for UFW.



To Action From
-- ------ ----
8000 ALLOW Anywhere
22/tcp ALLOW Anywhere
80 ALLOW Anywhere
5000 ALLOW Anywhere
443/tcp DENY Anywhere
8000 (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
5000 (v6) ALLOW Anywhere (v6)
443/tcp (v6) DENY Anywhere (v6)


However, when one navigates to https://SERVER_IP:5000, the server still crashes. I think this is because https traffic is not necessarily coming in on port 443 but rather 5000 and that's exposed (which it needs to be only for HTTP traffic). So is there some way I can disallow HTTPS traffic on 5000 through UFW or do I have to configure something with nginx?










share|improve this question























  • I would bind 5000 to localhost only and would proxy only http requests from nginx to it
    – Rui F Ribeiro
    Nov 30 at 8:40














up vote
0
down vote

favorite












We're running a dev server on some IP and have our API exposed on port 5000 and nginx listening on 80. However, the entire backend will crash when one makes an HTTPS request to port 5000. Thus, I noticed a vulnerability, that when one accesses https://SERVER_IP:5000, since it can't handle the HTTPS request, the request hangs and the entire backend stalls (so the API hangs for any other requests as well). I just want that request to never reach the backend.



I have the following rules set up for UFW.



To Action From
-- ------ ----
8000 ALLOW Anywhere
22/tcp ALLOW Anywhere
80 ALLOW Anywhere
5000 ALLOW Anywhere
443/tcp DENY Anywhere
8000 (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
5000 (v6) ALLOW Anywhere (v6)
443/tcp (v6) DENY Anywhere (v6)


However, when one navigates to https://SERVER_IP:5000, the server still crashes. I think this is because https traffic is not necessarily coming in on port 443 but rather 5000 and that's exposed (which it needs to be only for HTTP traffic). So is there some way I can disallow HTTPS traffic on 5000 through UFW or do I have to configure something with nginx?










share|improve this question























  • I would bind 5000 to localhost only and would proxy only http requests from nginx to it
    – Rui F Ribeiro
    Nov 30 at 8:40












up vote
0
down vote

favorite









up vote
0
down vote

favorite











We're running a dev server on some IP and have our API exposed on port 5000 and nginx listening on 80. However, the entire backend will crash when one makes an HTTPS request to port 5000. Thus, I noticed a vulnerability, that when one accesses https://SERVER_IP:5000, since it can't handle the HTTPS request, the request hangs and the entire backend stalls (so the API hangs for any other requests as well). I just want that request to never reach the backend.



I have the following rules set up for UFW.



To Action From
-- ------ ----
8000 ALLOW Anywhere
22/tcp ALLOW Anywhere
80 ALLOW Anywhere
5000 ALLOW Anywhere
443/tcp DENY Anywhere
8000 (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
5000 (v6) ALLOW Anywhere (v6)
443/tcp (v6) DENY Anywhere (v6)


However, when one navigates to https://SERVER_IP:5000, the server still crashes. I think this is because https traffic is not necessarily coming in on port 443 but rather 5000 and that's exposed (which it needs to be only for HTTP traffic). So is there some way I can disallow HTTPS traffic on 5000 through UFW or do I have to configure something with nginx?










share|improve this question















We're running a dev server on some IP and have our API exposed on port 5000 and nginx listening on 80. However, the entire backend will crash when one makes an HTTPS request to port 5000. Thus, I noticed a vulnerability, that when one accesses https://SERVER_IP:5000, since it can't handle the HTTPS request, the request hangs and the entire backend stalls (so the API hangs for any other requests as well). I just want that request to never reach the backend.



I have the following rules set up for UFW.



To Action From
-- ------ ----
8000 ALLOW Anywhere
22/tcp ALLOW Anywhere
80 ALLOW Anywhere
5000 ALLOW Anywhere
443/tcp DENY Anywhere
8000 (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
5000 (v6) ALLOW Anywhere (v6)
443/tcp (v6) DENY Anywhere (v6)


However, when one navigates to https://SERVER_IP:5000, the server still crashes. I think this is because https traffic is not necessarily coming in on port 443 but rather 5000 and that's exposed (which it needs to be only for HTTP traffic). So is there some way I can disallow HTTPS traffic on 5000 through UFW or do I have to configure something with nginx?







networking webserver http ufw






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 30 at 5:50









Rui F Ribeiro

38.4k1479128




38.4k1479128










asked Nov 30 at 5:46









rb612

1033




1033











  • I would bind 5000 to localhost only and would proxy only http requests from nginx to it
    – Rui F Ribeiro
    Nov 30 at 8:40
















  • I would bind 5000 to localhost only and would proxy only http requests from nginx to it
    – Rui F Ribeiro
    Nov 30 at 8:40















I would bind 5000 to localhost only and would proxy only http requests from nginx to it
– Rui F Ribeiro
Nov 30 at 8:40




I would bind 5000 to localhost only and would proxy only http requests from nginx to it
– Rui F Ribeiro
Nov 30 at 8:40










1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










No, UFW cannot do it.



Determining whether traffic in TCP connection is valid HTTP request or not requires accepting the connection and seeing what kind of data the client is trying to send. In other words, it's content-based filtering.



UFW needs to make the decision based on the data in the initial SYN packet of the TCP connection, which contains no data. At that point you cannot tell what the client's request will be. It sounds like you'd rather need some sort of HTTP reverse proxy in front of your API, to filter out everything that is not a well-formed HTTP request for an URI applicable to your API.



Might I also suggest to you that you also have the input validation of your API improved, at least to the point that it is no longer crashable by sending in random nonsense, before you place it into production? Otherwise it really looks like your API is very likely vulnerable to a trivial denial-of-service attack, like nc your.API.server.example 5000 < /dev/urandom, or maybe nc your.API.server.example 5000 < War_and_Peace.txt, where War_and_Peace.txt is anything that is definitely larger than the input buffer of your API service.






share|improve this answer




















  • Awesome, thank you! I'm using gunicorn and there's a bug that's causing the server to not respond on certain occasions, and I think I'll test with piping in random input - great idea. Maybe I can have nginx listen on 5000 also and forward that appropriately?
    – rb612
    Nov 30 at 8:33










  • That sounds like a good approach to me.
    – telcoM
    Nov 30 at 8:34










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',
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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485076%2fufw-deny-specific-port-access-over-https%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








up vote
2
down vote



accepted










No, UFW cannot do it.



Determining whether traffic in TCP connection is valid HTTP request or not requires accepting the connection and seeing what kind of data the client is trying to send. In other words, it's content-based filtering.



UFW needs to make the decision based on the data in the initial SYN packet of the TCP connection, which contains no data. At that point you cannot tell what the client's request will be. It sounds like you'd rather need some sort of HTTP reverse proxy in front of your API, to filter out everything that is not a well-formed HTTP request for an URI applicable to your API.



Might I also suggest to you that you also have the input validation of your API improved, at least to the point that it is no longer crashable by sending in random nonsense, before you place it into production? Otherwise it really looks like your API is very likely vulnerable to a trivial denial-of-service attack, like nc your.API.server.example 5000 < /dev/urandom, or maybe nc your.API.server.example 5000 < War_and_Peace.txt, where War_and_Peace.txt is anything that is definitely larger than the input buffer of your API service.






share|improve this answer




















  • Awesome, thank you! I'm using gunicorn and there's a bug that's causing the server to not respond on certain occasions, and I think I'll test with piping in random input - great idea. Maybe I can have nginx listen on 5000 also and forward that appropriately?
    – rb612
    Nov 30 at 8:33










  • That sounds like a good approach to me.
    – telcoM
    Nov 30 at 8:34














up vote
2
down vote



accepted










No, UFW cannot do it.



Determining whether traffic in TCP connection is valid HTTP request or not requires accepting the connection and seeing what kind of data the client is trying to send. In other words, it's content-based filtering.



UFW needs to make the decision based on the data in the initial SYN packet of the TCP connection, which contains no data. At that point you cannot tell what the client's request will be. It sounds like you'd rather need some sort of HTTP reverse proxy in front of your API, to filter out everything that is not a well-formed HTTP request for an URI applicable to your API.



Might I also suggest to you that you also have the input validation of your API improved, at least to the point that it is no longer crashable by sending in random nonsense, before you place it into production? Otherwise it really looks like your API is very likely vulnerable to a trivial denial-of-service attack, like nc your.API.server.example 5000 < /dev/urandom, or maybe nc your.API.server.example 5000 < War_and_Peace.txt, where War_and_Peace.txt is anything that is definitely larger than the input buffer of your API service.






share|improve this answer




















  • Awesome, thank you! I'm using gunicorn and there's a bug that's causing the server to not respond on certain occasions, and I think I'll test with piping in random input - great idea. Maybe I can have nginx listen on 5000 also and forward that appropriately?
    – rb612
    Nov 30 at 8:33










  • That sounds like a good approach to me.
    – telcoM
    Nov 30 at 8:34












up vote
2
down vote



accepted







up vote
2
down vote



accepted






No, UFW cannot do it.



Determining whether traffic in TCP connection is valid HTTP request or not requires accepting the connection and seeing what kind of data the client is trying to send. In other words, it's content-based filtering.



UFW needs to make the decision based on the data in the initial SYN packet of the TCP connection, which contains no data. At that point you cannot tell what the client's request will be. It sounds like you'd rather need some sort of HTTP reverse proxy in front of your API, to filter out everything that is not a well-formed HTTP request for an URI applicable to your API.



Might I also suggest to you that you also have the input validation of your API improved, at least to the point that it is no longer crashable by sending in random nonsense, before you place it into production? Otherwise it really looks like your API is very likely vulnerable to a trivial denial-of-service attack, like nc your.API.server.example 5000 < /dev/urandom, or maybe nc your.API.server.example 5000 < War_and_Peace.txt, where War_and_Peace.txt is anything that is definitely larger than the input buffer of your API service.






share|improve this answer












No, UFW cannot do it.



Determining whether traffic in TCP connection is valid HTTP request or not requires accepting the connection and seeing what kind of data the client is trying to send. In other words, it's content-based filtering.



UFW needs to make the decision based on the data in the initial SYN packet of the TCP connection, which contains no data. At that point you cannot tell what the client's request will be. It sounds like you'd rather need some sort of HTTP reverse proxy in front of your API, to filter out everything that is not a well-formed HTTP request for an URI applicable to your API.



Might I also suggest to you that you also have the input validation of your API improved, at least to the point that it is no longer crashable by sending in random nonsense, before you place it into production? Otherwise it really looks like your API is very likely vulnerable to a trivial denial-of-service attack, like nc your.API.server.example 5000 < /dev/urandom, or maybe nc your.API.server.example 5000 < War_and_Peace.txt, where War_and_Peace.txt is anything that is definitely larger than the input buffer of your API service.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 30 at 8:05









telcoM

15.2k12143




15.2k12143











  • Awesome, thank you! I'm using gunicorn and there's a bug that's causing the server to not respond on certain occasions, and I think I'll test with piping in random input - great idea. Maybe I can have nginx listen on 5000 also and forward that appropriately?
    – rb612
    Nov 30 at 8:33










  • That sounds like a good approach to me.
    – telcoM
    Nov 30 at 8:34
















  • Awesome, thank you! I'm using gunicorn and there's a bug that's causing the server to not respond on certain occasions, and I think I'll test with piping in random input - great idea. Maybe I can have nginx listen on 5000 also and forward that appropriately?
    – rb612
    Nov 30 at 8:33










  • That sounds like a good approach to me.
    – telcoM
    Nov 30 at 8:34















Awesome, thank you! I'm using gunicorn and there's a bug that's causing the server to not respond on certain occasions, and I think I'll test with piping in random input - great idea. Maybe I can have nginx listen on 5000 also and forward that appropriately?
– rb612
Nov 30 at 8:33




Awesome, thank you! I'm using gunicorn and there's a bug that's causing the server to not respond on certain occasions, and I think I'll test with piping in random input - great idea. Maybe I can have nginx listen on 5000 also and forward that appropriately?
– rb612
Nov 30 at 8:33












That sounds like a good approach to me.
– telcoM
Nov 30 at 8:34




That sounds like a good approach to me.
– telcoM
Nov 30 at 8:34

















draft saved

draft discarded
















































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.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • 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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485076%2fufw-deny-specific-port-access-over-https%23new-answer', 'question_page');

);

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






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay