Block TCP 445 in LAN out WAN2
-
1/ We have no idea what's your LAN and WAN.
2/ I sincerely hope you do not allow SMB from WAN. :o ::) -
I know, I'm trying to paint as clear a picture I can.
Note: WAN2 is not the internet, it's another network.
Note: WAN is the Internet
-
pfSense is a stateful firewall. When you let traffic in, corresponding traffic will be let out.
P.S. Calling something WAN when it's not WAN does not help to get "clear picture". It does the exact opposite.
-
Below is packet capture on the WAN2 Interface:
12:22:00.217546 IP 172.16.0.31.445 > 172.18.2.12.28706: tcp 1460
12:22:00.217578 IP 172.16.0.31.445 > 172.18.2.12.28706: tcp 1460
12:22:00.219499 IP 172.18.2.12.28706 > 172.16.0.31.445: tcp 0Computer 172.16.0.31 (LAN) is sending the traffic with source port 445 to WAN2 IP, Right?
Was this captured after doing the reset states? If you didn't do that, any existing connection would probably still work. If 0.31 is on LAN, 2.12 is on WAN2, it may be that 2.12 initiated the connection, so adding a block inbound on WAN2 to dst port 445 may also be needed. The block outbound from LAN to dst port 445 prevents LAN from initiating the connection, but does not prevent a connection from outside of LAN to dst port 445.
(I think this is what dok means with the emphasis on stateful)
-
Yeah when you don't want two networks to talk over SMB you need the block rule on both interfaces, with the opposite subnet as destination.
-
In effort to be more clear, what to a call a "remote network", that is not the internet?
Diagram:
PFSENSE
[LAN] <–-------> /--------------/ <-------> [WAN]
172.16.0.0 / /
/–------------/ <-------> [WAN2] 10.10.10.34 <–-> [ROUTER] <–--> 172.18.0.0/ 22
10.10.10.36 REMOTE SITE -
Testing…
-
(WAN2 –> REMOTE SITE interface Rules
ID Proto Source Port Destination Port Gateway Queue Schedule Description
BLOCK IPv4 TCP * * * 445 (MS DS) * none Block Inbound Destination 445 From ALL
ALLOW IPv4 * * * * * * none Allow all traffic to and from otherStill not blocking...
-
1/ You need this on BOTH interfaces.
2/ You need to reset the states (or reboot the firewall box if unabled to find the button to do so).If you think it's still not blocked then stick logging on the rules and look at the firewall logs.
P.S. Learn to produce screenshots instead of broken ASCII art.
-
Will provide screen shots from now on, did not know I could do that.
I will Reset states again…
-
First of all I want to thank Doktornotor for pointing out the System,States (and the ability to reset them), this was causing me false positives on my earlier testing.
Second, I want to thank Mer, for putting the stateful blocking logic as it related directly to my situation and helped to see the initial incoming connection.
After I added the correct rule, above, I did not reset the states, so it did not block.
Thank You, guys the blocking is working.
ALSO, There was one thing I did not understand/anticipate with MS SMB, after port 445 was blocked, the workstation decided to change to port 139, so my block worked, but my test failed as the file transfer was still going on. Once I blocked 445 and 139 TCP, all worked/Blocked which is what I wanted.
Thank You!
-
Honestly, if this Windows NetBIOS/file sharing stuff is undesired, block 135-139 and 445, TCP/UDP.
-
guess I don't get any love for pointing out his rule was backwards.. ;)
-
John, you have to let some of us catch up in karma first :)
OP:
Don't forget that all the ports should have a default deny as the first thing (it's there already you don't have to add it). This makes it really nice: if everything is blocked by default, then you have a smaller list of "allow this". It feels backwards (like an old HP RPN calculator) but it makes things a lot easier on you. On my setup I have 7 TCP services plus 3 UDP allowed, a lot simpler than "need to block this, block that,crap missed that one". There may be a few things I could add, but so far noone has complained.
