vpnc and shorewall

I wanted to configure my home Linux box with vpnc.  I had done this before, but I’ve lost track of the documentation I made at the time.

First, I ran pcf2vpnc on the .pcf configuration file — what an easy way to get the .conf file needed by vpnc!

Then I tried running vpnc.  From the messages it gave, it looked like I was successfully connected… but I couldn’t ping any servers… hmm.

Diagnosing

After a few minutes, it began to dawn on me that I had experienced a very similar issue before, and that time it wasn’t the vpnc configuration.  It was the firewall that was rejecting all traffic from the vpn.

I stopped shorewall and sure enough, I was able to get into the network and ping things.

Solving

I:

1. Added this line to /etc/shorewall/zones:

   vpnc  ipv4
   

2. Added this line to /etc/shorewall/interfaces:

   vpnc  tun0  detect
   

3. Added this line to /etc/shorewall/tunnels, replacing xx.xx.xx.xx with the IP address of my  router:

   generic:udp:500    net  xx.xx.xx.xx
   

4. Finally, I believe I added this fw vpnc ACCEPT line to /etc/shorewall/policy:

   fw      vpnc    ACCEPT
   net     all     DROP    info
   all     all     REJECT  info

   (I believe this line needs to be above the more general net-all-DROP and all-all-REJECT lines, as shown.)

I then restarted shorewall and I was off and running.

Basically I guess we’re telling shorewall to allow all traffic from the firewall to the vpn interface, where by default it would deny such traffic otherwise.  I need to get a deeper understanding of what’s going on here, though.

Thanks to Gary Court and Tobias Weisserth, whose posts were helpful!

Security maxims

There’s a list of over 40 Physical Security Maxims put together by Roger G. Johnston from the Argonne Vulnerability Assessment Team.  They have funny names like the Huh Maxim, Yipee Maxim, Arg Maxim, and Gossip Maxim.

Johnston says,

The following maxims are somewhat cynical and tongue-in-cheek. Nevertheless they say important things about physical security, and are essentially correct 80-90% of the time (unfortunately).

Check them out!

(Thanks to Bruce Schneier’s Crypto-Gram for the pointer to this list.)

Who did you say you were?

Sometimes you want authentication — you don’t want to let a connection in to your system unless it supplies the right credentials.  Other times, you just want identification — for instance, you might want to remember who it was that initiated a request.

One example of this distinction is when you’re dealing with JMS queues.  The process that puts a message in a queue may have been involved in authenticating the user… but the process that takes that message out of the queue to process may not have been.  That receiving process needs a way to identify the user that placed the message in the queue.

The first part of the solution is to pass the userId along with the JMS message, to the queue.  You can do this by setting a String property on the JMS Message.

Before we can use LDAP to look up information about this user, though, we need to populate the Spring security context with this userId.  (Spring does support setting the SecurityContextHolder contents directly.)  So that the domain-level developers don’t have to worry about this, we can use AOP around-advice, like this:

    public Object doPopulateSecurityContext(ProceedingJoinPoint proceedingJoinPoint) throws Throwable {
        Message message = (Message) proceedingJoinPoint.getArgs()[0];
        String userId = message.getStringProperty("userId");
        UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(userId, "");
        SecurityContext context = new SecurityContextImpl();
        context.setAuthentication(authenticationToken);
        SecurityContextHolder.setContext(context);

        Object retVal = proceedingJoinPoint.proceed();

        SecurityContextHolder.clearContext();
        return retVal;
    }

This populates the information about the current user so that the MessageListener can look up things in LDAP based on that.