DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD Security

FreeBSD Security Securing FreeBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 28th October 2008
ijk ijk is offline
Fdisk Soldier
 
Join Date: Jun 2008
Posts: 47
Thanked 0 Times in 0 Posts
Default pf blocking php mail

pf firewall was working well till suddenly it is nolonger allow and mail to be delivered. when i disable pf everything works fine.
Below is the relevant rule. Any ideas as to why this is happening.
Code:
tcpservices = "{ domain, www, smtp, https, 10000 }"

block all

pass proto tcp from any to self port $tcpservices
thank you
__________________
Freebsd 7 64 bit apache2.2 php5 mysql5
Reply With Quote
  #2   (View Single Post)  
Old 28th October 2008
ijk ijk is offline
Fdisk Soldier
 
Join Date: Jun 2008
Posts: 47
Thanked 0 Times in 0 Posts
Default

I have temporarily fixed the issue with the rules below

Code:
# pass smtp
pass in quick on $ext_if proto tcp from any to $ext_if port 25 keep state
pass out quick on $ext_if proto tcp from any to any port 25 keep state
but could somebody tell me what is wrong with my rules in my first post.
__________________
Freebsd 7 64 bit apache2.2 php5 mysql5
Reply With Quote
  #3   (View Single Post)  
Old 28th October 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,116
Thanked 182 Times in 149 Posts
Default

DNS, or 'domain' usually uses UPD and hardly ever TCP.

For filtering TCP statefully you have to create state on the first packet of the TCP handshake. You do this with flags S/SA
Code:
pass in quick on $ext_if inet proto tcp from any to $ext_if port 25 \
                           flags S/SA keep state
On OpenBSD (flags S/SA) keep state has been the default for quite some time. Don't know whether that is also the default in FBSD 7.0.

BTW, in most cases you are better off to create separate rules for outgoing and incoming traffic. Just create TCP_OUT, TCP_IN, UDP_IN and UDP_OUT macro's for finer grained rules.
__________________
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
  #4   (View Single Post)  
Old 28th October 2008
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

There is nothing wrong with those rules. If they were all the rules in your ruleset, then smtp packets would get in. But, as phoenix said, DNS would not, as dns uses UDP, and that rule only passes TCP.

So, either:
1. You do not have another rule passing DNS, or
2. You do have a 'block quick' before that rule blocking smtp, (your workaround of adding 'quick' to this rule seems to rule this out) or
3. You do have a block rule after that rule inadvertently blocking smtp.
__________________
The only dumb question is a question not asked.
The only dumb answer is an answer not given.

Last edited by robbak; 29th October 2008 at 03:26 AM.
Reply With Quote
  #5   (View Single Post)  
Old 29th October 2008
ijk ijk is offline
Fdisk Soldier
 
Join Date: Jun 2008
Posts: 47
Thanked 0 Times in 0 Posts
Default

Quote:
There is nothing wrong with those rules.
My initial rule set below did not allow smtp
Code:
tcpservices = "{ domain, www, smtp, https, 10000 }"
block all
pass proto tcp from any to self port $tcpservices
had to add these two rules below
Code:
# pass smtp
pass in quick on $ext_if proto tcp from any to $ext_if port 25 keep state
pass out quick on $ext_if proto tcp from any to any port 25 keep state
I should not have needed to add the # pass smtp bit .

as regards allowing udp the below rules were already present in my rule set.
Code:
udpservices = "{ domain, ntp }"
pass proto udp to any port $udpservices
pass out on $ext_if proto udp from any to port $udpservices
Quote:
On OpenBSD (flags S/SA) keep state has been the default for quite some time
same in FBSD 7 . as the the verbose output even without the keep state in the ruleset flags and keep state is output.

so still puzzled as to what is wrong with the ruleset that I have to add the # pass smtp rules to get smtp working
__________________
Freebsd 7 64 bit apache2.2 php5 mysql5
Reply With Quote
  #6   (View Single Post)  
Old 29th October 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,116
Thanked 182 Times in 149 Posts
Default

If you don't show the complete ruleset it is very difficult to diagnose the problem.
There probably is some other rule that is blocking the smtp traffic. Remember: in pf the last matching rule wins.

These rules are still not correct
Code:
# pass smtp
pass in quick on $ext_if proto tcp from any to $ext_if port 25 keep state
pass out quick on $ext_if proto tcp from any to any port 25 keep state
You have two options to do it correctly:
  1. Use no keep state at all
    Code:
    pass in quick on $ext_if proto tcp from any to $ext_if port 25
    pass out quick on $ext_if proto tcp from any to any port 25
    In this case the FBSD 7.0 pf will add automatically flags S/A keep state
  2. Use flags S/A keep state yourself:
    Code:
    pass in quick on $ext_if proto tcp from any to $ext_if port 25 flags S/SA keep state
    pass out quick on $ext_if proto tcp from any to any port 25 flags S/SA keep state
Daniel Hartmeier, one of the pf architects explains it as follows in http://undeadly.org/cgi?action=artic...20060928081238
Quote:

