PF pf.conf syntax error

X

xSunLighTx3

Hey Com,

I try to install pf.conf firewall to stay save against DoS attacks.
So I used a simple code. But when I try to enable it, I got anyway
this error: "Enabling pf/etc/pf.conf:1: syntax error" ... (all lines below have the same error)

Code:

Code: 
ext_if="em0"
service_ports="{ 22 }"
game_ports="{ 11000 }"
table <trusted_hosts> const { 81.30.113.28 }
table <abusive_hosts> persist
# options
set block-policy drop
set loginterface $ext_if
set skip on lo
scrub on $ext_if reassemble tcp no-df random-id
antispoof quick for { lo0 $ext_if }
block in
pass out all keep state
pass out on $ext_if all modulate state
pass in quick from <trusted_hosts>
block in quick from <abusive_hosts>
pass in inet proto icmp all icmp-type echoreq
pass in on $ext_if proto tcp to any port $service_ports flags S/SA keep state \
        (max-src-conn 20, max-src-conn-rate 15/5, overload <abusive_hosts> flush)
pass in on $ext_if proto tcp to any port $game_ports flags S/SA keep state \
        (max-src-conn 20, max-src-conn-rate 15/5, overload <abusive_hosts> flush)

Can someone help me? I don't know why this error appears... Usually everything looks clean.
Pf service is already started. The interface name is "em0".
rc.conf has this attributes too:
pf_enable="YES"
pflog_enable="YES"
 
Hey SirDice, yes sure:

601d0bddf1.png
 
There's something wrong with the file itself. If I copy/paste the configuration it works:
Code: 
root@maelcum:~ # pfctl -nvf pf-test.conf 
ext_if = "em0"
service_ports = "{ 22 }"
game_ports = "{ 11000 }"
table <trusted_hosts> const { 81.30.113.28 }
table <abusive_hosts> persist
set block-policy drop
set loginterface em0
set skip on { lo }
scrub on em0 all no-df random-id reassemble tcp fragment reassemble
block drop in quick on ! lo0 inet6 from ::1 to any
block drop in quick on ! lo0 inet from 127.0.0.0/8 to any
block drop in quick on em0 inet6 from fe80::92e2:baff:fe53:fd2f to any
block drop in all
pass out all flags S/SA keep state
pass out on em0 all flags S/SA modulate state
pass in quick from <trusted_hosts> to any flags S/SA keep state
block drop in quick from <abusive_hosts> to any
pass in inet proto icmp all icmp-type echoreq keep state
pass in on em0 proto tcp from any to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 15/5, overload <abusive_hosts> flush, src.track 5)
pass in on em0 proto tcp from any to any port = 11000 flags S/SA keep state (source-track rule, max-src-conn 20, max-src-conn-rate 15/5, overload <abusive_hosts> flush, src.track 5)

How did you create the file? What editor did you use?
 
Mh thats strange. :eek: I created the pf.conf file manually in a ftp program (filezilla) with 777 rights.

Edit: I tried to create the file in putty with ee /etc/pf.conf and now it works.
Thanks for your help.
 
Really. You made the file world-writable? Fix the permissions while you're fixing things, it should be, at most, 644 and ideally 640.
 
I don't know why it works when I create the file with putty. It's the same as before. xD
But I think the formatting is different.
 
xSunLighTx3 said:
I don't know why it works when I create the file with putty. It's the same as before. xD
But I think the formatting is different.
Click to expand...
It's very likely either a character set oddity or Unix vs DOS text file formatting (I'd guess the latter). As a general thing, most seasoned Unix people would never consider using any non-Unix tools (e.g. FTP from a foreign platform) to edit config files, and mostly would not even use FTP between Unix systems for such a thing. Using foreign (i.e. non-Unix) tools for any system-related tasks is mostly a recipe for pain and/or disaster, unless they are specifically designed for the particular task and properly Unix-compatible. PuTTY is an example of a (mostly) safe tool, as it is designed for the specific task of cleanly connecting to a Unix shell via SSH.

When it comes to system config files and directories, there is never a justification for 666 or 777 permissions on anything. There's normally no justification for it on anything else, in the vast majority of cases; only a tiny minority of narrow and specific cases should ever have 666 or 777 permissions. It is pretty much never even a valid diagnostic technique on Unix. Mostly, they should not even be group writeable, although that's ok for certain things and where the group is something like wheel or operator, and default group permissions (i.e. which ship with the OS) should mostly be left alone unless understood. Similarly the owner and group of system stuff should not be changed (for convenience or anything else) in general.
 
I don't remember if FreeBSD does the same check but OpenBSD PF refuses to load the rules unless the /etc/pf.conf file has exactly 600 permissions, in other words read and write only for the owner of the file.
 
You must log in or register to reply here.
Back
Top