DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 11th March 2009
bsdnewbie999 bsdnewbie999 is offline
Package Pilot
 
Join Date: May 2008
Posts: 145
Default pflog not logging.

Why my pflog does not log? I have done the pf configuration and logging as told in the openbsd FAQ page. But why nothing is logged in pflog file ?
Reply With Quote
  #2   (View Single Post)  
Old 11th March 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Every rule you want to log must explicitly have the "log" option.

Only the final matching rule, with "log" explicitly declared, will cause a log entry.

Still confused? Post your pf.conf file.
Reply With Quote
  #3   (View Single Post)  
Old 12th March 2009
bsdnewbie999 bsdnewbie999 is offline
Package Pilot
 
Join Date: May 2008
Posts: 145
Default

Here is it.

Code:
# Macros
int_if="vic0"

#scrub
scrub in all

# Filtering rules
pass in on $int_if proto tcp from any to $int_if port www
pass out on $int_if proto tcp from $int_if to any port www
block in log quick on $int_if proto tcp from any to any port ssh flags S/SA

 
#Antispoof
antispoof log for $int_if inet

#Unicast reverse path forwarding
block in log quick from urpf-failed label uRPF

#Passive operating system fingerprinting
pass in log on $int_if from any os OpenBSD keep state
block in log on $int_if from any os "Windows 2000"
block in log on $int_if from any os "Windows XP"
block in log on $int_if from any os "Windows XP SP1"
block in log on $int_if from any os "Windows XP SP2"
block in log on $int_if from any os "Windows xP SP3"
block in log on $int_if from any os "Windows 98"
block in log on $int_if from any os "Windows NT"
block in log on $int_if from any os "Linux 2.4 ts"
block in log on $int_if from any os unknown

# return
block return

#Block ICMP redirect packets
block in log quick on $int_if inet proto icmp from any to $int_if 
block in log quick on $int_if inet proto icmp from any to $int_if icmp-type redir

#Block SMTP(simple mail transfer protocol)
block in log quick on $int_if inet proto tcp from any to $int_if port smtp

#pass out UDP and ICMP
pass out on $int_if inet proto udp all keep state
pass out on $int_if inet proto icmp from $int_if to any keep state

#Block everything
block return-rst in log quick on $int_if inet proto tcp from any to $int_if 
block return-icmp in log quick on $int_if inet proto udp from any to $int_if
block in quick on $int_if all

Last edited by bsdnewbie999; 12th March 2009 at 07:44 AM.
Reply With Quote
  #4   (View Single Post)  
Old 12th March 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Packets are tested with the rules top down. At each test, PF determines if the rule matches or not.
  1. If a "quick" rule matches, PF stops analysis and applies the rule, block or pass.
  2. If the rule is not "quick", PF notes if the rule matches, and continues analysis of the next rule.
  3. The last matching rule, block or pass, is applied to the packet.
The first "quick" rule that matches is applied, and PF processing stops. Here are your "quick" rules, in order:
  • You block all incoming traffic to port 22 (ssh)
  • You block incoming traffic from "urpf-failed"
  • You block all incoming ICMP traffic ...
  • You block all ICMP redirects. This rule will never match, because of the preceding "quick" rule.
  • You block all incoming traffic to port 25 (smtp)
  • You block all incoming TCP traffic.
  • You block all incoming UDP traffic.
  • You block all incoming traffic. This rule is not logged.
The end result is that all incoming traffic is blocked. Unless one of the prior quick rules matches, the blocked incoming traffic is not logged by pflog(4).
Not one of your normal (non-"quick") rules for incoming traffic will ever be used, as every incoming packet will match a "quick" rule.

For outgoing traffic, the rules are normal. The last matching rule applies.
  • You pass outbound traffic to port 80 (www)
  • You pass all UDP traffic
  • You pass all ICMP traffic
None of your outbound traffic is logged.
Reply With Quote
  #5   (View Single Post)  
Old 12th March 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

As an addendum, as I noted in http://daemonforums.org/showthread.php?t=2953#post21893 in the midst of your rules you have an unexplained "block return" which will match all packets, inbound or outbound, without logging. If no following rules match, this rule will be applied.
Reply With Quote
  #6   (View Single Post)  
Old 13th March 2009
bsdnewbie999 bsdnewbie999 is offline
Package Pilot
 
Join Date: May 2008
Posts: 145
Default

Can you give me any suggestions for my pf to start logging?

Thanks.
Reply With Quote
  #7   (View Single Post)  
Old 13th March 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Your current rule set is not in any clear logical order, and some rules appear to have been found elsewhere and added, without an understanding of what the rule does. Some examples:
  1. You have "quick" rules at the end of your ruleset.
  2. You have rules that will never match.
  3. You have an unreferenced label.
  4. You have a broad rule in the middle of the set that negates all normal filter rules above it.
