thttpd and pf

M

mc_hammer

after installing from ports on FreeBSD 8.0 thttpd web server.
I have put such a rule to pf.conf

Code: 
pass in on bwi0 from any to (bwi0) port 80 user www

I see in top display that thttpd is run by user www
but pf is blocking incoming tcp connections.

If change user in pf.conf rule to root:
pass in on bwi0 from any to (bwi0) port 80 user root

pf is passing incoming connections.

Why it is so?

mc_hammer
 
pf.conf rules sgould be:
Code: 
pass in on bwi0 proto tcp from any to (bwi0) port 80 user www
and
Code: 
pass in on bwi0 proto tcp from any to (bwi0) port 80 user root

thttpd version 2.25b_3
 
I see that thttpd use user www and real user www
why pf is blocking incoming connections?

rule:
Code: 
pass in on bwi0 proto tcp from any to (bwi0) port 80 user www
 
You might want to add:
Code: 
keep-state flags S/SA

At the end. I'm not sure if the FreeBSD version of pf does that by default to every rule (Recent OpenBSD version do, but FreeBSD version lags behind rather a lot).

OpenBSD PF FAQ has an excellent explanation what this does. Probably a much better/comprehensive explanation I can offer you at this hour ;)

I'm not sure if this should be before or after "user www" ... To be honest I never used that option ... I didn't even know it existed ...
Which makes me wonder ... *does* this option actually exist? for that matter, did you actually reload your pf.conf with pfctl?

You can also learn a lot with tcpdump(1) and pflogd(8). Actually, this is the #1 firewall debugging tool. Add "log" keywords to your rules, start pflogd, and use tcpdump to see what is and isn't blocked and why.
 
Carpetsmoker said:
You might want to add:
Code: 
keep-state flags S/SA

At the end. I'm not sure if the FreeBSD version of pf does that by default to every rule
Click to expand...

It does.
 
Carpetsmoker said:
I'm not sure if this should be before or after "user www" ... To be honest I never used that option ... I didn't even know it existed ...
Which makes me wonder ... *does* this option actually exist?
Click to expand...

And again: it does ;)

Using it for rtorrent myself:

Code: 
pass  out quick inet proto tcp all user rtorrent modulate state queue( torrent, toracks )
pass  in quick inet proto tcp all user rtorrent synproxy state (max-src-conn 10, max-src-conn-rate 10/5, overload <bruteforce> flush global) queue( torrent, toracks )
 
Thanks for help, I still don't understand, why this rule is not working:
pass in on bwi0 proto tcp from any to (bwi0) port 80 user www

is it a bug in FreeBSD firewall?
 
I don't know if it's a bug, but you usually use either the user or the port. By using 'user www' you're really saying 'all processes and ports owned by the www user' already. By specifying the port as well as the user you may introduce some weird and undocumented AND/OR situation that does neither.
 
Code: 
pass  out proto { tcp, udp } all user { < 1000, dhartmei }

Let me explain this grammatic question in ungrammatic way:

We see from pf.conf GRAMMAR section that word "all"
is variation of one syntax element called hosts.

Code: 
hosts = "all" |
"from" ( "any" | "no-route" | "urpf-failed" | "self" | host |
"{" host-list "}" | "route" string ) [ port ] [ os ]
"to"   ( "any" | "no-route" | "self" | host |
"{" host-list "}" | "route" string ) [ port ]

This "hosts" element should work as any of above.
 
DutchDaemon said:
I don't know if it's a bug, but you usually use either the user or the port. By using 'user www' you're really saying 'all processes and ports owned by the www user' already. By specifying the port as well as the user you may introduce some weird and undocumented AND/OR situation that does neither.
Click to expand...

I normally use both. I always figured that by using both the user and the port, it prevents things like the following from happening:

The www user is somehow compromised. Then, because you didn't specific the port in the firewall, the compromised www user can run a program to listen on another port accessible by the www user and send/receive data used to exploit the system in another such way.

If the firewall was set to allow traffic for the www user ONLY on port 80, for example, it can help prevent scenarios like the above from happening.
 
