DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 28th October 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Question Blocking All HTTP and HTTPS Traffic

Hi,

I have setup a Proxy server on my LAN and I want to restrict all the HTTP and HTTPS traffic from my PF. I want to allow HTTP and HTTPS traffic only to my Proxy server not to any other PC on my LAN.

How can I achieve the above?

I tried the following code but it gave a syntax error.
Code:
lan="{192.168.94.0/24}"
proxy="192.168.94.49"
and I pasted the following two lines after "pass out keep state" rule
Code:
block out tcp from $lan to any port {80,443}
pass out tcp from $proxy to any port {80,443}
Thanks

Last edited by ocicat; 31st October 2016 at 11:59 AM. Reason: Please wrap code with [code] & [/code] tags.
Reply With Quote
  #2   (View Single Post)  
Old 28th October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

The syntax error is a missing "proto" before "tcp".

Note that you are filtering TCP packets by destination port numbers. This is not the same as filtering for HTTP or HTTPS. As an example, this does not block HTTP traffic to web servers that use non-default port numbers.
Reply With Quote
  #3   (View Single Post)  
Old 31st October 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Default

Hi Jggimi,

Thanks for the information. I put the following rules
Code:
block out on $int_if proto tcp from $lan to any port = http
block out on $int_if proto tcp from $lan to any port = https
pass out on $int_if proto tcp from $proxy to any port = http keep state
pass out on $int_if proto tcp from $proxy to any port = https keep state
Now the pfctl -nf /etc/pf.conf doesn't trigger any error. But still my LAN side I can access http and https traffic without the proxy.

Do I have to apply these rules before " pass out keep state " section?

Thanks

Last edited by ocicat; 31st October 2016 at 12:01 PM. Reason: Please wrap code with [code] & [/code] tags.
Reply With Quote
  #4   (View Single Post)  
Old 31st October 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

Let us review the PF User's Guide, which states:
Quote:
Filter rules specify the criteria that a packet must match and the resulting action, either block or pass, that is taken when a match is found. Filter rules are evaluated in sequential order, first to last. Unless the packet matches a rule containing the quick keyword, the packet will be evaluated against all filter rules before the final action is taken. The last rule to match is the "winner" and will dictate what action to take on the packet. There is an implicit pass all at the beginning of a filtering ruleset, meaning that if a packet does not match any filter rule the resulting action will be pass.
If you are unsure which rule is the last to match, log your rules and use tcpdump(8) to determine which rule is applied.

Add logging to your PF rule set:
Code:
match log
Use tcpdump(8) to determine what rule is applied to traffic. The program will show you which rule numbers are passing or blocking traffic:
Code:
# tcpdump -neti pflog0
And pfctl(8) will show you the text of any rule if you supply the rule number:
Code:
# pfctl -sr -R 37

Last edited by jggimi; 31st October 2016 at 10:34 AM. Reason: typos, clarity
Reply With Quote
  #5   (View Single Post)  
Old 31st October 2016
junkym
-Guest-
 
Posts: n/a
Default

Can we see your entire pf.conf file?
Reply With Quote
  #6   (View Single Post)  
Old 1st November 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Default

Hi Junkym, Jggimi

I add the rules at the bottom of the pf.conf file, still I can access http and https traffic without the proxy server.

My pf.conf is attached herewith.

Thanks
Attached Files
File Type: conf pf-01-11-2016.conf (7.2 KB, 37 views)
Reply With Quote
  #7   (View Single Post)  
Old 1st November 2016
junkym
-Guest-
 
Posts: n/a
Default

My first thought is to add these lines towards the bottom of the file:
Code:
# BLOCK IT ALL ON INTERNAL NIC
block on $int_if all

# REDIRECT http, https LAN TRAFFIC TO PROXY SERVER
pass in on $int_if proto tcp from $lan to any port { http https } \
rdr-to $proxy

# LET http, https OUT FROM PROXY SERVER
pass out on $proxy proto tcp to any port { http https }
Reply With Quote
  #8   (View Single Post)  
