DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 8th July 2009
birdmansdomain birdmansdomain is offline
Port Guard
 
Join Date: Jun 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default Ok, i've tried but failed. Damn

So i've been working for past couple hours to get pf to forward to webserver on internal net,but no luck. I can nmap and get an open port from remote location but if i try to enter ip it just sits there for quite a while. I've read the debugging guide and still having trouble. I run tcpdump on both ext and int and they both show the packets on both passing though, so i guess the pf in is working but no out maybe??? Anyways heres my pf.conf any help would be great as there might be a whole pile hair under my chair by the time i figure this out.

ext_if="em0"
int_if="re0"
wifi_if="ral0"
local_net="{192.168.0.1/24, 192.168.1.1/24}"
server="{ 192.168.0.10 }"
icmp_types="echoreq"
tcp_flags="flags S/SA keep state"
table <abusers> persist

set require-order no
set skip on lo
scrub in all

nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80

block drop all
block in quick from <abusers>

pass out on $ext_if proto tcp all flags S/SA keep state
pass out on $ext_if proto { udp,icmp } all keep state

pass in quick inet proto icmp all icmp-type $icmp_types keep state
pass in quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA synpro$
pass in quick on $wifi_if proto tcp to ($wifi_if) port ssh $tcp_flags (max-src-conn 8, m$
pass quick on { lo, $int_if, $wifi_if }

antispoof quick for { lo, $int_if, $ext_if, $wifi_if }
Reply With Quote
  #2   (View Single Post)  
Old 8th July 2009
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Thanked 40 Times in 39 Posts
Default

firstly, log all your drops, and check the logs to see if you are dropping the packets.

I'm not sure if "rdr pass' is valid - it probably is, mind you, it's just that I don't know - but the pass will be immediately overridden by the following 'block drop all'. It just depends on whether the pass in quick ...to $server... line is right. You haven't put a 'keep state' line there, but I think pf assumes keep state now.

Anyway, if those mutterings don't help you, add 'log' to your block lines, check the log (there's an example of how to check them in the 'pflog' man page), and post back with your findings.
__________________
The only dumb question is a question not asked.
The only dumb answer is an answer not given.
Reply With Quote
  #3   (View Single Post)  
Old 8th July 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,710
Thanked 214 Times in 189 Posts
Default

Your pf.conf was damaged when you copied and pasted. Note your "synproxy" got cut, as well as what appears to possibly have been a "modulate state". Next time, copy and paste plain text between [ code ] [ /code ] tags.

I'll guess, for two solutions:

1) You have no pass out for your internal network(s). Remember, PF doesn't know which of your interfaces connect to the Internet. It just knows interfaces, and the direction of traffic. The "rdr pass" only passes the incoming packets, you still need a pass rule for the outgoing packets on your local LANs.

2) If you have not already confirmed it, make sure you have enabled IPv4 packet forwarding in /etc/sysctl.conf.

Robbak is right: put "log" on every blocking filter rule, and use tcpdump.. You might also consider logging all pass rules, too. To watch for blocked traffic, use something like:
# tcpdump -neti pflog0 action block
Reply With Quote
  #4   (View Single Post)  
Old 8th July 2009
birdmansdomain birdmansdomain is offline
Port Guard
 
Join Date: Jun 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

Ok, "tcpdump -neti pflog0 action pass" shows my connection from remote location, but nothing under block. Which is good?? I have no other problems passing out data with my current config.


Code:
 
ext_if="em0"
int_if="re0"
wifi_if="ral0"
server="{ 192.168.0.10 }"
icmp_types="echoreq"
tcp_flags="flags S/SA keep state"
table <abusers> persist

set require-order no
set skip on lo
scrub in all

nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80

block drop all
block in quick from <abusers>

pass out on $ext_if proto tcp flags S/SA keep state
pass out on $ext_if proto { udp,icmp } keep state

pass in quick inet proto icmp all icmp-type $icmp_types keep state
pass in quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA synproxy state
pass in quick on $wifi_if proto tcp to ($wifi_if) port ssh $tcp_flags (max-src-conn 8, max-src-conn-rate 15/5, overload <abusers> flush global)

pass quick on { lo, $int_if, $wifi_if }

antispoof quick for { lo, $int_if, $ext_if, $wifi_if }
Reply With Quote
  #5   (View Single Post)  
Old 8th July 2009
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Thanked 40 Times in 39 Posts
Default

