PF PF creates states for blocked addresses

D

darkemon

Hello!
I've got some troubles in my testing network and noticed that PF doesn't block traffic properly.

My FreeBSD 12.1 machine has 2 interfaces, the both are in the same L2 segment:
em0 - LAN 192.168.17.92
em1 - WAN 192.168.170.92

pf.conf:
Code: 
nat log on em1 from 192.168.17.0/24 to any -> { 192.168.170.92 }

block in log on em1 all tag BLOCK
pass out log on em1 all tag PASS
block in log on em0 all tag BLOCK                                 
pass out log on em0 all tag PASS

pass in log quick on em0 proto tcp from 192.168.17.0/24 to self port 22 tag PASS

block quick log tagged BLOCK

In that network I've got udp packets that come to both interfaces simultaneously:
Code: 
16:16:42.223247 f4:4d:30:e3:d9:f0 > 00:e0:4c:68:00:01, ethertype IPv4 (0x0800), length 154: 192.168.0.10.162 > 192.168.0.10.162:  C=dd_cc_62_6c_69_63 Trap(97)  .1.3.6.1.4.1.3183.1.1 192.168.0.10 enterpriseSpecific s=2453248 1014325720 .1.3.6.1.4.1.3183.1.1.1=00_11_22_33_44_55_66_77_88_99_aa_bb_cc_dd_ee_ff_1c_cf_00_00_00_00_ff_ff_50_68_01_c8_01_17_00_00_00_00_00_00_00_00_00_19_00_00_6a_92_22_11_c1

Behavior of PF is:
Code: 
 00:00:08.436901 rule 9/0(match): block in on em0: 192.168.0.10.162 > 192.168.0.10.162:  C=dd_cc_62_6c_69_63 Trap(97)  .1.3.6.1.4.1.3183.1.1 192.168.0.10 enterpriseSpecific s=2453248 1014325720 .1.3.6.1.4.1.3183.1.1.1=00_11_22_33_44_55_66_77_88_99_aa_bb_cc_dd_ee_ff_1c_cf_00_00_00_00_ff_ff_50_68_01_c8_01_17_00_00_00_00_00_00_00_00_00_19_00_00_6a_92_22_11_c1
00:00:00.000187 rule 9/0(match): block in on em1: 192.168.0.10.162 > 192.168.0.10.162:  C=dd_cc_62_6c_69_63 Trap(97)  .1.3.6.1.4.1.3183.1.1 192.168.0.10 enterpriseSpecific s=2453248 1014325720 .1.3.6.1.4.1.3183.1.1.1=00_11_22_33_44_55_66_77_88_99_aa_bb_cc_dd_ee_ff_1c_cf_00_00_00_00_ff_ff_50_68_01_c8_01_17_00_00_00_00_00_00_00_00_00_19_00_00_6a_92_22_11_c1
00:00:00.000128 rule 1/0(match): pass out on em1: 192.168.0.10.162 > 192.168.0.10.162:  C=dd_cc_62_6c_69_63 Trap(97)  .1.3.6.1.4.1.3183.1.1 192.168.0.10 enterpriseSpecific s=2453248 1014325720 .1.3.6.1.4.1.3183.1.1.1=00_11_22_33_44_55_66_77_88_99_aa_bb_cc_dd_ee_ff_1c_cf_00_00_00_00_ff_ff_50_68_01_c8_01_17_00_00_00_00_00_00_00_00_00_19_00_00_6a_92_22_11_c1


At the moment it doesn't matter why there are such packets, another thing is interesting for me: why does PF pass out this traffic?
 
VladiBG said:
what is the output of pfctl -sa
Click to expand...
Code: 
root@archer:~ # pfctl -sa
TRANSLATION RULES:
nat log on em1 inet from 192.168.17.0/24 to any -> 192.168.170.92

