Can't block ports 135, 139, 445

[N10n105]

I m using FreeBSD as router / firewall (pf with altq enable).
After I do make a scan (nmap from outside) on my system I discover that the ports 135, 139, 445 was opened / filtered.
I do add rules to block the ports like the following

block in log quick on $ext_if proto {tcp udp} from any to any port 135

I test those ports with (http://www.canyouseeme.org) and the response was "Connection timed out." and
not "Connection refused" as expected. (the same result I get when I telnet from outside.)
Just in case I block my a testing web server and the response was as expected "Connection refused."

There is no daemon runs or use of those ports on my system is there something special about these ports ?

 

[asteriskRoss]

From your post, I understand you have configured your /etc/pf.conf with:

set block-policy return

You therefore expect a "connection refused" response from all blocked ports.

It is likely that your ISP has blocked the ports 135, 139 and 445 (relating to Windows file sharing), since they were so commonly used for attacking Windows machines before software firewalls became the norm. You will likely find that 137 and 138 are also blocked. If I am right, your ISP's firewall is silently dropping the traffic to these ports. You could confirm this by using tcpdump(1) to monitor incoming traffic on these ports to your firewall and then initiating a connection from outside your network. I expect that your firewall will never receive the packets. Since you are intending to block the ports anyway, there isn't anything to be gained by asking your ISP to change their firewall's behaviour.

 

[N10n105]

Thanks for your quick answer but as you will see the ISP don't block those ports.
I start the tcpdump() as follows
tcpdump -n -e -vvv -ttt -i pflog0

Then on a remote machine I did the port test as follows
knoppix@Microknoppix:~$ time telnet 85.73.159.xxx 135

Trying 85.73.159.xxx...
telnet: Unable to connect to remote host: Connection timed out

real	2m7.249s
user	0m0.000s
sys	0m0.000s

The tcpdump() result was

00:01:55.979441 rule 22..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 6730, offset 0, flags [none], proto TCP (6), length 60)
    79.129.106.xxx.25086 > 85.73.159.xxx.135: Flags [S], cksum 0x6bdb (correct), seq 912301163, win 29200, options [mss 1442,sackOK,TS val 99873 ecr 0,nop,wscale 7], length 0
00:00:00.993907 rule 22..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 6731, offset 0, flags [none], proto TCP (6), length 60)
    79.129.106.xxx.25086 > 85.73.159.xxx.135: Flags [S], cksum 0x6aae (correct), seq 912301163, win 29200, options [mss 1442,sackOK,TS val 100174 ecr 0,nop,wscale 7], length 0
00:00:02.010203 rule 22..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 6732, offset 0, flags [none], proto TCP (6), length 60)
    79.129.106.xxx.25086 > 85.73.159.xxx.135: Flags [S], cksum 0x6854 (correct), seq 912301163, win 29200, options [mss 1442,sackOK,TS val 100776 ecr 0,nop,wscale 7], length 0
00:00:04.011280 rule 22..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 6733, offset 0, flags [none], proto TCP (6), length 60)
    79.129.106.xxx.25086 > 85.73.159.xxx.135: Flags [S], cksum 0x63a0 (correct), seq 912301163, win 29200, options [mss 1442,sackOK,TS val 101980 ecr 0,nop,wscale 7], length 0
00:00:05.982672 rule 22..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 6734, offset 0, flags [none], proto TCP (6), length 60)
    79.129.106.xxx.25086 > 85.73.159.xxx.135: Flags [S], cksum 0x5a3c (correct), seq 912301163, win 29200, options [mss 1442,sackOK,TS val 104384 ecr 0,nop,wscale 7], length 0
00:00:16.056577 rule 22..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 6735, offset 0, flags [none], proto TCP (6), length 60)
    79.129.106.xxx.25086 > 85.73.159.xxx.135: Flags [S], cksum 0x476c (correct), seq 912301163, win 29200, options [mss 1442,sackOK,TS val 109200 ecr 0,nop,wscale 7], length 0
00:00:32.057103 rule 22..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 6736, offset 0, flags [none], proto TCP (6), length 60)
    79.129.106.xxx.25086 > 85.73.159.xxx.135: Flags [S], cksum 0x21dc (correct), seq 912301163, win 29200, options [mss 1442,sackOK,TS val 118816 ecr 0,nop,wscale 7], length 0

But when I telnet the other port that I block from outside the result was:

knoppix@Microknoppix:~$ time telnet 85.73.159.xxx 5005

Trying 85.73.159.xxx...
telnet: Unable to connect to remote host: Connection refused

real	0m0.072s
user	0m0.000s
sys	0m0.000s

And the tcpdump output was

00:00:35.546799 rule 20..16777216/0(match): block in on ng0: (tos 0x10, ttl 56, id 20183, offset 0, flags [none], proto TCP (6), length 60)
79.129.106.xxx.25708 > 85.73.159.xxx.5005: Flags [S], cksum 0x5088 (correct), seq 2914139959, win 29200, options [mss 1442,sackOK,TS val 225760 ecr 0,nop,wscale 7], length 0

I hope this is more helpful. Just in case I like to add that I use mpd5 to make connection to the internet using bridged ADSL modem.

 

[asteriskRoss]

You're right: no blocking from your ISP. What version of FreeBSD are you running? Can you post a sanitised version of your /etc/pf.conf?

 

[N10n105]

The FreeBSD version is uname -a

FreeBSD control01 10.0-RELEASE-p2 FreeBSD 10.0-RELEASE-p2 #2 r265820: Sun May 11 08:53:56 EEST 2014     root@control02:/usr/obj/usr/src/sys/PF_ALTQ  i386

At the GENERIC configuration file i add the follwing to enable the PF ALTQ option

## PF_ALTQ MY SETTINGS
#makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols
#makeoptions	WITH_CTF=1		# Run ctfconvert(1) for DTrace support

device pf
device pflog
device pfsync

options         ALTQ
options         ALTQ_CBQ        # Class Bases Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)
options         ALTQ_NOPCC      # Required for SMP build

####

Here is minimal a minimal pf.conf file which produces the same issue with 135 port.

ext_if="ng0"
int_if="xl0"

set skip on lo0
set block-policy return

#Nat Translation
nat on $ext_if from !($ext_if) to any -> ($ext_if)

rdr on $ext_if inet proto tcp from any to ($ext_if) port 80 -> 192.168.3.12 port 80

#block in log all

block in log quick on $ext_if proto { tcp udp } from any to any port 5005 
block in log quick on $ext_if proto { tcp udp } from any to any port 5006

block in log quick on $ext_if proto { tcp udp } from any to any port 135

 

[kpa]

Again, it's not a surprise that you get the filtered result in the scan. The block-policy return line tells PF to return RST for blocked TCP connections instead of staying quiet (and I think some ICMP packet for UDP, can't remember exactly...). Change the rule to:

block drop in log quick on $ext_if proto { tcp udp } from any to any port 135

The thing that may confuse you is that PF will return that RST packet if block policy is set to "return" even if there's nothing listening on the port, PF takes over handling of the port so to speak if you write block rules that block the specific port.

One other thing, PF defaults to passing everything trough unless there's a "default deny" rule in the rules. It would be a very good idea to re-activate the block in all rule that you have now commented out and adjust the rest of the rules for the situation if needed.

 

[asteriskRoss]

@kpa: I believe @N10n105 is expecting to receive a RST packet when probing port 135 but isn't currently receiving one.

@N10n105: Like you, I can't see anything in your PF configuration. Have you checked whether the RST packet is being sent from your firewall's external interface (with tcpdump(1))? The possibility I want to eliminate is that the RST packet is being sent but blocked somewhere between you and your external test machine. If your machine is physically local to you, you could also check by connecting directly to your firewall's external interface (with no other machines in between) and confirm that you are experiencing the same behaviour.

 

[N10n105]

Sorry for the delay but I want to be sure before come to any conclusions.I perform the test using PPPoE dial up so I can have clear tcpdump results witch shows that ISP blocks the 135, 139 and 445. So the RST packet which PF firewall sends is blocked and never reaches the host trying to connect on port 135.

Case closed ;-)