You haven't set logging on any rules yet, so you won't see anything on pflog.
At the least, set logging on the block rules like this:
Code:
block drop log all
block in log quick from <abusers>
The log statement goes directly after the direction keyword (in or out) or after the action keyword (block, pass, rdr etc) if you aren't stating a direction. Then you will find out what is happening to your packets.
Unless you are handling gigabytes per second through your firewall, you should always log blocked packets
__________________
The only dumb question is a question not asked.
The only dumb answer is an answer not given.
Reply With Quote
  #6   (View Single Post)  
Old 8th July 2009
birdmansdomain birdmansdomain is offline
Port Guard
 
Join Date: Jun 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

i just reposted the pf.conf that got cut earlier my pf.conf is logged. the www traffic isn't being blocked. I tcpdump -neti pflog0 action rdr and i can see the traffic
Reply With Quote
  #7   (View Single Post)  
Old 9th July 2009
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Thanked 40 Times in 39 Posts
Default

OK, you can see it hitting the rdr rule, but that 'action rdr" will stop you seeing if the traffic is hitting the block rules.

If that is your pf.conf posted above then you have no log statements anywhere. As far as i am aware, tcpdum pflog should show nothing.
__________________
The only dumb question is a question not asked.
The only dumb answer is an answer not given.
Reply With Quote
  #8   (View Single Post)  
Old 9th July 2009
birdmansdomain birdmansdomain is offline
Port Guard
 
Join Date: Jun 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

well i don't have the time, patience, or hair to be trying to figure this out, i was hoping for more help, but got none. I have a new cable connection being installed next week and imma just run web server from that connection, that way i dont have to waste my time. BTW like i said i didnt post my updated pf.conf thats shows i have log put in every rule.
Reply With Quote
  #9   (View Single Post)  
Old 9th July 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,710
Thanked 214 Times in 189 Posts
Default

Quote:
i was hoping for more help, but got none.
See d2 in http://www.daemonforums.org/showthread.php?t=596 -- you may find d1, e1, and e2 informative, as well.

Allow me to refer to you to the misc@ mailing list. The OpenBSD community here is relatively tiny in comparison.

Last edited by jggimi; 9th July 2009 at 03:50 AM.
Reply With Quote
Old 9th July 2009
birdmansdomain birdmansdomain is offline
Port Guard
 
Join Date: Jun 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

i'm not here to become an expert and i know you dont have to help me. I've tried the best to my ability to resolve this issue, which i cant. I've read many online texts and have read the PF man many times. I figure seeing as how many of you are sitting on the answer to my issue, i didn't realize that anyone had a issue with helping someone with less knowledge. Like i said i'm not trying to become an expert, i have better things to do with my time, i just wanted a lil more help than these cryptic answers. I really thought this forum was better than this elitist attitude i got.
Reply With Quote
Old 9th July 2009
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,154
Thanked 182 Times in 149 Posts
Default

I don't understand why you are too lazy to post your updated pf.conf. I you want people to help you, you should help those people

The following two rules are enough to redirect ssh traffic.
Code:
EXT_IF = bge0

set skip on lo0

rdr on $EXT_IF inet proto tcp  from any to any  port 55555 tag SSH -> 192.168.222.11 port 22

# default policy
block log all

pass in quick on $EXT_IF tagged SSH
When testing redirection there are two issues most people run into:
  • Testing from the internal LAN

    As explained in http://www.openbsd.dk/faq/pf/rdr.html#reflect accessing the external IP from the internal LAN does not cause redirection to work.
    You, or a friend, really needs to test from the Internet side.
  • Routing

    The default gateway of the box receiving the redirected traffic should be correct.

    If you redirect traffic to the internal LAN, the internal NIC of the firewall should be set as the default gateway.
    In case you use a DMZ the DMZ NIC of the firewall is the default gateway.

    If you forget this, like I did a couple of times, tcpdump will not show any blocked packets. Running tcpdump on the server NIC will even show the packets coming in.The server just doesn't know how to route the it's answer packets.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Old 9th July 2009
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

I don't understand why so many people who are new to OpenBSD/pf create(..copy&paste) unimaginably complex rulesets without first confirming they work in their specific setup.

You should always start simple, which will be beneficial.. especially if you're just learning.

Please don't insult people birdman, if you're just going to criticize support from volunteers.. there are other less social ways to learn about pf, I managed to create my first ruleset by reading the man pages, the pf FAQ.. and Peter's tutorial.
Reply With Quote
Old 9th July 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,710
Thanked 214 Times in 189 Posts
Default

