May 14, 2008
Where's the Open?
Ok, so it seems that the whirlwind on OpenSSL has settled down a bit. Posts about it are coming from everywhere, ranging from rants on package maintenance to blame-pointing on both upstream and packager sides. And, of course, Slashdot.
Where does all this leave the end user with? Well, probably not much except to
regenerate weak SSH keys with the new openssh-server (now enhanced with
openssh-blacklist, see the new advisory) and hope to $DEITY all gets
well soon. And maybe, just maybe, a minor suspicion that other Debian-packaged
software may be "tainted" with a similar blemish (that being having patches
that are supposed to fix something, applied with upstream's blessing, and yet
not really audited enough to ensure functionality AND security of the
system is maintained.)
Obviously, there's going to be some adjustments to be made on the Debian side.
But I do hope to $DEITY that major revamps ought to happen on the OpenSSL side
as well, in particular on clarifying their public channels to reaching upstream
developers (read: publish openssl-team@openssl.org in a legitimate way, being
the legitimate upstream contact endpoint it is,) and keeping a closer eye on
the vendors who package their software (yeah, it may not be an obligation at
all for OpenSSL, but heck, their vendors are users, too!) Upstream may be
free not to partake on a social contract like Debian's, but it shouldn't
escape from them the fact that vendors nevertheless aggregate continuing and
potential users (aside from being users themselves) for their benefit.
More importantly though, is that delivering FOSS is a community effort. Sure, its easy to put blame now, but in the end, the blame isn't as important as the real cause and effects of the problem/bug/issue are. Better to move on and work together towards a real fix, rather than the bickering that currently passes as FOSS entertainment.
Tags: community, debian, linux, openssh, openssl. | Posted at: 11:31 | 2 Comments/Trackbacks.
May 13, 2008
OpenSSL Ouch
I won't repeat it here, but there's DSA-1571-1 waiting for your attention,
especially if you made some material out of openssl over the last couple of
years or so. Yes, you read it right: COUPLE.
Upgrading to the new OpenSSL is easy. Generating new keys is another story.
To save (or add to, depending on how you handle this) your pain, there is a simple checker that can currently see if your OpenSSH or OpenVPN public keys are weak enough to warrant replacement. I await a version that can handle X.509 certificates too (though I only just generated a new one today, before the announcement, so that means I have to do it again (and get its CSR to CACert for signing, etc.)
And yeah, if you're running openssh-server, consider regenerating your host RSA and DSA keys, e.g.:
# mv /etc/ssh/ssh_host_{dsa,rsa}_key* /some/place/else
# dpkg-reconfigure -plow openssh-server
That should regenerate your keys and restart openssh-server once the new keys
are installed to /etc/ssh.
The hard part (of making sure all the keys of your systems are updated and tested) is still up to you, however.
UPDATE: The Debian wiki has up-to-date information regarding other packages that generate SSH/SSL keys at postinst. Please refer to that while the key-rollover page isn't up yet.
UPDATE 2: openssh-server is updated (with corresponding
DSA-1576-1) that is linked to the updated OpenSSL library. Be sure to
upgrade! The new package also pulls in openssh-blacklist, a new package
that contains the database needed by the new ssh-vulnkey for checking SSH
public keys.
Tags: debian, linux, openssh, openssl, perl, remote, vulnerability. | Posted at: 16:32 | 13 Comments/Trackbacks.
May 10, 2008
Apache2 Worker MPM on Low Memory Servers
If you're running Apache2 on a memory-constrained system (like in a
virtual machine,) you may want to choose the prefork MPM to save memory at
the cost of more process forks. However, if you have more than one CPU on that
same machine, you may also want to consider using the threaded worker MPM
and tweak its MaxClients and ThreadsPerChild settings from the default
configuration.
On a typical apache2 installation on a Debian system, the worker MPM
configuration looks like this:
<IfModule mpm_worker_module>
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
Using these default settings on a resource-constrained system (say a server with 128MB of RAM but with no swap) would be overkill, and the web server processes will definitely eat up all of that memory, leaving little or no room for even simple CGI scripts.
In my setup, I experimented with tweaking the values above to get apache2 to
serve without eating up too much precious memory. I found that the important
values to consider here are MaxClients, which dictate how many clients can
connect simultaneously to my server, and ThreadsPerChild, which specifies how
many threads of execution can run in a child/worker process. My resulting
config becomes:
<IfModule mpm_worker_module>
MaxClients 15
MinSpareThreads 3
MaxSpareThreads 7
ThreadsPerChild 3
MaxRequestsPerChild 200
</IfModule>
With this setup, I free up a significant amount of RAM from apache2's hold whle maximizing my thread usage in each worker process; at the same time, I avoid keeping each child process for too long by setting a maximum number of requests each worker can serve, preventing the workers to bloat too much when handling CGI.
I also tweaked the KeepAliveTimeout setting to just 2 seconds (instead of the
default 15) so that each worker process can go to the next request quickly and
preventing them from being tied up to a connection for too long. I also set
the Timeout to 30 seconds.
Tags: apache2, debian, linux, lowmem. | Posted at: 02:42 | 2 Comments/Trackbacks.
Apr 28, 2008
Some Exim4 hacks
Exim is the stock MTA in Debian, and rightly so, since its pretty much the most flexible MTA around (note: I did say "most flexible," not "most secure.") It is also very easy to set up, thanks to its debconf integration and sane configuration interface; however, there may be some bits that still needs that extra tweaking that a dialog or menu interface can't reach:
Setting the Right mailserver hostname
Most mailservers typically go by a hostname of "mail" or "mx," for various
reasons. Of course, this requires setting the right DNS entry for your domain,
but Exim may miss this and use the internal hostname of your mailserver
instead. There are quite a lot of ways to set the "right" mailserver name in
Exim, but in Debian, it is recommended that one DOESN'T set it via the
primary_hostname variable, as this can mess up other places in the Exim
configuration and complicate matters. Instead, one can use
smtp_active_hostname in the global options:
smtp_active_hostname = mail.foobar.net
Changing Received: header
If one changes the mailserver hostname like above, then it also probably needs
to change some headers as well, like the "Received:" header. Again, this is a
global options setting, controlled by received_header_text:
received_header_text = Received: \
${if def:sender_rcvhost {from $sender_rcvhost\n\t}\
{${if def:sender_ident {from $sender_ident}}\
${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}} }}\
by $smtp_active_hostname \
${if def:received_protocol {with $received_protocol}} \
${if def:tls_cipher {($tls_cipher)\n\t}}\
(Exim $version_number)\n\t\
${if def:sender_address {(envelope-from <$sender_address>)\n\t}}\
id $message_id\
${if def:received_for {\n\tfor $received_for}}
Note that this changes the header when your Exim receives mail; when your Exim sends mail to another mailserver, you'll have to ensure that the header made by the destination mailserver has its hostname matching your own. Thus, you need to fix the "remote_smtp" transport a bit:
remote_smtp:
debug_print = "T: remote_smtp for $local_part@$domain"
driver = smtp
# to disable TLS on outgoing connections, uncomment this
# hosts_avoid_tls = *
helo_data = $smtp_active_hostname # use the variable we set earlier
# use the interface our Exim is running on and where the mailserver name points to
interface = 1.2.3.4
Changing Message-Id
Finally, one can change the "Message-Id" header to match the new hostname
above, via another global options variable,
message_id_header_domain:
message_id_header_domain = $smtp_active_hostname
Tags: debian, exim, linux, mail. | Posted at: 15:03 | 0 Comments/Trackbacks.