how come on a natted port 80 a blocked ip can still telnet in
-
@KOM said in how come on a natted port 80 a blocked ip can still telnet in:
@akuma1x You have a duplicate rule there. Your VNC rule for 10.0.1.138 is repeated.
Thanks! I just caught that myself too, as I was blurring stuff out and posting.
Jeff
-
@akuma1x oke i blurred few things.
I use many aliases so a lot is not directly visible on the images.
Hopefully it is helpful.
-
OK, so whom are you trying to block, and to what? I see a bunch of pfB blocks, but nothing else.
I just tried this. I could reach my DMZ web server via WAN. Then I blocked myself and tried the telnet while doing a packet capture. No connection and zero packets.
-
The first time i noticed this was wen i saw a massive amount of incoming connections from a IP that are on a pfblockerng list. Besides that, i saw the destination was the local private ip adres of my webserver in de dmz. Normaly this does not happen but destination should be my pub ip.
That got my attention and i started to search how i could copy that behavior.
After a lot of searching i figured out i could do it with telnet.I connected my webserver from the outside first the normal way that worked. Then I blocked the ip so i could not connect anymore to the webserver.
But wen I telnet to the pub ip of the pfsense i could connect and enter
GET / HTTP/1.1
Few seconds later the connection was dropped by the server without any output.In the firewall log i see the blocked ip connecting to the local ip of my webserver just like the ones i saw earlier coming in from digitalOcean and AWS ip's.
The digitalOCean and AWS ip's are blocked by pfblocker lists and the block of my test ip i added to the top of the wan rules. I have many block lists not everything is visible on the image.
-
Show the block rule you created.
-
@KOM
It is deleted now I am done with testing.
It was the same as the pfblocker block rules.
It was blockedIt is not only this test block rule, the block rules of pfblocker show the same behavior thats were i first saw it happen.
You can see the most pfblocker rules in the wan image. -
This image shows what happens wen i open port 80 again.
The bottom 2 lines is with port 80 removed.
Wen i add port 80 again you see the top 2 lines connecting to my local webserver.
While the source ip is still blocked.wen port 80 is removed i cannot telnet in from the internet, the outside.
Wen port 80 is added but the public test ip is blocked i can telnet in while the log says it is blocked to the local ip of the webserver.I can not visit any website telnet gives no output other then CONNECTED.
How can it be connected wen i block the ip?
-
Those aren't connections, they're hits on a block rule that shows you the intended destination. With your NAT enabled, it shows you the LAN server that's the destination of the connection attempt. With the NAT disabled, it shows you your WAN address. You can try to telnet but it won't make a connection. To verify, change the block rule to a reject rule. That way your WAN will close the connection instead of letting it timeout, and you will know right away if something is blocked or not.
-
I should not be able to telnet in wen a ip is blocked.
Telnet shows connected. If i try the same with port 443 it does not give the text connected.It is hard to explain i guess.
I know it looks like both are blocked correctly but it is not.
The top 2 lines of the log image should not happen to the local ip it should show blocked to the pub ip. and not say connected in the telnet client side. -
I don't believe that's correct. You think you're connecting, but it's just timing out. I explained why the block log shows what it shows. For definitive proof, do a packet capture on the interface that your server is on, and filter it to just the server's IP address and then start and do your telnet test. Stop the capture and you wont see ANY packets have passed.
And like I said earlier, change your block rule to a reject rule and see what happens.
-
It gives a timeout on any other port.
Wen I use port 80 it is connected.
And its not only me who knows this other people know this too because that is how i saw this.I probably don't explain it the right way.
I also tested reject and many more things befor i start posting here on the forum.
I started up a other system again and connected via my mobile (tethering) just to take this screenshot.
Everything that is blurred out is the public ip of the pfsense box.
-
Do the packet capture (Diagnostics - Packet Capture) and see if any traffic goes out to your server.
-
It looks like it is not connecting to the local webserver.
But it is connecting something (maybe the firewall itself) on port 80 from the outside.The destination ip in this wireshark screenshot is the public ip of my pfsense box.
-
No, it's not connecting to anything. Your telnet session isn't doing anything but knocking on the door and waiting. Shortly, it will time out. The session only ever sends SYN packets and never gets a SYN ACK back, so no TCP connection is established. It doesn't matter what telnet thinks is happening or what it says. It's not really connecting. Your firewall logs shows blocks every time you try to connect and no traffic is passed out the interface.
-
Still there is a difference:
Wen i remove the port 80 from the http_https ports alias i get a different outcome a timeout.
Wen i add port 80 to the http_https ports alias i get a connection with telnet on port 80.And in both these tests a different log entry.
The first a block on the public ip and the second on the local ip of the webserver.Specially since somebody is hitting my pfsense box this way, for several days, with a lot of different ip addresses all day and night.
I don't know what his plan is but i am not comfortable with it.
-
I've explained everything already and I don't know what else to tell you.
-
Oke i understand.
Thank you a lot for helping and thinking with me.
I am not yet reassured but that's probably my stubborn brain i am sorry for that.Good night sir.
-
@Gerard64 said in how come on a natted port 80 a blocked ip can still telnet in:
But i don't want to put that information out on a forum.
Here a my WAN rules :
Tell, me : am I at risk now ?
Btw : I was one NAT rule : the one that gives "Source" hosts access to my "diskstation".
edit : the NAT rule :