Based on this, I assume that:
  • You do not understand how PF works.
  • You do not understand PF filter rules.
  • You have found some examples on the Internet, and have plugged them into your rule set, hoping they will somehow magically add value.
Of course, these are assumptions based on the pf.conf you've posted. If my assumptions are correct, these are my recommendations:
  1. Do NOT paste random PF rules you find on the Internet into your rule set.
  2. Do NOT use PF until you determine what you want to accomplish with it. Your current ruleset is for a terminating workstation running OpenBSD, with a single NIC. If that is correct -- I do not know if it is -- then you do not necessarily require PF at all.
To properly deploy an effective PF configuration, you must:
  1. Understand what kind of traffic you want to allow.
  2. Understand what kind of traffic you want to deny.
  3. Determine if you need a "default allow" or "default deny" configuration. PF can do either.
  4. Set up rules that control traffic as desired
  5. Test the rules to ensure they behave as intended. This is one of the values of PF logging.
In order to understand the kind of traffic you want to allow or deny, you must have knowledge of the communication protocols involved, in order to configure effective rules.

In order to understand how to use PF, you must read and understand the PF User's Guide. It is available in English, German, French, Italian, Dutch, Polish, and Portuguese.
Reply With Quote
  #8   (View Single Post)  
Old 13th March 2009
bsdnewbie999 bsdnewbie999 is offline
Package Pilot
 
Join Date: May 2008
Posts: 145
Default

Yes. You're right. I don't quite understand how pf works and the logical order of the rule sets. I printed the pf FAQ page but it didn't specify how to arrange the rules in correct order. I tried to google some resources from the Internet but really hard to find one.

My purpose of the pf firewall is to secure my PC from some sort of attack.
Reply With Quote
  #9   (View Single Post)  
Old 13th March 2009
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

Take a look at these two educational references for PF that ocicat mentioned in another thread earlier today:

http://www.daemonforums.org/showthre...2956#post21913

These may be helpful.
Quote:
My purpose of the pf firewall is to secure my PC from some sort of attack.
As you already know, the default installation is considered secure. But nobody runs the default install. Even if we don't add any 3rd-party packages, we make configuration changes, add users ... enable services ... and do other administrative tasks that may introduce weaknesses or attack vectors.

Knowledge of our networking applications is key.

For instance, let us pretend that you have decided to start ftpd(8), and run an ftp server. It is not enabled in the default install. So you enable it, either in inetd.conf(5) or in rc.conf.local(5).

Some of the most obvious attack vectors to consider:
  • Anonymous FTP misconfiguration
  • Allowing password authentication, and the implications for packet sniffing
  • Poor passwords
  • Common userids
  • Brute force password attacks
  • Authenticated users and improper access
  • ...
There are plenty of things to consider, and plenty of ways to make mistakes without even realizing it.

Will PF help? Perhaps. I might use PF to limit FTP client access from a particular set of IP addresses or network blocks, or, I might use state table management to set limits on anonymous FTP connections.

FTP is a good example. To use PF to allow (or deny) FTP, the admin needs to know the protocol it uses, and the ports. If you elect to offer an FTP service ... do you know it uses different ports depending on whether "Active FTP" or "Passive FTP" is used? Do you know it uses a range of high port numbers for data channels? And, that the initiator of the data backchannel may be the client, or the server, depending on Active/Passive FTP?

On to your next network application....
Reply With Quote
Old 13th March 2009
ai-danno's Avatar
ai-danno ai-danno is offline
Spam Deminer
 
Join Date: May 2008
Location: Boca Raton, Florida
Posts: 284
Default

jggimi really hit the nail on the head. It's going to take a well-thought plan and understanding of your needs and vulnerabilities, as well as a better understanding of pf and OpenBSD, before you can start to appreciate the security it can provide.

I would personally start small. Instead of putting in a bunch of rules you may not fully understand, start by learning how to do one thing. For instance, figure out how to block ssh (port 22) but allow everything else. As you learn things, figure out ways to test your changes to see if they are actually working as expected. Do your homework and ask questions here... it's not like we're holding back
__________________
Network Firefighter
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
sshd logging - can we get the ssh command? Mantazz FreeBSD Security 17 23rd May 2009 08:34 AM
Suggestions for Web Traffic Logging? Bruco FreeBSD Ports and Packages 16 18th September 2008 10:54 PM
Network + aMule Logging Problems disappearedng FreeBSD General 0 28th August 2008 09:22 PM
Why PFLOG can't LOG anything????? chamnanpol FreeBSD General 1 18th June 2008 07:09 PM
spamd logging question roundkat OpenBSD General 10 11th June 2008 01:27 PM


All times are GMT. The time now is 09:23 AM.


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