Quote:
Originally Posted by birdmansdomain View Post
I figure seeing as how many of you are sitting on the answer to my issue...
That expectation is incorrect, in two different ways:
  1. No one is holding back knowledge from you. There is no single answer to a particular PF configuration problem, ever. And the information you posted has been limited, and misleading. The latter may have been unintentional, but your repost of a configuration that could not possibly be used with tcpdump, along with a summary of tcpdump results was confusing. It confused robbak, and it confused me. I assume it was confusing to others reading the thread as well.
  2. There aren't *many* OpenBSD users here. The number of OpenBSD users who regularly answer OpenBSD-related questions on this forum number around a dozen people. And none of them camp on the forum 7x24 waiting for problem reports to appear, so I would bet that only a handful of the regulars have even seen your thread. (That's not to say that FreeBSD users who are also PF users couldn't provide assistance, with the understanding that the PF implementations of the two OSes are actually quite different.) This is one of the reasons I recommended misc@ -- your post would be seen by thousands of users, with perhaps hundreds who could assist you, rather than the tiny community here.
Quote:
... i didn't realize that anyone had a issue with helping someone with less knowledge... I really thought this forum was better than this elitist attitude i got...
None of us mind helping others; that's why we're here. Unfortunately, you are misinterpreting confusion over your problem description, our attempts to uncover more about the problem, and our suggestions for additional problem source identification, in order to assist you, as "elitist attitude." You misunderstand, and your expectations of our abilities are also unrealistic.

A post by Nick Holland on misc@ just a couple of hours ago, to another user who also had unmet expectations, is apropos. Nick said to him:
Quote:
Don't waste people's time. As the asker of the question, expect to spend AT LEAST as much time (and more likely, many times as much time) investigating and describing your problem as you expect others to spend helping you for free.

Last edited by jggimi; 9th July 2009 at 12:39 PM.
Reply With Quote
Old 9th July 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,710
Thanked 214 Times in 189 Posts
Default

And, while you may have given up, a user on misc@ just reported that his redirection problem was due to using synproxy. Yours might be, also.

His post:
http://marc.info/?l=openbsd-misc&m=124715215831478&w=2

Thread start:
http://marc.info/?l=openbsd-misc&m=124700148528406&w=2

That resolution makes some sense, because http://openbsd.rt.fm/faq/pf/rdr.html says:
Quote:
...However, if you want to enable more specific filtering options such as synproxy, modulate state, etc. you'll still have to use a dedicate pass rule as these options don't fit into redirection rules.
Reply With Quote
Old 9th July 2009
birdmansdomain birdmansdomain is offline
Port Guard
 
Join Date: Jun 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

Quote:
Testing from the internal LAN

As explained in http://www.openbsd.dk/faq/pf/rdr.html#reflect accessing the external IP from the internal LAN does not cause redirection to work.
You, or a friend, really needs to test from the Internet side.
I have been testing externally the whole time

Quote:
Routing

The default gateway of the box receiving the redirected traffic should be correct.

If you redirect traffic to the internal LAN, the internal NIC of the firewall should be set as the default gateway.
In case you use a DMZ the DMZ NIC of the firewall is the default gateway.

If you forget this, like I did a couple of times, tcpdump will not show any blocked packets. Running tcpdump on the server NIC will even show the packets coming in.The server just doesn't know how to route the it's answer packets.
I have 2 internal nics, 1 wireless other wired on initial setup if my gateway was setup for the wired nic IP the wireless would not access internet but wired would. I changed gateway to other nic's IP and both were able to access internet. That problem was solved. Should i set my gateway to the IP of external nic???? not sure of the implications of doing so, so i haven't.


Quote:
I don't understand why so many people who are new to OpenBSD/pf create(..copy&paste) unimaginably complex rulesets without first confirming they work in their specific setup.

You should always start simple, which will be beneficial.. especially if you're just learning.
I didnt think this was that complex considering the scope of PF's abilities. BTW i didnt copy and paste either so thank you for the assumption. This pf.conf has been working for me for quite a while and the only thing that was added was the
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80
pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA

the original pf.conf i created was from reading the pf man pages.

Isn't "pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA" a dedicated pass rule????

Also i apologise for my attitude this has made me really pissy past day. Anyways heres my pf.conf WITH log put in there for some of you.

Quote:
ext_if="em0"
int_if="re0"
wifi_if="ral0"
server="{ 192.168.0.10 }"
icmp_types="echoreq"
tcp_flags="flags S/SA keep state"
table <abusers> persist file "/etc/ssh-violate"

set require-order no
set skip on lo
scrub in all

nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80

block drop log all
block in log quick from <abusers>

pass out log on $ext_if proto tcp from any to any flags S/SA
pass out log on $ext_if proto { udp,icmp } from any to any

