Some thoughts on intercepting https traffic
It's been pointed out to me that there are legitimate reasons tointercept and inspect https traffic, and this can even be a primarypurpose of having a local certificate authority .For example, breaking open https traffic can be vital for being able tosee and possibly analyze malware downloads.
(Note that you should really not do this covertly, without admittingthat you're inspecting https traffic. Sooner or later someone willnotice that the SSL certificate authority for some outside site is yourown internal CA, and things
Local CAs and an interesting consequence of the SSL security model
Suppose that your organization creates an internal organizationalCertificate Authority, so that it can issue SSL certificates for strictly internal hostnames . Of course, everyoneneeds to have the internal CA's certificate loaded in their browser andso on in order to get work done on your intranet; as a practical matter,you probably preload it in your standard machine setups. I suspect thatthis is a not uncommon setup in sufficiently large companies.
It's recently struck me that this has an interesting consequence: yourcompany security and firewall
Secure or useful: pick one
A great deal of time, pragmatic security involves striking a balancebetween actual security and usefulness. The more secure you are, theless useful you are; the more useful you are, the less secure. Here,I am taking a broad view of 'useful', one that encompasses not justthings like features but also how easy your system is to use, and howmuch the security gets in the way.
(Sometimes, very rarely, this is not the case. When this happens,celebrate and take
The good and bad of SQL
The good of SQL is that it is an excellent ad-hoc query and reportingtool. If you have an SQL database with a decently formed schema (and inmany ways a denormalized schema is the easiest), you can bang togetherlots of things very fast and easily. Raw SQL is an excellent way toexplore your way around a bunch of data, for example to see if there aresigns that something odd is going on.
(It also makes it possible to answer silly amusing questions that wouldnot be
How Linux software RAID is making me grumpy right now
This weekend, one of my machines sent me email to report:
WARNING: mismatch_cnt is not 0 on /dev/md0
WARNING: mismatch_cnt is not 0 on /dev/md3
What this means (as opposed to what it says) is that a softwareRAID data scrub has detected some number ofinconsistencies between the mirrors for two of my software RAID devices.
(I believe that the kernel also notices this under some othercircumstances, but I can't follow the code well enough
The high costs of true security paranoia in the face of compromises
A while back I wrote about paranoia versus optimism in dealing withsecurity compromises . One of the factorsdriving optimism is the sheer cost of doing otherwise in a decent-sizedenvironment such as, well, ours.
Suppose that we take the paranoid approach; if we detect that an accounthas been compromised on a machine, we make the assumption that there isan invisible rootkit. So we take the machine down, build a replacementfrom scratch, and do forensics on the potentially compromised machine todetect how correct our paranoia
Mercurial versus git for sysadmins, or why we picked Mercurial
I've recently managed to persuade my co-workers to start migrate awayfrom doing version control with RCS and to using a modern VCS (whichhas made me think about various issues ). Specifically, I picked Mercurial, which I thinkis one of only two sensible options right now (the other being git).
I'm perfectly prepared to believe that git has important aspects that make it technically superior , and that githas more power for doing sophisticated things that matter for seriousdevelopment. But for us
Sysadmin versus developer uses of version control systems
Here is a thesis: sysadmins use modern version control systemsdifferently than developers. Specifically, sysadmins generally use VCSesfor documentation, while developers use them for development. By thisI mean that when sysadmins make a commit, it's for something that isalready in use; for example, you change a file in /etc and then commitin order to document when and why you made the change.
(This is certainly our local sysadmin usage of version control, but Ithink it is more than just us,
You should always be able to get a program's version and basic usage
Here is a small little sysadmin request: all programs should be willingto report their version and their usage before either insisting onspecial privileges or doing anything that might fail, such as checkingfor config files, probing various things, or whatever. The rule of thumbshould be if your program can run at all, it should be able to reportthis stuff.
(Note that this specifically includes shell scripts, Perl programs,Python programs, and other interpretable things, ideally even ifthey're being run on the
A wish for KVM virtualization: simple bridged networking
I have a sad confession: despite running Fedora 11 on a machine that'sfully capable of hardware virtualization, I am still using VMWare (andliving with various bits of pain). While there are side reasons, themajor one is that as far as I can see, KVM doesn't have simple bridgednetworking that needs no host-side changes, and VMWare does.
(Now, I freely admit that I may well be missing something in KVM andits setup. I certainly hope so;