Old 1st November 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Default

Thanks a lot Junkym,

I'll try these rules carefully and get back to you.

Reply With Quote
  #9   (View Single Post)  
Old 1st November 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

I see you are still using your Frankensystem, as your configuration file uses altq, removed two and a half years ago.
Reply With Quote
Old 1st November 2016
junkym
-Guest-
 
Posts: n/a
Default

Quote:
Originally Posted by jggimi View Post
I see you are still using your Frankensystem, as your configuration file uses altq, removed two and a half years ago.
I thought I might have seen this file before in my travels on this site.

I do think this particular pf.conf would greatly benefit from a clean-up.
Reply With Quote
Old 1st November 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

And I continue to recommend the steps I recommended in reply #4 above.

With that simple test, Amithapr would discover the rule that is unintentionally passing the traffic that should be blocked.

There are three possibilities:
  1. The intended block is not matching the traffic.
  2. The intended block is superseded by a later pass rule.
  3. There is a prior pass quick rule which matched, preventing any later rule from being tested.

Last edited by jggimi; 1st November 2016 at 10:59 PM. Reason: typo, clarity, and even more clarity.
Reply With Quote
Old 2nd November 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Default

Quote:
Originally Posted by junkym View Post
My first thought is to add these lines towards the bottom of the file:
Code:
# BLOCK IT ALL ON INTERNAL NIC
block on $int_if all

# REDIRECT http, https LAN TRAFFIC TO PROXY SERVER
pass in on $int_if proto tcp from $lan to any port { http https } \
rdr-to $proxy

# LET http, https OUT FROM PROXY SERVER
pass out on $proxy proto tcp to any port { http https }
Hi Junkym,

I tried these rules on my live firewall. All the http and https traffic had been blocked due to the above rules. I couldn't browse the internet via proxy as well.

Thanks.
Reply With Quote
Old 2nd November 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

The final test rule has "on $proxy" but I've noticed that $proxy is defined as an IP address. However, "on" is used for interfaces or interface groups, not IP addresses.

This last rule will never match any packets.
Reply With Quote
Old 7th November 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Default

Hi Jggimi, Junkym

If I Apply the following rule-set for the firewall is it OK?
Code:
# BLOCK IT ALL ON INTERNAL NIC
block on $int_if all

# REDIRECT http, https LAN TRAFFIC TO PROXY SERVER
pass in on $int_if proto tcp from $lan to any port { http https } \
rdr-to $proxy

# LET http, https OUT FROM PROXY SERVER
pass out on $int_if proto tcp from $proxy to any port { http https } keep state
Thanks

Last edited by ocicat; 7th November 2016 at 11:48 AM. Reason: Please use [code] & [/code] tags when posting code snippets.
Reply With Quote
Old 7th November 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

Your first rule blocks all traffic on your internal interface. Your second rule passes inbound traffic on that interface if it is TCP and has a destination port of 80 or 443.

Problems I see:
  • Your third rule appears to me to be on the wrong interface. I expect you want your proxy server to reach out to web servers via your external interface.
  • You are missing a rule to pass domain name resolution traffic between your clients on the internal interface and whatever domain name server(s) they must reach.
Reply With Quote
Old 15th November 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Default

Hi Jggimi,

I changes my rule set as follows

Code:
# BLOCK IT ALL ON INTERNAL NIC
block on $int_if all

# REDIRECT http, https LAN TRAFFIC TO PROXY SERVER
pass in on $int_if proto tcp from $lan to any port { http https } rdr-to $proxy

# LET http, https OUT FROM PROXY SERVER
pass out on $ext_if proto tcp from $proxy to any port { http https } keep state

# For DNS Traffic
pass in on $int_if proto { tcp, udp } from any to any port = 53 keep state
Still I cannot access the internet directly or via proxy.

Thanks
Reply With Quote
Old 15th November 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

I'll guess that your outbound DNS traffic is still blocked, because you are only permitting inbound DNS, not outbound DNS.