FILTER RULES:
block drop in log on em1 all tag BLOCK
pass out log on em1 all flags S/SA keep state tag PASS
block drop in log on em0 all tag BLOCK
pass out log on em0 all flags S/SA keep state tag PASS
pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 192.168.17.92 port = ssh flags S/SA keep state tag PASS
pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 192.168.170.92 port = ssh flags S/SA keep state tag PASS
pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 127.0.0.1 port = ssh flags S/SA keep state tag PASS
pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 172.77.77.253 port = ssh flags S/SA keep state tag PASS
pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 172.77.77.1 port = ssh flags S/SA keep state tag PASS
block drop log quick all tagged BLOCK
No queue in use

STATES:
all udp 192.168.0.10:162 -> 192.168.0.10:162       MULTIPLE:MULTIPLE
all tcp 192.168.17.92:22 <- 192.168.17.49:57722       ESTABLISHED:ESTABLISHED

INFO:
Status: Enabled for 0 days 00:01:39           Debug: Urgent

State Table                          Total             Rate
  current entries                        5               
  searches                            2572           26.0/s
  inserts                                6            0.1/s
  removals                               1            0.0/s
Counters
  match                               2002           20.2/s
  bad-offset                             0            0.0/s
  fragment                               0            0.0/s
  short                                  0            0.0/s
  normalize                              0            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                              0            0.0/s
  proto-cksum                            0            0.0/s
  state-mismatch                         0            0.0/s
  state-insert                           0            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s
  map-failed                             0            0.0/s

TIMEOUTS:
tcp.first                   120s
tcp.opening                  30s
tcp.established           86400s
tcp.closing                 900s
tcp.finwait                  45s
tcp.closed                   90s
tcp.tsdiff                   30s
udp.first                    60s
udp.single                   30s
udp.multiple                 60s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         30s
interval                     10s
adaptive.start            60000 states
adaptive.end             120000 states
src.track                     0s

LIMITS:
states        hard limit   100000
src-nodes     hard limit    10000
frags         hard limit     5000
table-entries hard limit   200000

TABLES:

OS FINGERPRINTS:
762 fingerprints loaded
 
Ok, try to flush your state table which contain
Code: 
all udp 192.168.0.10:162 -> 192.168.0.10:162       MULTIPLE:MULTIPLE

and then after a while check if this state appear again.
To flush the state table use pfctl -F states

In general is better to separate the em0 domain from em1 using vlans. You can also try to log the traffic and check what cause this snmp trap
 
VladiBG said:
Ok, try to flush your state table which contain
Code: 
all udp 192.168.0.10:162 -> 192.168.0.10:162       MULTIPLE:MULTIPLE
ap
and then after a while check if this state appear again.
Click to expand...
I've done that already. The state appears again.

VladiBG said:
In general is better to separate the em0 domain from em1 using vlans.
Click to expand...
I understand that, it's just testing network and I'm seeking the source of this snmp trap, but this is an another story.
 
Do you have this IP address (192.168.0.10) on your server? Also can you display the rule numbers using pfctl -sr -vv to see which one is rule number 1 which match the first in your log at
00:00:00.000128 rule 1/0(match)

p.s.
Also try to remove the tagging
 
VladiBG said:
Do you have this IP address (192.168.0.10) on your server? Also can you display the rule numbers using pfctl -sr -vv to see which one is rule number 1 which match the first in your log at
00:00:00.000128 rule 1/0(match)

p.s.
Also try to remove the tagging
Click to expand...
I don't have the IP 192.168.0.10 anywhere in my network.

Code: 
root@archer:~ # pfctl -sr -vv
@0 block drop in log on em1 all tag BLOCK
  [ Evaluations: 9552      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 95411 State Creations: 0     ]
@1 pass out log on em1 all flags S/SA keep state tag PASS
  [ Evaluations: 1238      Packets: 3821      Bytes: 332868      States: 4     ]
  [ Inserted: uid 0 pid 95411 State Creations: 12    ]
@2 block drop in log on em0 all tag BLOCK
  [ Evaluations: 9551      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 95411 State Creations: 0     ]
@3 pass out log on em0 all flags S/SA keep state tag PASS
  [ Evaluations: 1327      Packets: 2162      Bytes: 181600      States: 1     ]
  [ Inserted: uid 0 pid 95411 State Creations: 2     ]
