Modifications to stock CUPS server

I've been tasked with setting up a Unix print server, since the current one runs unmanaged on a PC beneath someone's desk. Since we use RHEL4 for our servers, obviously this is going to be using CUPS. Setting up CUPS isn't too painful. The web interface is pretty easy to use. My concern though is when you click on the Administration link and log in, it continues to use plain-text HTTP to pass the credentials.

Here are the few things I've changed to make me feel a little bit less uneasy.

First, I created a self-signed SSL certificate and copied the key and crt to /etc/cups/ssl.

Then, I enabled the following in cupsd.conf

ServerCertificate /etc/cups/ssl/server.crt
ServerKey /etc/cups/ssl/server.key
SSLPort 443

I still have the stock port 631 listening as well.

Finally, I modified the index HTML page for the CUPS service. I found this located in /usr/share/cups/doc/index.html. I edited the two hyperlinks for administrator so that it pointed to "https://print.example.com/admin". I know this won't stop people from using "http://print.example.com:631/admin", but at least if they are just clicky-clicky, it will have them log into the administrative interface using HTTPS. I'm not sure how to force users to use HTTPS when accessing the administrative page in CUPS, but at least this is a start.

Now, I don't feel like my usernames and passwords are floating around in the clear when it comes to CUPS.

Thought on malware spreading through known vulnerabilities

The BBC has an article today about the spreading of an Internet worm to millions of PC's (aka Conficker, Downadup, or Kido). Interesting enough, this vulnerability was addressed by Microsoft in MS08-067 on October 23, 2008. The BBC article then obviously states "users should have up-to-date anti-virus software and install Microsoft's MS08-067 patch." What I found interesting was the estimated top locations of infections.

China 38,277

Brazil 34,814

Russia 24,526

India 16,497

Ukraine 14,767

Italy 13,115

Argentina 11,675

Korea 11,117

Romania 8,861

United States 3,958

United Kingdom 1,789

I wonder how this ranking compares to the total number of pirated/unsupported instances of the operating system running in each country, as in "not recognized as a 'Genuine' license to Microsoft and therefore unable to apply patches from Windows Update." I'm wondering if the spread of malware like this that targets personal PC's or office workstations would be significantly reduced if Microsoft either opened up their Windows Update service to non-verified owners, or changed their pricing to be more affordable for its worldwide users.

TaoSecurity's thoughts on the future

REF: http://taosecurity.blogspot.com/2008/11/dont-fight-future.html

The points he raises are interesting, and some seem very probable. The ones I think are interesting are

Prediction 1: VPN connections will disappear.
"Some of you might limit the type of connection to certain protocols, but why not just expose those protocols directly to the outside world and avoid the VPN altogether?"

This may have some merits, but it makes me uncomfortable. It's quite possible I may be looking at it from a narrow point of view of performing my job remotely, and not looking at normal day-to-day work. Some internal assets such as email, collaborative web tools (ex. wikis, Microsoft Share Point), and code repositories (ex. CVS, SVN) might be able to to be exposed with proper strength of authentication and encryption. However, I would think it would be difficult to do many remote administration tasks securely. Maybe the title implies that the VPN connections dramatically decrease, but not totally disappear?

Prediction 2: Intranets will disappear.

This prediction builds off the previous one. I suppose this is a semantics argument. The assets are still going to exist, but since they are exposed to the internet, they would no longer be considered intranet?

The other predictions are definitely plausible to happen in the future. It's a fairly quick and interesting read, so I'd recommend clicking the link above. He has other good posts too, so you may want to add him to your RSS feed if you haven't already.

Another iPhone security problem

Reported by El Reg, it appears that the "Emergency Call" feature on PIN protected iPhones are not discriminatory to certain numbers.

http://www.theregister.co.uk/2008/11/07/iphone_passcode/

I've confirmed this on my iPhone 3G (version 2.1), and was able to dial a non-emergency number (my landline phone number). This number is also not listed as a contact in my phone either. So, word to the wise, if you lose your iPhone, people can still make unauthorized calls on it.

Confused by an SSL related blog post

I subscribe to the Planet SysAdmin, an aggregation of Sys Admin related blogs via RSS (http://planetsysadmin.com/). Today, I came across a post that really confused me on what the author was trying to accomplish or explain.

http://utcc.utoronto.ca/~cks/space/blog/web/RevocableSSLNames

I'm hoping that one of you that is smarter than me gets it and maybe can explain it to me. Using his example of online banking, I look at my bank and it looks like the cert is probably handled by a load balancer; or maybe explained in his second case, an HTTPS Proxy server. He discusses revoking the cert by changing the host name.

A) How would that help when I have a bookmark to https://onlinebanking.example.com?
B) and wouldn't you revoke the compromised cert with the certificate issuer anyways?

The only thing I could think of is he's discussing SSL on both ends of his proxy (web client to proxy, proxy to application server). But in that scenario, the only thing that is apparent to the end user is the SSL cert to the proxy which would have to be revoked by the certificate issuer if compromised.

Or, I'm missing something entirely...

RE: iPhone MAC address post

I ran into this post today from TUAW, and there is now an iPhone app that can switch your MAC address.

http://www.tuaw.com/2008/01/14/tuaw-responds-mac-addresses-on-the-iphone/

I guess that would make it more difficult to keep users from using the corporate wireless network with iPhones, unless you can implement a 802.1 solution.

What I've done at work is only allow wireless into our Guest VLAN. If they need to access corporate assets (printers, shared drives, etc.), then they need to use VPN after connecting to the
wireless network.

iPhone Mac Address OUI's

Because of security concerns, I'm thinking about filtering out iPhone wi-fi access from our corporate "trusted" wi-fi network. One thought would be to know what the MAC addresses for iPhones wi-fi start with, and block those. I found this post.

http://www.everythingiphone.com/forum/wifi/iphone-mac-address-oui-5819.html