how come on a natted port 80 a blocked ip can still telnet in
-
I discovered something weird.
I have a http server on port 80 and 443
I have several name based vhosts some reachable on the outside some only local (no public ip is set).Wan rules / NAT everything works.
Wen i block a public ip say my other computer tethering via my mobile i can't reach my http/https anymore ofcourse.
Except i can still telnet port 80 even if the ip is blocked.
I see the connection in the pfsense log comming in blocked but destination is the local ip of my http server. (?)I cannot telnet port 443
if i disable the wan rule for port 80 and 443 i can stil telnet in on port 80.
if i disable the nat i can't telnet in anymore.If i disable port 80 and only enable port 443 i can not telnet in anymore.
So the weird thing is how come i can still telnet in on port 80 even if i have blocked the ip on the wan?
I discovered this because somebody is telnetting my port 80 like crazy.
I blocked the ip but it stil went on.
So i started testing with telnet on my pfsense box from the outside.I want to have port 80 and port 443 open but wen i block a ip i don't want them to be able to still telnet in on port 80.
-
Hi, show your :
WAN rules.
NAT rules. -
@Gertjan said in how come on a natted port 80 a blocked ip can still telnet in:
Hi, show your :
WAN rules.
NAT rules.I agree @Gerard64, you need to show these. Without seeing them, I would guess you have the allow traffic rule on your WAN interface above the block traffic rule for that specific address you are talking about.
If this is the case, the allow rule takes precedence, since pfsense rules are evaluated from the top of the list down, first match wins, everything else is ignored.
Jeff
-
Hmm i understand. Your right i should share the wan and nat rules with you if i would like an answer/help.
But i don't want to put that information out on a forum.
It sucks because now i have to close port 80 and only have 443 open for my webserver because of this.A moderator can delete this message.
I am sorry to waste your time guys.I use pfsense for many years i know rules are evaluated top down.
If i block someone they can't reach the webserver anymore and i see it in the logs it is blocked.
If i however telnet with a blocked ip on port 80 i can still connect even if the ip is blocked and on top of the rules and everything. Somebody who knows this is filling my logs like crazy from digitalocean from AWS ip'sIf i test it for myself it works i can telnet in even if i blocked my test ip.
test it and you wil see.I understand you can't help me with it because i don't want to share my nat and wan rules.
I understand and accept that. -
You can "sanitize" your screenshots/pictures of your rules if you have access to an image editor program.
Check out mine, no big deal really.
Meaning... erase or blur out any IP addresses you don't want the forum to see. People do that here all the time. You don't have to erase or blur out any "internal" network IP addresses, since these can't be reached anyway. They are irrelevant to the users out on the web, since most of us are running some variation of the non-addressable IPv4 rfc1918 network space inside our LAN networks, all blocked off with firewalls of some type.
You can tell what services I'm running internally, due to the port(s) numbers and descriptions being visible, but that's about it.
Jeff
-
@akuma1x You have a duplicate rule there. Your VNC rule for 10.0.1.138 is repeated.
-
@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.
