Contributed by merdely on from the i-see-you dept.
In February, Ryan McBride (mcbride@) committed an update to authpf(8) adding "authpf-noip" support. From the commit message:
Add authpf-noip, which allows multiple users to connect from a single IP; forces users to write sane rulesets for this by not providing $user_ip or updating the authpf table.
Mark Uemura (mtu@) shares some background and a very nice write-up on authpf-noip below.
From the man page:
authpf-noip is a user shell which allows multiple connections to take place from the same IP address. It is useful primarily in cases where connections are tunneled via the gateway system, and can be directly as- sociated with the user name. It cannot ensure accountability when clas- sifying connections by IP address; in this case the client's IP address is not provided to the packet filter via the client_ip macro or the authpf_users table. Additionally, states associated with the client IP address are not purged when the session is ended.
Mark writes:
I remember talking with Bob Beck (beck@) about our two wireless solutions a couple of years back, both of which use authpf. What was interesting to us was that he was more interested in ensuring that users at his University did not abuse his network outbound, and I was looking at it from the other direction. I wanted to ensure that inbound users to the Corporate network resources were identified, authenticated, authorized and limited to only what our Security Policy allows.
Our remote access solution involves giving users dedicated workstations at the office and inexpensive laptops for remote access while at home or on the road, all running Windows XP. The laptops are considered dumb terminals for remote access. At the office, the workstations are locked down, running their own firewalls, AntiVirus software and with limited user privileges. However, the major problem that we have to deal with are the users.
If staff can turn off security measures or otherwise undermine security, then we have a problem. At home or on the road, users tend to double-click on attachments and install programs they should not besides visiting possibly malicious websites and use various P2P programs. Through their actions, they unknowingly infect their laptops with worms, Storm Worms, viruses, Trojans and other malware. This is a problem with traditional VPN solutions: infections spread to the internal network because the infected remote system is considered part of the internal network once authenticated. Unfortunately, no amount of user education or security awareness will help eliminate this problem.
Knowing this, we wanted to provide a clear boundary between work and personal activities. We accomplished this and more by forcing remote users to use a Remote Desktop Connection (RDC) tunnelled through an encrypted OpenSSH tunnel. Authentication is done using their SSH key and passphrase besides their Windows login credentials.
Similarly, at the office, users are not allowed to hook up their laptops onto any of the "Trusted" networks. We provide them with a different coloured cable ("Untrusted" network) for this purpose and laptops brought to the office are treated exactly as if they were on the user's home network.
The only communication allowed is a remote desktop connection tunnelled through an SSH session. Obviously nothing is allowed before identification, authentication and authorization. Afterwards, all that passes through the tunnel are bitmap changes, keyboard and mouse movements via remote desktop. Moreover, creating mapped drives through RDC is forbidden and enforced by a Domain Group Policy. In this way we allow the remote user to do as he or she normally would be able to do but from a distance. We allow human interaction but we deny direct computer interaction. Besides the simplicity of this solution, infection of any sort is now mitigated if not prevented outright. This is the main reason we prefer this solution for remote access.
It's difficult to solve a social problem with technology, but it seems that we are able to curtail it with this solution. The damage that can be done from an infected laptop is isolated to that laptop and not the corporate network. There is no direct communication between the user's laptop at home and the user's workstation at the office. Authpf loads a very strict user specific rule set (authpf.rules) allowing only a remote desktop session to the user's workstation. After successful authentication the user has access to all internal resources via their workstation.
There are many benefits to this remote access solution:
- Ease of use
- It is easier to configure than IPsec and has many benefits over an IPsec VPN.
- It is simple, efficient, effective and relatively inexpensive.
- It does not limit functionality but rather extends the user experience.
- The users can work from anywhere physically away from their workstations.
- Manageability
- It saves bandwidth as the solution has a small network footprint.
- It eliminates degraded network performance due to fragmentation issues.
- Rather than laptops, LiveCDs or bootable memory sticks can be used as clients.
- In fact, you are not limited to using Windows for the client.
- Virtualization technology or Terminal/Citrix Servers can used on the back end.
- In our experience, it dramatically reduces Helpdesk Support.
- It now works with many NAT'ed remote access users behind the same public IP.
- Cost
- It can possibly extend the End-of-Life for laptops.
- There is no commercial software or hardware lock-in.
- Security
- It keeps the trusted workstations free of worms, viruses, trojans, etc.
- There is also a clear boundary between personal and work related computing.
- Users are more accountable for their actions.
- You also have all the security that comes with using OpenSSH and OpenBSD.
This solution works quite well with the basic authpf, but NAT has always been a problem. Imagine a group of users who would go to a conference together, stay in the same hotel and then try to remotely access their workstations. The problem was that they were usually coming in from one IP address NAT'ed behind some gateway, and authpf only allows one connection per IP address. This behaviour is by design, in order to ensure that authpf correctly enforces policy and guarantees accountability.
However, thanks to Ryan McBride and Bob Beck, this is no longer a problem. The change was due to a "little epiphany" as Bob put it, of not allowing $user_ip in the authpf.rules file if we remove the restriction on multiple connections per source IP and therefore no longer "trust" that information.
With this simple idea, Ryan was able to implement a 'noip' mode for authpf (/usr/sbin/authpf-noip) that makes it possible to have multiple ssh connections from authpf users coming from the same IP address, i.e., many authpf users NAT'ed behind the same gateway.
And now for the technical how-to...
We have to make a few minor changes to the existing setup, if you have been using authpf already, to allow multiple connections coming in from the same IP address.
So, rather than /usr/sbin/authpf for the user's authpf shell, we change this to /usr/sbin/authpf-noip with a command like this:
chsh -s /usr/sbin/authpf-noip username
Note that you only really want to use authpf-noip in tunnelling situations. That is, for inbound connections to internal resources such as internal workstations or POP/SMTP mail tunnelled through OpenSSH.
We also want to make sure that the user is not in the "authpf" login class as it overrides the shell that you set in /etc/passwd.
This is an example of username's authpf.rules (/etc/authpf/users/username/authpf.rules):
username_ip="www.xxx.yyy.zzz" pass out log on $int_if inet proto tcp from $int_if to \ $username_ip port 3389 user $user_idThere are a lot of SSH clients available for Windows. Use whatever best suits your needs. Essentially, you want the following command to be run:
where AAA.BBB.CCC.DDD is the public IP address of your OpenSSH Server.ssh -l username -i username-openssh-key-date -L 3390:www.xxx.yyy.zzz:3389 \
AAA.BBB.CCC.DDDThen open a Remote Desktop Connection to localhost:3390.
Thereafter, the user should be authenticating to their own workstation at the office. Obviously, this is not limited to IPv4 networks.
authpf-noip with ssh port forwarding for secure remote access may not be the best solution for all situations and environments. It is the best solution for our needs with a myriad of real benefits to security.
Thank you to Mark for his excellent explanation of how he uses authpf-noip. If you have a interesting write-up explaining how you're using an OpenBSD technology, please share your experience.
(Comments are closed)
By Curt Micol (69.16.222.102) asenchi@asenchi.com on
Comments
By Terrell Prude' Jr. (151.188.18.42) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/
Agreed, thanks, this is quite helpful.
The way we do it now is through a traditional IPSec VPN. The user fires up the client, authenticates, and boom, they're in. The problem is getting the bosses from the top to be willing to back up such an excellent policy as you describe. I can hear the whining and complaining now. "Oh, it's too hard!" "I'm not a 'computer person', I need to do *real* work!", ad nauseam. The bosses, sadly, usually side with such whiners because they don't tend to trust the IT folks. This is despite the fact that what you're describing is actually quite easy for the end user to operate.
--TP
By Barry (63.237.125.21) on
Comments
By Anonymous Coward (198.175.14.5) on
Yes. It's encrypted with a decent scheme. It also is much faster (probably because it ties in at the widget API and not the bitmap images)
By ostiguy (216.240.26.4) on
I am not a VNC expert - post the release of XP (only 2000 server had RDP), I use RDP for everything that is capable of it on Windows.
RDP benefits:
Good crypto possible, but potential MITM vulnerabilities - when possible, use through a VPN that mitigates MITM risk
Performance much much better than VNC on higher latency links - up to 75ms one way, and it should be fine.
Auditing - with right settings enabled, the security event log should have connecting IP and username details.
By emre onur kurt (88.247.138.23) ciscoine@gmail.com on www.destarnet.com