To be honest, FreeBSD 8.0 32 installation is working on wmware server installed on windows server 2008 64,
could it be explanation of pf malefunction?
 
Well, for starters I don't think it's a bug on the FreeBSD side, but rather a bug in the configuration.

To repeat myself:
You can also learn a lot with tcpdump(1) and pflogd(8). Actually, this is the #1 firewall debugging tool. Add "log" keywords to your rules, start pflogd, and use tcpdump to see what is and isn't blocked and why.
Click to expand...

You also haven't posted the full pf.conf or described your network situation, maybe something else is causing the problems.
 
I changed pf.conf during tcpdump capture (1.), there was no output from tcpdump during (2.), also client xxx could not connect to server yyy.
(3.) xxx client could connect but tcpdump output is garbage.

xxx client
yyy server

1.
Code: 
tcpdump -i pflog0 -A > /mnt/pflog.txt

2.
Code: 
pfctl -sr

block drop log quick inet6 all
block return in log on le0 all
pass in log on le0 proto tcp from any to (le0) port = http user = 80 flags S/SA keep state

3.
Code: 
pfctl -sr

block drop log quick inet6 all
block return in log on le0 all
pass in log on le0 proto tcp from any to (le0) port = http flags S/SA keep state


pflog.txt
Code: 
15:55:38.858135 IP xxx.xxx.xxx.xxx.4501 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0............
..6...P1.,.....
15:55:39.342702 IP xxx.xxx.xxx.xxx.4501 > yyy.yyy.yyy.yyy.http:  tcp 28 [bad hdr length 0 - too short, < 20]
E..0............
..6...P1.,.....
15:55:39.826130 IP dns.dns.dns.dns.domain > yyy.yyy.yyy.yyy.59196: [|domain]
E...=...<.......
..6.5.<...:.y..
15:55:39.845881 IP xxx.xxx.xxx.xxx.4501 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0............
..6...P1.,.....
15:55:44.934847 IP dns.dns.dns.dns.domain > yyy.yyy.yyy.yyy.59196: [|domain]
E...=...<.......
..6.5.<...?.y..
15:55:47.860749 IP xxx.xxx.xxx.xxx.4521 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0............
..6...P`i.U....
15:55:48.298687 IP xxx.xxx.xxx.xxx.4521 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0............
..6...P`i.U....
15:55:48.797852 IP xxx.xxx.xxx.xxx.4521 > yyy.yyy.yyy.yyy.http:  tcp 28 [bad hdr length 0 - too short, < 20]
E..0............
..6...P`i.U....
15:55:56.244322 IP dns.dns.dns.dns.domain > yyy.yyy.yyy.yyy.24287: [|domain]
E..0=...<..%....
..6.5^...6..z..
15:56:01.305292 IP dns.dns.dns.dns.domain > yyy.yyy.yyy.yyy.24287: [|domain]
E..0=...<..$....
..6.5^......z..
15:57:39.592106 IP xxx.xxx.xxx.xxx.4531 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0.N.....)....
..6...P.G......
15:57:39.751673 IP xxx.xxx.xxx.xxx.4533 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0.e..........
..6...P..t+....
15:57:42.888031 IP xxx.xxx.xxx.xxx.4535 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0.u..........
..6...PX.,.....
15:57:42.950597 IP xxx.xxx.xxx.xxx.4537 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0............
..6...P...`....
15:57:43.043791 IP xxx.xxx.xxx.xxx.4539 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0............
..6...P........
15:57:43.196845 IP xxx.xxx.xxx.xxx.4541 > yyy.yyy.yyy.yyy.http: [|tcp]
E..0............
..6...P........
 
Hello,

Do thttpd and pf runs together on same server / vmware with only 1 NIC ?

What is your external NIC? ppp0 ?

What is your internal NIC? le0 ?
 
>Do thttpd and pf runs together on same server / vmware with only 1 NIC ?

Yes, it's bridged nic. On host there are 2 nics, 1 of them is active.
 
working

I changed virtual nic from vlance to e1000 in .vmx host file
and now pf is working correctly.

thanks
mc_hammer
 
You must log in or register to reply here.
Back
Top