Re: PF and LDAP
Thanks Chris! Thanks everybody! I was not clear, my mistake. I'm sorry. The idea is to allow traffic from a computer on the inside network to pass the traffic to the outside network (Internet) using some directory service based on LDAP (Active Directory). Users in the LAN sometimes need to use other PCs than usual or the PC should be used by lots of users. I should be good if the firewall rules could be created to allow/deny based on the user of the PC instead of the IP Address. Note that the PC and the firewall are distinct computers. For example, certain firewalls integrate the firewall rules with some kind of LDAP Server the same way as Squid does (I know Squid is a proxy server). Maybe it is not a smart idea, and if so, I4d like to know why (if possible)? Is there another way to do the same without compromising the security? I thought about authpf, but I'm trying to avoid future problems regarding security. Rgds, Marcello - Original Message - From: Chris Dukes pak...@pr.neotoma.org To: Marcello Cruz marcello.c...@globo.com Cc: misc@openbsd.org Sent: Thursday, July 30, 2009 11:47 PM Subject: Re: PF and LDAP On Wed, Jul 29, 2009 at 01:42:44PM -0300, Marcello Cruz wrote: Dear all, Is there a way to use LDAP in a rule to allow or deny based on the user instead of the IP Address? Okay, I'm going to be literal here... ypldap to map LDAP to NIS. Configure the box to allow users to be resolved by NIS as well as local files. Use the user parameter on the pf rule. There's an example in the pf.conf manpage. The idea is to permit the traffic from an inside user to access, for example, a VoIP resource on the Internet. Of course I have no idea what you mean by inside user. Your specific question indicates someone that can actually log in on the OpenBSD firewall and run a voip application. Which seems reasonable for me because someone might be foolish enough to want me to run asterisk or a SIP gateway on the firewall. If you mean an IP address associated with a specific user... If the system with the IP associated with the user is high function (IE can run an ssh client in addition to everything else), then you want to look at authpf. If the system with the IP associated with the user is low function (IE a SIP phone), but can negotiate WPA, LEAP, PPPoE, or 802.1X, then you'll want to investigate how to retrieve IP/user associations from your network auth mechanism and generate appropriate tables. If your system is using registered MAC addresses to determine which VLAN a NIC goes into, you'll have to look into extracting that data from your registration system, and then correlate it against ARP data. -- Chris Dukes
Re: PF and LDAP
On Fri, Jul 31, 2009 at 08:58:26AM -0300, Marcello Cruz wrote: Thanks Chris! Thanks everybody! I was not clear, my mistake. I'm sorry. Please do not top post and if you are not going to respond to specific bits of quoted text, delete the quoted bits of text. Thanks. The idea is to allow traffic from a computer on the inside network to pass the traffic to the outside network (Internet) using some directory service based on LDAP (Active Directory). I suspect you have not a clue about the layers to networking. Let's go for the simple case of a single user/computer Let's start at the lowest network layer. http://www.geocities.com/billalexander/ethernet.html Do you see any fields in the header that contain user or auth information? Let's go up a layer http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/ip-packet.html Do you see any fields in the header that contain user or auth information? Another layer http://en.wikipedia.org/wiki/Transmission_Control_Protocol go down to TCp segment structure Do you see any fields in the header that contain user or auth information? Same layer, different protocol http://en.wikipedia.org/wiki/User_Datagram_Protocol See anything in the headers that looks like user or auth information? Let's go up one more layer http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html look at section 14.8, ah we have credentials. Unfortunately, pf does not process packets this deeply. With the exception of packets initiated from the machine running pf, pf has no idea what user is associated with a given packet. You can have a table of IPs associated with a given set of rules and management of that table by some mechanism that involves LDAP authentication. You can bring associate an IP with a user specific rule set through authpf on the OpenBSD firewall. You can redirect all traffic for a permitted protocol to a proxy server for that protocol. And have that proxy server require certain authorization information. Users in the LAN sometimes need to use other PCs than usual or the PC should be used by lots of users. I should be good if the firewall rules could be created to allow/deny based on the user of the PC instead of the IP Address. Note that the PC and the firewall are distinct computers. For example, certain firewalls integrate the firewall rules with some kind of LDAP Server the same way as Squid does (I know Squid is a proxy server). And 'pf' is out of the picture when you reach the data portion of a TCP or UDP packet. You can redirect the traffic to a proxy, but once that's done, it really ceases to be an OpenBSD issue. And if you have a machine that allows more than one user on at once, you'll either have to use whatever packet filtering services are available on it to block on a per user basis, or else ensure that traffic is redirected to proxy servers that require user authentication. If the protocol does not lend itsself to a proxy server that requires user authentication, then you'll have to investigate VPN technologies that restrict access to a specific VPN to the user that started it and doesn't choke at a single IP running multiple VPNs to the same destination. Again, OpenBSD is out of the picture unless this shared use machine is running OpenBSD. Maybe it is not a smart idea, and if so, I4d like to know why (if possible)? Is there another way to do the same without compromising the security? I thought about authpf, but I'm trying to avoid future problems regarding security. The two biggest threats to computer security are 1) Users 2) Ignorance Hopefully this email will start to address #2. I suggest a wood chipper for addressing #1. -- Chris Dukes
Re: PF and LDAP
On 2009-07-31, Marcello Cruz marcello.c...@globo.com wrote: Thanks Chris! Thanks everybody! I was not clear, my mistake. I'm sorry. The idea is to allow traffic from a computer on the inside network to pass the traffic to the outside network (Internet) using some directory service based on LDAP (Active Directory). Users in the LAN sometimes need to use other PCs than usual or the PC should be used by lots of users. I should be good if the firewall rules could be created to allow/deny based on the user of the PC instead of the IP Address. looks like a job for authpf + ypldap, with some ssh app on the client machines.
Re: PF and LDAP
30.07.09, 13:55, Marcello Cruz marcello.c...@globo.com:
Dear all,
Is there a way to use LDAP in a rule to allow or deny based on the user
instead of the IP Address?
The idea is to permit the traffic from an inside user to access, for example,
a VoIP resource on the Internet.
Based on user...
I use for this PPPoE server with list of usernames/passwords/IP addresses.
Users connect with their usernames to PPPoE server, and PF controls traffic
from
PPPoE IP addresses.
You can write script to synchronize users in LDAP and /etc/ppp/ppp.secret file.
Example: allow access for user1 to web sites, and for user2 to mail servers
/etc/ppp/ppp.secret
user1 pass1 192.168.100.1
user2 pass2 192.168.100.2
..
/etc/pf.conf:
table squid-pppoe file /etc/pftables/int-web-pppoe
table mail-pppoe file /etc/pftables/int-mail-pppoe
pass in log quick on tun inet proto tcp from mail-pppoe to any port = pop3
pass in log quick on tun inet proto tcp from mail-pppoe to any port = smtp
pass in log quick on $pppoe_if_grp inet proto tcp from web-pppoe to any port
{ www, https }
..
/etc/pftables/int-web-pppoe
192.168.100.1
..
/etc/pftables/int-mail-pppoe
192.168.100.2
..
Re: PF and LDAP
On Wed, Jul 29, 2009 at 01:42:44PM -0300, Marcello Cruz wrote: Dear all, Is there a way to use LDAP in a rule to allow or deny based on the user instead of the IP Address? Okay, I'm going to be literal here... ypldap to map LDAP to NIS. Configure the box to allow users to be resolved by NIS as well as local files. Use the user parameter on the pf rule. There's an example in the pf.conf manpage. The idea is to permit the traffic from an inside user to access, for example, a VoIP resource on the Internet. Of course I have no idea what you mean by inside user. Your specific question indicates someone that can actually log in on the OpenBSD firewall and run a voip application. Which seems reasonable for me because someone might be foolish enough to want me to run asterisk or a SIP gateway on the firewall. If you mean an IP address associated with a specific user... If the system with the IP associated with the user is high function (IE can run an ssh client in addition to everything else), then you want to look at authpf. If the system with the IP associated with the user is low function (IE a SIP phone), but can negotiate WPA, LEAP, PPPoE, or 802.1X, then you'll want to investigate how to retrieve IP/user associations from your network auth mechanism and generate appropriate tables. If your system is using registered MAC addresses to determine which VLAN a NIC goes into, you'll have to look into extracting that data from your registration system, and then correlate it against ARP data. -- Chris Dukes
PF and LDAP
Dear all, Is there a way to use LDAP in a rule to allow or deny based on the user instead of the IP Address? The idea is to permit the traffic from an inside user to access, for example, a VoIP resource on the Internet. Thanks in advance. Marcello
Re: PF and LDAP
* Marcello Cruz marcello.c...@globo.com [2009-07-29 10:51]:
Dear all,
Is there a way to use LDAP in a rule to allow or deny based on the user
instead of the IP Address?
Define user - in the context of IP. last time I looked no such thing
was in there.
authpf comes close, but remember, traffic can be spoofed.
-Bob
The idea is to permit the traffic from an inside user to access, for example,
a VoIP resource on the Internet.
Thanks in advance.
Marcello
--
#!/usr/bin/perl
if ((not 0 not 1) != (! 0 ! 1)) {
print Larry and Tom must smoke some really primo stuff...\n;
}
simple pf, apache, ldap captive portal
would like to authenticate users off of an ldap directory before letting them loose on the internet ... for testing purposes this is what i've come up with: pf.conf ... int_if = rl0 ext_if = rl1 table auth_hosts persist nat on $ext_if from auth_hosts - ($ext_if:0) rdr pass on $int_if inet proto tcp from ! auth_hosts to port www - 127.0.0.1 port 8000 config'ed apache to listen on 127.0.0.1:8000, load the auth_ldap module and require ldap authentication off of an ms active directory box to load index.html (the default while i'm testing): Listen 127.0.0.1:8000 LoadModule auth_ldap_module /usr/lib/apache/modules/mod_auth_ldap.so DocumentRoot /var/www/htdocs Directory / Options Indexes FollowSymLinks AllowOverride None AuthType Basic AuthName Authentication Required AuthLDAPBindDN obfuscated AuthLDAPBindPassword obfuscated AuthLDAPURL ldap://obfuscated?samAccountName? Require valid-user Order allow,deny Allow from all /Directory so far so good ... browser get's prompted for creds, they're bounced off of an ldap server and, if valid. the default as shipped index.html page appears the next and most obvious thing is to get the source ip of the connecting client into the auth_hosts table as in: pfctl -T a -t auth_hosts ip address of client what's not obvious to me is the best, as in simple and straightforward, way to do so ... don't really know much about tweaking apache,cgi, php, etc. ... perhaps the index.html could call a shell script passing the ip addy as an argument? don't seem to be having much luck with exec cmd i suspect the default chrooted environment that apache runs in would present some hurdles to this perhaps some clever incantation of pf's overload state option in combination with an index.html file that forces multiple sessions to the existing 127.0.0.1:8000 instance of apache or even another used for this purpose? any thoughts or suggestions would be appreciated. -p