Create TCP states on the initial SYN packet

Ideally, TCP state entries are created when the first packet of the connection, the initial SYN is seen. You can enforce this by following a simple principle:
Use 'flags S/SA' on all 'pass proto tcp keep state' rules!
All initial SYN packets (and only those packets) have flag SYN set but flag ACK not set. When all your 'keep state' rules that can apply to TCP packets are restricted these packet, only initial SYN packets can create states. Therefore, any TCP state created is created based on an initial SYN packet.

The reason for creating state only on initial SYN packets is a TCP extention called 'window scaling' defined in RFC 1323. The field of the TCP header used to advertise accepted windows became too small for today's fast links. Modern TCP/IP stacks would like to use larger window values than can be stored in the existing header field. Window scaling means that all window values advertised by one peer are to be multiplied by a certain factor by the receipient, instead of be taken literally. In order for this scheme to work, both peers must understand the extention and advertise their ability to support it during the handshake using TCP options. The TCP options are only present in the initial SYN and SYN+ACK packets of the handshake. If and only if both of those packets contain the TCP option, the negotiation is successful, and all further packets' window values are meant to be multiplied.

If pf didn't know about window scaling being used, it would take all advertised window values seen literally, and calculate its windows of acceptable sequence number ranges incorrectly. Typically, peers start to advertise smaller windows and gradually advertise larger windows during the course of a connection. Unaware of the window scaling factors, pf would at some point start to block packets because it would think one peer is overflowing the other's advertised window. The effects would be more or less subtle. Sometimes, the peers will react to the loss of the packets by going into a loss recovery mode and advertise smaller windows. When pf then passes subsequent retransmissions again, advertised windows grow again, up to the point where pf blocks packets. The effect is that connections temporarily stall and throughput is poor. It's also possible that connections stall completely and time out.

pf does know about window scaling and supports it. However, the prerequisite is that you create state on the initial SYN, so pf can associate the first two packets of the handshake with the state entry. Since the entire negotiation of the window scaling factors takes place only in these two packets, there is no reliable way to deduce the factors after the handshake.

Window scaling wasn't widely used in the past, but this is changing rapidly. Just recently, Linux started using window scaling by default. If you experience stalling connections, especially when problems are limited to certain combinations of hosts, and you see 'BAD state' messages related to these connections logged, verify that you're really creating states on the initial packet of a connection.
__________________
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
  #7   (View Single Post)  
Old 30th October 2008
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

[QUOTE=ijk;16943]My initial rule set below did not allow smtp
Code:
tcpservices = "{ domain, www, smtp, https, 10000 }"
block all
pass proto tcp from any to self port $tcpservices
That rule is correct. That rule will pass smtp.

Some other rule is blocking smtp. Or you may be having problems with dns, which that rule is _not_ passing.

Your problem with smtp is not in those rules. it is in other rules, elsewhere in your pf.conf

(Alternatley, maybe you are having a problem with the 'self' keyword. If you are using dhcp, maybe the address has changed since you loaded the ruleset. If you have dynamic ip addresses, it is best to use keywords like that in brackets (eg "( self )" ). Then the address will be updated if the interface addresses change.)
__________________
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 30th October 2008
ijk ijk is offline
Fdisk Soldier
 
Join Date: Jun 2008
Posts: 47
Thanked 0 Times in 0 Posts
Default

I have added more rules here and trying to avoid putting my entire rule set on display.
All my block rules are however listed.

Code:
norouteips = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24,  240.0.0.0/4 }"
tcpservices = "{ domain, www, smtp, https, 10000 }"
table <bruteforce> persist file "/pathto/bruteforceblock"
block all
block quick from <bruteforce>
set skip on tx0
antispoof quick for { tx0 $ext_if }
# block non routable ips
block in  quick on $ext_if from $norouteips to any
block out quick on $ext_if from any to $norouteips
# block exploited servers http://www.wizcrafts.net/exploited-servers-iptables-blocklist.txt
block in quick from <exploitedservers>

pass proto tcp from any to self port $tcpservices
pass inet proto tcp from any to port $tcpservices keep state  (max-src-conn 100, max-src-conn-rate 30/5, overload <bruteforce> flush global)

I was wondering if the below ruleset could be causing the problem
Code:
pass inet proto tcp from any to port $tcpservices keep state  (max-src-conn 100, max-src-conn-rate 30/5, overload <bruteforce> flush global)
I deleted my <bruteforce> table with a long list of ipaddress thinking I must have blocked myself but it did not work.

however mysteriously everything seems to be back to normal now even without using those smtp rules
__________________
Freebsd 7 64 bit apache2.2 php5 mysql5

Last edited by ijk; 31st October 2008 at 09:45 AM.
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 MySpace roddierod Other OS 3 12th April 2009 09:39 PM
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 schrodinger OpenBSD Security 6 6th October 2008 10:33 PM
Blocking remote desktop apps bichumo General software and network 3 30th September 2008 08:14 PM


All times are GMT. The time now is 12:08 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