pass in log quick inet proto icmp all icmp-type $icmp_types
pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA
pass in log quick on $wifi_if proto tcp to ($wifi_if) port ssh $tcp_flags (max-src-conn 8, max-src-conn-rate 15/5, overload <abusers> flush global)

pass quick on { lo, $int_if, $wifi_if }

antispoof quick for { lo, $int_if, $ext_if, $wifi_if }
Quote:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33204
priority: 0
groups: lo
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5


re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:18:e7:18:3d:34
priority: 0
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::218:e7ff:fe18:3d34%re0 prefixlen 64 scopeid 0x1


em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:60:47:d3:9c
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet6 fe80::20d:60ff:fe47:d39c%em0 prefixlen 64 scopeid 0x2
inet *.*.*.* netmask 0xfffffc00 broadcast 255.255.255.255


ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:1d:6a:3a:48:66
priority: 0
groups: wlan
media: IEEE802.11 autoselect hostap
status: active
ieee80211: nwid Phreaks chan 2 bssid 00:1d:6a:3a:48:66
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::21d:6aff:fe3a:4866%ral0 prefixlen 64 scopeid 0x3


pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33204
priority: 0
groups: pflog
Reply With Quote
Old 9th July 2009
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,888
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by birdmansdomain View Post
Ummm how come it wouldnt post my post?????????
You mention that it was a large message which probably means that you had spent some amount of time to construct it. vBulletin (the forum software used here...), will drop connections which lie dormant for some amount of time. I don't know what is the exact amount of time which times out connections, but you can save your work going back one page (typically with the Back button...), followed by cutting & pasting into yet another new message.
Reply With Quote
Old 9th July 2009
birdmansdomain birdmansdomain is offline
Port Guard
 
Join Date: Jun 2009
Posts: 13
Thanked 0 Times in 0 Posts
Default

yeh tried again and apparently all my posts have to be monitored by an admin now. Though it seems quick reply works.
Reply With Quote
Old 10th July 2009
Carpetsmoker's Avatar
Carpetsmoker Carpetsmoker is offline
Real Name: Martin
Old man from scene 24
 
Join Date: Apr 2008
Location: Eindhoven, Netherlands
Posts: 2,074
Thanked 198 Times in 156 Posts
Default

Problem was the spam filter -- False positive.
The first ten posts of new users are scanned for spam.

It seems to dislike message with significant code/config files/shell examples and markes those as spam ...

In any case, your post is displayed now.
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Reply With Quote
Old 10th July 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,710
Thanked 214 Times in 189 Posts
Default

I believe you have two problems. #1:
Quote:
pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA
I don't believe this rule will ever match a packet. The incoming traffic is destined for the IP address of your OpenBSD router on em0; there will normally never be an incoming packet from em0 (the Internet) destined for 192.168.0.10, that is an RFC 1918 address.

#2:
Quote:
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80
This should cause a redirect of TCP and UDP traffic on em0, with a destination port 80, towards 192.168.0.10, as you intended. That traffic is passed IN, as you intend, due to the "pass" in the rdr rule. (If I recall correctly, UDP is not used with http protocol, so any UDP traffic will be ignored by the web server. You should be able to safely remove UDP from your rdr rule.)

However, the redirected traffic needs its own pass rule. That's because you are running NAT, which changes the destination address from your IP address on the Internet to 192.168.0.10. I would add a rule something like:
Quote:
pass out log on $int_if from any to $server port 80
As I stated initially, PF doesn't know which of your interfaces is internal or external, and "in" and "out" are directions in and out of your NICs. This outbound pass rule goes *out* of your OpenBSD router, but towards your internal LAN.
Reply With Quote
Old 10th July 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,710
Thanked 214 Times in 189 Posts
Default

On second thought, and another review of your pf.conf .... #2 may not be necessary, as you have
Quote:
pass quick on { lo, $int_if, $wifi_if }
I'm not sure why "lo" works for you without error, your loopback virtual NIC is "lo0". And the set skip rule, if it works, means that the loopback interface need not be included in this pass rule.

If your problem isn't isolated and resolved by someone else today, I will recreate your environment and test your specific pf.conf tonite (US EDT).
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
back-sql - SQLConnect() failed vol_o3 OpenBSD General 0 9th September 2009 09:36 AM
pfstat fopen failed: ? Calderon FreeBSD General 3 7th May 2009 08:52 AM
phpPgAdmin login failed gosha General software and network 14 17th March 2009 11:49 PM
Communication with su failed amandus OpenBSD Packages and Ports 7 17th July 2008 07:17 AM
Failed Installs dctr OpenBSD Installation and Upgrading 23 4th June 2008 04:25 AM


All times are GMT. The time now is 11:27 PM.


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