View Single Post
  #2   (View Single Post)  
Old 24th October 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Quote:
I'm a total newbie in pf...
Keep these in mind whenever you are considering using PF for filtering:
  1. The last matching pass/block rule wins (unless the quick option is used.)

    This means if you have two rules that will match, put the general case first, the specfic case second. For example, put your pass rule allowing users to reach the web (eg: destination ports 80 for HTTP and 443 for HTTPS) before the block rule for the specific addresses you want blocked.
  2. PF is a network layer 3 filter (unless you are filtering a bridge device, which permits filtering of Ethernet frames). PF may not be appropriate for all needs -- and probably not for your intended use case.

    PF filtering is limited to rules regarding the Internet Protocol ("IP") and its suite of subordinate IP protocols that are referred to generally as "TCP/IP". We write PF rules for the three IP protocols TCP, UDP, and ICMP, though there are others that are used and may need rules written as well. For example, I use the ESP protocol as a component of my ipsec(4) implementation. A complete list of IP protocols can be found listed in /etc/protocols, if you're interested.

    PF does not deal with higher level protocols used in applications, such as the HTTP protocol. It does not inspect packets for content, such as the contents of an HTTP GET request destined for www.facebook.com.

    While Domain names can be used in PF rules for convenience, they are resolved to IP addresses at rule initiation time only, and the administrator needs to be sure they can be resolved at boot time for the rules to work.
  3. Other tools will inspect the higher protocols and make decisions based on the data found in the packets. For HTTP traffic, the tool most commonly deployed is the http proxy server. The network admin routes outgoing HTTP traffic through the server for this inspection, and the proxy server decides whether to pass or block the traffic.

    Routing HTTP traffic through proxy server can be done by browser settings at each client, or can be done via a packet filter such as PF. PF may not inspect the HTTP traffic, but rules can be written to redirect such traffic through a proxy server if so identified. As an example of this, and mentioned in the first paragraph, the HTTP protocol is carried within TCP packets and the server listens for traffic on TCP port 80.
Quote:
It worked after I commented out 'pass out'
Is it correct to do without 'pass' ? can you help me make suck blocks better?
Not without seeing your ruleset. But remember, the last matching rule wins. Look at this two line ruleset, where both rules will always match. All traffic will be blocked, because the block rule is last:
Code:
pass all
block all
Now, a more realistic example. Here, I start by blocking all traffic. That rule always matches. Then, I permit HTTP traffic (TCP for destination port 80) from anywhere to anywhere in the second rule. It will only apply to traffic destined for servers listening to port 80. Finally, I narrow that access by blocking that sort of traffic to the network 10.10.0.0/16 in a third rule:
Code:
block all
pass proto tcp from any to any port 80
block proto tcp from any to 10.10.0.0/16 port 80
There were two recent threads on the OpenBSD misc@ mailing list this week regarding blocking facebook traffic. They may help. Links to the first post in each thread are below.

Blocking facebook.com: PF or squid?
Sorry: Facebook again
Reply With Quote