@4 pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 192.168.17.92 port = ssh flags S/SA keep state tag PASS
  [ Evaluations: 1327      Packets: 334       Bytes: 31086       States: 1     ]
  [ Inserted: uid 0 pid 95411 State Creations: 1     ]
@5 pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 192.168.170.92 port = ssh flags S/SA keep state tag PASS
  [ Evaluations: 49        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 95411 State Creations: 0     ]
@6 pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 127.0.0.1 port = ssh flags S/SA keep state tag PASS
  [ Evaluations: 49        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 95411 State Creations: 0     ]
@7 pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 172.77.77.253 port = ssh flags S/SA keep state tag PASS
  [ Evaluations: 49        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 95411 State Creations: 0     ]
@8 pass in log quick on em0 inet proto tcp from 192.168.17.0/24 to 172.77.77.1 port = ssh flags S/SA keep state tag PASS
  [ Evaluations: 49        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 95411 State Creations: 0     ]
@9 block drop log quick all tagged BLOCK
  [ Evaluations: 9550      Packets: 2512      Bytes: 255604      States: 0     ]
  [ Inserted: uid 0 pid 95411 State Creations: 0     ]

I'll try without tagging a bit later.
 
The ip address may be set in IPMI inside the firmware of your network adapter. What you see in the log is the packet first match @1 and get a tag PASS which create a dynamic state in the states table. According the snmp trap it's from 1.3.6.1.4.1.3183.1.1 https://mibs.observium.org/mib/DELL-ASF-MIB/

Remove the tags and add block rule for outgoing traffic for udp port 164
 
VladiBG said:
The ip address may be set in IPMI inside the firmware of your network adapter. What you see in the log is the packet first match @1 and get a tag PASS which create a dynamic state in the states table. According the snmp trap it's from 1.3.6.1.4.1.3183.1.1 https://mibs.observium.org/mib/DELL-ASF-MIB/

Remove the tags or reorder your rules. You don't need the tags.
Click to expand...

Hmm, I'll check it. But I don't understand why packet matches "pass out" rule, it is blocked by "block in" rules and shouldn't get into the system.
I checked another configuration and it works as has to:
Code: 
nat log on em1 from 192.168.17.0/24 to any -> { 192.168.170.92 }

block in log on em1 all
pass out log quick on em1 all
block in log on em0 all
pass out log quick on em0 all

pass in log quick on em0 proto tcp from 192.168.17.0/24 to self port 22
block quick log
 
VladiBG said:
The ip address may be set in IPMI inside the firmware of your network adapter.
Click to expand...
To find out install sysutils/ipmitool. Then kldload ipmi and ipmitool lan print.

IPMI and the ethernet ports are often shared. It's better to configure IPMI to use its own dedicated interface (if the machine has one).
 
out of band traffic must be not visible for the host even on the shared port which is strange. I suspect that it's not tagged with tag BLOCK and that's why the first packet is routed between em0 and em1 and match the out rule @1 pass out on em1

tcpdump will help here.


f4:4d:30:e3:d9:f0 > 00:e0:4c:68:00:01

Elitegroup Computer Systems Co.,Ltd --> REALTEK SEMICONDUCTOR CORP
 
VladiBG said:
out of band traffic must be not visible for the host even on the shared port which is strange. I suspect that it's not tagged with tag BLOCK and that's why the first packet is routed between em0 and em1 and match the out rule @1 pass out on em1

tcpdump will help here.


f4:4d:30:e3:d9:f0 > 00:e0:4c:68:00:01

Elitegroup Computer Systems Co.,Ltd --> REALTEK SEMICONDUCTOR CORP
Click to expand...
I found machine with f4:4d:30:e3:d9:f0 and it isn't my FreeBSD machine, it's Windows workstation. I checked it with wireshark and didn't find any snmp traffic, it looks like ipmi and is invisible for the Windows host as you said.
 
You must log in or register to reply here.
Back
Top