Avoid the use of "in" "out" and "on" in your rule sets unless absolutely necessary.

I'm tired of guessing. You have been struggling with this particular configuration problem for weeks. So I'll restate what I've tried to state before, and try to be as clear as I can be.
  • Traffic is being blocked.
  • You have no idea why and post fragments of pf.conf configuration files here and hope we can guess why.
  • OpenBSD has tools that can tell you EXACTLY what is happening with PF. They are as easy to use as posting to this forum, and more accurate than our guesses. You are not using them.
Here's a "How To" guide:
  1. Put the following line at the top of your /etc/pf.conf file. It adds logging to every pass and block rule in the file.
    Code:
    match log
  2. Reload your rules with # pfctl -f /etc/pf.conf
  3. Use the tcpdump(8) command to capture the PF logging you enabled. Start tcpdump() with this command. The use of a pipe "|" and tee(1) sends the output both to a file and to your shell in a console or window. The tcpdump() program will continue to run until you stop it with CTRL-C.
    Code:
    # tcpdump -neti pflog0 | tee /tmp/my.pf.log.output
  4. While tcpdump is running, test any of your failing connections.
  5. You may stop your tcpdump() program after capturing traffic with CTRL-C.
  6. In the output, you will see the traffic being filtered, whether the action was pass or block, and the rule number of the pass or block rule.
  7. To map the rule number to the specific rule in your /etc/pf.conf file, issue the command # pfctl -sr -R <number>
If a block rule is very broad, such as a first block all, then your traffic does not match any subsequent rule.

Last edited by jggimi; 15th November 2016 at 12:16 PM. Reason: clarity, typos
Reply With Quote
Old 17th November 2016
Amithapr Amithapr is offline
Fdisk Soldier
 
Join Date: Dec 2015
Posts: 55
Default

Hi Jggimi,

I changed my rules so that the DNS outbound traffic also pass through the firewall( rules are given below). But still I cannot access the internet directly or using the proxy.

the "tcpdump -neti pflog0 | tee /tmp/my.pf.log.output" commands output file is attahced herewith.

Code:
# BLOCK IT ALL ON INTERNAL NIC
block on $int_if all

# REDIRECT http, https LAN TRAFFIC TO PROXY SERVER
pass in on $int_if proto tcp from $lan to any port { http https } rdr-to $proxy

# LET http, https OUT FROM PROXY SERVER
pass out on $ext_if proto tcp from $proxy to any port { http https } keep state

# For DNS Traffic
pass in on $int_if proto { tcp, udp } from any to any port = 53 keep state
pass out on $int_if proto { tcp, udp } from any to any port = 53 keep state
Attached Files
File Type: txt mypflog.txt (330.1 KB, 18 views)
Reply With Quote
Old 17th November 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

Have you looked at this log you posted?
  • There are no pass rules logged, only match and block rules logged.
  • All of the block rules logged are for bge1, your external interface, blocked by rule number 14.
As I've posted twice above in this thread, pfctl(8) can show you this rule. I will guess it is a general block.

Also as I've posted above, be very careful with in, out, and on. Your most recent fragment shows DNS traffic is still not permitted to transit your external interface.
Reply With Quote
Old 17th November 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,732
Default

I've been thinking further about your log output, and why I am seeing rules which match but do not block. I reviewed the pf.conf(5) man page.

I provided misleading information. My apologies. A match log is not "sticky" - it does not apply to subsequent pass and block rules.

Your rule 14 logs a block, most likely because there is a log parameter on your rule 14.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
blocking rapidshare joostvgh OpenBSD Security 39 17th January 2010 02:55 AM
PF Blocking VPN Traffic plexter OpenBSD Security 6 23rd January 2009 05:25 PM
Firewall Blocking Good Traffic plexter OpenBSD Security 6 8th January 2009 05:58 PM
pf blocking php mail ijk FreeBSD Security 7 30th October 2008 08:33 PM
PF Blocking schrodinger OpenBSD Security 6 6th October 2008 10:33 PM


All times are GMT. The time now is 04:01 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick