# Can't block ports 135, 139, 445



## N10n105 (Aug 24, 2014)

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 (Aug 24, 2014)

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 (Aug 25, 2014)

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 (Aug 25, 2014)

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 (Aug 25, 2014)

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 (Aug 25, 2014)

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 (Aug 25, 2014)

@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 (Sep 10, 2014)

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


----------

