Keep in mind that MAC addresses will only be available for machines on the same physical network segment as you, so unless this is just intended for use on a single LAN that'd be heading down the wrong track.

A much better solution would be to use SSL/TLS certificates to strongly authenticate clients.

Update: Also note that it's not impossible to spoof another host's MAC given the right OS and a cooperative NIC. Granted they'd have to knock the real host off the network or it'd probably send packets with RST set when it sees traffic for TCP connections it knows nothing about, but traffic from a given MAC doesn't guarantee it's from that NIC.

Good point. Most clients will be on the same physical network segment, but some will not be. Hmmmm. /me goes off to read up on coding SSL certificate authentication...

cLive ;-)

Set them to expire every so-many-months, and filter by signer if you need to ban someone who is abusive.

• Your application is secure. The application should be very carefully written, should use taint mode, etc.
• Your server is secure. Make sure other services are locked-down, it's probably behind a firewall, running only necessary services. You should be running a secure operating system, probably some kind of Unix. Also make sure you have a procedure for regularly updating the installed components of your OS, such as Debian's apt-get or RedHat's up2date.
• Your network is secure. Your router and switches should be reasonably well-protected, etc.
• Your clients are secure. Make sure they're running secure OS's, if possible, and are regularly updated. If one of your clients is taken over by the latest virus and an intruder gains access to the keyboard and screen of the machine, all of your other security is worthless.

If you want to do MAC-level filtering, it's probably best to do that at the OS/firewall level; that information isn't readily available to a userspace program. Of course this will only work for machines on the same LAN as you, and users can change their MAC address, so this doesn't add too much.

While I agree with the rest of your post, I want to comment on your last point:

One should never assume the clients are secure. Always (if at all possible) treat clients with utmost suspicion, and that means not trusting any data you get from the clients unless it checks with the stuff you know. Taint checking all the input should go without saying.

Assuming the client is out to get you not only protects you from clients that have been taken over by black hats, but also from bugs in the client...

I agree that the script should never assume the client is secure, as an essential component of a security-in-depth strategy.

However, a secure client really is necessary for making sure only authorized users use the script. A compromised computer may be under an unauthorized user's control, but have a permitted IP address and access to the password or the SSL certificate.

I have a feeling that grabbing the Apache request before it hits the SOAP stuff through a PerlHandler) would be the easiest way of doing that. Although that's not how I'm currently approaching it :)

I was going to add a 'LocalAuth' module (or similar) that would be run at the beginning of a method call, something along the lines of:

if ($auth->can('set credit card')) {
    proceed();
}
[download]

as the final lock down at the application level, where individual methods are listed in a DB along with identifying group(s) of hosts allowed to run them (then do a group look up to see which group the particular host belongs to.

I'm still in flux over all this, but having great fun experimenting :) Perhaps you'd care to expand on your ideas...

cLive ;-)

The DB solution is exactly what I have in mind. The "$auth->can" call in the method call is one solution I thought about.
Since this requires an additional call in the method code, I would opt for an inherited method or an additional module in SOAP::Lite, that does this work.

Gnork

cat /dev/world | perl -e "(/(^.*? \?) 42\!/) && (print $1))"
errors->(c)