Ernie's questions

This actually applies to a bunch of other services we use this same certificate for, but the way Apache does this is the most obvious and contradictory when you compare the test results.

We have a wildcard certificate on our website at https://webmail.lightspeed.ca. Web browsers give our clients a green lock, GeoTrust's CryptoReport at https://cryptoreport.geotrust.com/checker/ tells me that our certificate is installed correctly. Yet when I try to use openssl s_client -connect webmail.lightspeed.ca:443, I get the error Verify return code: 20 (unable to get local issuer certificate)

This is what our Apache configuration looks like for SSL:

SSLEngine on
SSLCertificateFile /mailhome/webmail.lightspeed.ca/ssl.cert
SSLCertificateKeyFile /mailhome/webmail.lightspeed.ca/ssl.key
SSLCACertificateFile /etc/ssl/certs/GeoTrust_DV_SSL_CA-G3.pem

While I understand that the connection is being encrypted, evidently this error message also means that I'm not being fully verified as who I say I am. This is problematic when we apply these same certificates to say, our SMTP or POP server, as some clients (like Outlook for Android) are really anal about this stuff. The test at http://www.checktls.com/perl/TestReceiver.pl doesn't like this, for example, and we get the error Cert NOT VALIDATED: unable to get local issuer certificate. I find that really weird, because the file GeoTrust_DV_SSL_CA-G3.pem is our intermediate CA certificate. And it's Geotrust's CA for our particular kind of wildcard cert.

This has been nothing but a source of aggravation for me. Your help would be greatly appreciated.

We have a mail server built on top of a Gluster distributed filesystem. While this has proven to be fairly easy to set up and quite stable, the performance of our webmail has been quite slow. So now I get to tune the performance of the underlying filesystem (which is almost certainly the cause of the slowness - it was lightning quick when we had our mail stored on the local filesystem).

The problem starts with the fact that I have no idea how to actually measure how fast IMAP retrieves individual messages. Without this metric, I can't determine which tuning variables are helping us. Moreover, it seems that caching doesn't work with IMAP. If I try to retrieve the same message again, it takes at least as long as the first time. Using the ls or du command on the filesystem itself does cache the results, and subsequent requests are much faster than the first. So timing these results wouldn't be able to help me much.

Any help would be appreciated.

We have a Munin server that's taken to some really strange behaviour lately. The website itself is working perfectly, we're getting our statistics, I'm getting paged, everything is otherwise fine except... Every 5 minutes I'm getting an e-mail that says:

/bin/sh: 1: munin: not found
This program will easily break if you run it as root as you are
trying now.  Please run it as user 'munin'.  The correct 'su' command
on many systems is 'su - munin --shell=/bin/bash'
Aborting.

So, I figure that the crontab in /etc/cron.d/munin-node has the wrong username, right? No...

#
# cron-jobs for munin-node
#

MAILTO=root

# If the APT plugin is enabled, update packages databases approx. once
# an hour (12 invokations an hour, 1 in 12 chance that the update will
# happen), but ensure that there will never be more than two hour (7200
# seconds) interval between updates..
*/5 * * * *     munin if [ -x /etc/munin/plugins/apt_all ]; then munin-run apt_all update 7200 12 >/dev/null; elif [ -x /etc/munin/plugins/apt ]; then munin-run apt update 7200 12 >/dev/null; fi

I've even completely removed the file /etc/cron.d/munin-node and it still carries on as if it's there, and that it's trying to run as root.

And, of course, the statistics keep showing up on time. It's driving me nuts, if only because I'm getting crap e-mails every 5 minutes.

I currently have one server that's connecting to a centralized MySQL server (say, 192.168.0.10). This server already allows remote connections from this IP address (say, 192.168.0.20), and in spite of my changes so far, continues to work. For this one IP address.

When I try to grant access to this same username and password from different hosts like this:

update db set host='192.168.0.%' where user='username';
update user set host='192.168.0.%' where user='username';
flush privileges;

Everything still stays the same. I can still connect from 192.168.0.20, but I also still can't connect from 192.168.0.25. I get the error message

ERROR 1130 (HY000): Host '192.168.0.25' is not allowed to connect to this MySQL server

I can't see how this is wrong. All the documentation says it should work. I'm also not firewalling connections from 192.168.0.25. Even restarting MySQL has no effect. Other IPs on this network can connect to MySQL without any issue - even ones that were previously not allowed - and I can ping 192.168.0.10 from 192.168.0.25.

So I've set up my initial master-slave replication pair on two different MySQL servers. That part is working great. So all I have to do is set up the first master as a slave and set up the first slave as the second master, right?

Wrong!

This is what happens when I try to create the second slave account on the secondary master server:

mysql> grant replication slave on *.* to 'repslave2'@'ourhost' identified by 'password';
Query OK, 0 rows affected (0.00 sec)

mysql> start master;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'master' at line 1

What? What do you mean, "syntax error"? This is pretty simple stuff. I spelled "master" right. It worked on the other server without having to install anything special. "stop slave" and "start slave" work as advertised on this server. Why won't it work?

EDITED TO ADD:

I think I've found part of the problem - that the master-slave replication is confused between the two servers. Here, I've tried to stop the master on the primary master:

mysql> stop master;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'master' at line 1
mysql> stop slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> stop master;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'master' at line 1
mysql> start master;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'master' at line 1
mysql> start slave;
ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO

Currently, we have a fully working POP/IMAP/Webmail system (using Dovecot and Roundcube) that is a gleaming tower of perfection in its intended design. We have thousands of customers who belong to a "default" domain (I'll call it ourdomain.com), and successfully log in with a username and password. We have a few thousand more who own domains that we host, and they log in successfully with their full e-mail address and password (call it customerdomain.com). It's been this way since the 1990s, with a lot of entrenched customer configuration.

The problem is now that people are used to logging into web forms with a full e-mail address, people who use ourdomain.com have to be reminded to log into webmail using only their username. This is a call our tech support department gets several times a week (and even I am guilty of doing this, I just don't call tech support about it), and probably should be eliminated with some kind of software solution.

So how do we get either Roundcube or Dovecot to recognise "[email protected]" as "username" instead, without having to change everyone's actual username in our system? But only do that if the domain is "ourdomain.com" and not "customerdomain.com". Keep in mind that any custom coding we do will have to be re-implemented every time we do security upgrades, and we would only consider that option as the last possible choice.

TL;DR:

We need this logic:

if $email contains @ourdomain.com
{
    remove @ourdomain.com;
    submit to roundcube;
} else {
    submit to roundcube;
}

We upgraded our Debian web server to Wheezy this morning, and after everything else came up fine, Apache appears to have lost the ability to execute PHP scripts, while it was able to do so before the upgrade. Now we only see the PHP code, as if the PHP module weren't enabled.

I've checked all the usual suspects, ensured that the PHP module is loaded and installed, and made sure /etc/apache2/mods-enabled/php5.conf has the "SetHandler application/x-httpd-php" option set. I've also followed the most recent documentation for installing PHP5 on Apache, and everything appears to check out. There aren't any errors in the Apache error log either that would indicate a problem.

Is there anything I've missed?

Output from 'apachectl -t -D DUMP_MODULES |grep php':

Syntax OK
 php5_module (shared)

Output from 'www3:/etc/apache2# apache2 -v':

Server version: Apache/2.2.22 (Debian)
Server built:   Jan 31 2014 18:55:37

Contents of /etc/apache2/mods-enabled/php5.conf:

<IfModule libphp5.so>
#    <FilesMatch "\.ph(p3?|tml)$">
#    </FilesMatch>
    <FilesMatch "\.php$">
        SetHandler application/x-httpd-php
    </FilesMatch>
    # To re-enable php in user directories comment the following lines
    # (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
    # prevents .htaccess files from disabling it.
    <IfModule mod_userdir.c>
        <Directory /home/*/public_html>
            php_admin_value engine Off
        </Directory>
    </IfModule>
</IfModule>

Latest apache error logs from the last restart:

[Thu Apr 10 15:35:44 2014] [notice] caught SIGTERM, shutting down
[Thu Apr 10 15:35:45 2014] [warn] No JkLogFile defined in httpd.conf. Using default /var/log/apache2/mod_jk.log
[Thu Apr 10 15:35:45 2014] [warn] No JkShmFile defined in httpd.conf. Using default /var/log/apache2/jk-runtime-status
[Thu Apr 10 15:35:45 2014] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Thu Apr 10 15:35:45 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Thu Apr 10 15:35:45 2014] [notice] Digest: generating secret for digest authentication ...
[Thu Apr 10 15:35:45 2014] [notice] Digest: done
[Thu Apr 10 15:35:45 2014] [warn] No JkLogFile defined in httpd.conf. Using default /var/log/apache2/mod_jk.log
[Thu Apr 10 15:35:45 2014] [warn] No JkShmFile defined in httpd.conf. Using default /var/log/apache2/jk-runtime-status
[Thu Apr 10 15:35:45 2014] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Thu Apr 10 15:35:45 2014] [notice] Apache/2.2.22 (Debian) DAV/2 SVN/1.6.17 mod_fcgid/2.3.6 mod_jk/1.2.37 PHP/5.4.4-14+deb7u8 mod_ssl/2.2.22 OpenSSL/1.0.1e mod_perl/2.0.7 Perl/v5.14.2 configured -- resuming normal operations

I'm going to start by admitting I don't really know much about networking beyond "Ethernet plug goes here, switch connects to other switch(es) here, switch connects to internet". Most of my experience with switches has been with their default configuration and we just leave each other alone.

In our datacenter, we have a network of servers served by a single 24 port PLANET SGSW-24040, which is apparently a 1000 Mbps Level 2 managed switch. When we bought it, it replaced an older Cisco/Linksys 10/100 switch that wasn't up to the task of switching VoIP data. Replacing the old switch solved our voice quality problems.

That was all well and good, and we didn't appear to have any further problems with it, until I found a nifty feature that lets me use Munin to measure bandwidth through SNMP. It also measures network errors, which I considered to be a good thing. After setting Munin up to collect these statistics, I started getting paged frequently about individual interface errors.

Reading up on the problem, I found that I could resolve the network errors by explicitly configuring the speed of the port that was generating the error. And that's where I started running into real problems. Whenever I rebooted a server, it wouldn't renegotiate the ethernet connection, and the server would be offline until I set its port on the switch to "autodetect".

So now I'm stuck between a rock and a hard place: I can either turn off the reporting of network errors and set all the ports on the switch to autodetect, or I can eliminate the errors in the first place at the cost of being forced to remember to reconfigure the switch anytime a server is rebooted for a kernel upgrade. Is this a problem with this particular switch? Is there some way to manually configure the ethernet on the servers (they're all Debian Linux)? Should I have to do any of this at all in the first place?

For as long as I've been using a DHCP server on Linux or even FreeBSD (all come from ISC if I recall correctly), it seems that it just doesn't know what to do with DHCP requests when the Internet goes down. It doesn't matter if the gateway is on the same machine or a different router, or if the router keeps working but the Internet has been disconnected, the DHCP server simply stops assigning IP addresses.

This is highly disruptive to our office, where we have workstations that need to connect to our internal customer database, even when we're offline. Never mind what happens to our Cisco IP phones when they can't get their DHCP leases. Sure, we can't make any calls through our SIP trunk when we have no Internet, but the phones should at least connect to the PBX.

Is there a fix for this problem, or is that "just how the DHCP server works"?

We're using BIND 9.7.3 on the stable version of Debian (updated weekly), and we see some very strange behaviour for one particular domain. We host a few hundred, but this one is ours.

Basically, the secondary DNS server is trying to transfer the domain from the master. According to the logs, it succeeds in transferring the domain every time, but it always gets the serial number wrong! As a result, it keeps re-doing the transfer at every opportunity. I'm not even sure where it's getting the serial number, because the primary server reports back with the right serial number.

Here's the logs we get from the secondary (the ip 192.168.0.130 is the primary server, 192.168.0.4 is the secondary. And of course, they're not real.):

Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: connected using 192.168.0.4#60959
Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs (0 bytes/sec)

This seems pretty normal, although both hosts are set up with IPv6 addresses and technically speaking they should be using them, but that's a problem for another day (I think).

So let's query the primary server from the secondary one, and see what it says:

$ host -4 -t any mydomain.ca 192.168.0.130
Using domain server:
Name: 192.168.0.130
Address: 192.168.0.130#53
Aliases: 

mydomain.ca has IPv6 address fc00:::31
mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011082201 900 3600 604800 86400
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca has address 192.168.0.205
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00:::23 ip6:fc00:::12 ip6:fc00:::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"

And then let's do the same for the secondary nameserver:

$ host -4 -t any mydomain.ca 192.168.0.4  
Using domain server:
Name: 192.168.0.4
Address: 192.168.0.4#53
Aliases: 

mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011011013 600 600 600 600
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
mydomain.ca has address 192.168.0.205
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca has IPv6 address fc00::31

You can see here that the serial number is 2011011013 on the secondary, but 2011082201 for the primary. I've used the date plus a 2-digit number, so the secondary is somehow using a serial number from January. I've tried searching our configuration on both the primary and secondary servers for this serial number, but it's nowhere to be found.

Speaking of configuration, here's the configuration for this domain in /etc/bind/named.conf:

zone "mydomain.ca" { type slave; file "secondaries/mydomain.ca"; masters { 192.168.0.130; }; };

and the timestamp on secondaries/mydomain.ca is the time of the most recent update. Deleting this file still results in a serial number of 2011011013. The contents of this file are very long, but here are the headers on the secondary server:

$ORIGIN .
$TTL 3600   ; 1 hour
mydomain.ca     IN SOA  ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
            2011011013 ; serial
            600        ; refresh (10 minutes)
            600        ; retry (10 minutes)
            600        ; expire (10 minutes)
            600        ; minimum (10 minutes)
            )
        NS  ns1.mydomain.bc.ca.
        NS  ns2.mydomain.bc.ca.
        A   192.168.0.205
        MX  20 pop.mydomain.ca.
        TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
        AAAA    fc00::31
$ORIGIN mydomain.ca.

and the headers from the equivalent file on the primary:

$TTL 1d
@       IN      SOA     ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
                    2011082302 ; serial
                    15m        ; refresh after 15 minutes
                    1h         ; retry after 1 hour
                    1w         ; expire after 1 week
                    1d )       ; negative caching TTL of 1 day.

    IN      NS      ns1.mydomain.bc.ca.
    IN      NS      ns2.mydomain.bc.ca.
    IN MX   20      pop.mydomain.ca.


@               IN      A       192.168.0.205

;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; SPF TXT records
;;;;;;;;;;;;;;;;;;;;;;;;;;;

mydomain.ca. TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"

; this next bit is for the Sender Policy Framework, if it ever really matters.
pop             TXT     "v=spf1 a -all"
pop3            TXT     "v=spf1 a -all"
smtp            TXT     "v=spf1 a -all"
webmail         TXT     "v=spf1 a -all"
horde           TXT     "v=spf1 a -all"

Don't get me wrong, I'm mostly glad that this happened. However, I want to make sure that the reasons for it happening are sound - rather than there being a problem with our methods. I'd like to illustrate what's going on here with a graph:

_{(source: lightspeed.ca)}

The bright green line here shows the rate at which our server has rejected messages from IP addresses listed in realtime blacklists over the course of the last 12 months. Last May, we were rejecting an average of about 175 messages every 5 minutes, or 35 per minute, using this filter alone. It's pretty clear that since October, it's tapered off to a fraction of that - we're now averaging about 8 rejected messages per minute on this filter:

_{(source: lightspeed.ca)}

Since we see no corresponding rise in the number of messages being trapped by Spamassassin (the teal line largely drowned out at the bottom of the graph) or any other filters, I can come to one of two conclusions based on these statistics:

1) All of our filters have become ineffective.

or

2) Spammers aren't spamming as much as they used to.

Historically speaking, I find 1 to be much more likely than 2. However, from experience and customer complaints (rather, a lack thereof), 1 isn't true because we're not seeing much spam in our inboxes anymore. So what the heck is going on here? I can't fathom that spam has somehow become unprofitable. Have they moved on to softer targets? I'm seeing little to no spam on Facebook or Twitter or any HTTP forums. Have there been massive arrests, removing spammers from the wild, and discouraging new criminals from entering the ring?

Whatever the reason, it sounds to me like a hard-fought victory for someone out there. But I still want to make sure that it's either time to break out the champagne or start sharpening our swords.

Reverse DNS entries for IPv6 addresses are not working. Everything I've read on the subject says the following configuration should work:

In named.conf:

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.0.0.c.7.5.0.6.2.ip6.arpa" IN {
      type master;
      file "/var/lib/bind/ipv6reverse.hosts";
      allow-update { none; };
};

In /var/lib/bind/ipv6reverse.hosts:

$TTL 2d
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.0.0.c.7.5.0.6.2.IP6.ARPA.
@       IN      SOA     ns1.domain.ca.  hostmaster.domain.ca. (
            2011051104 ; serial
            1h      ; refresh
            1h      ; retry
            20d     ; expire
            2d      ; minimum
                            )
    IN      NS      ns1.domain.ca.
    IN      NS      ns2.domain.ca.

3.2.0.0.                IN      PTR     smtp.domain.ca.

When I try to do the reverse hostname lookup, I get the following error:

# host -6 2605:7c00:3::23 2605:7c00:3::11
Using domain server:
Name: 206.12.82.130
Address: ::ffff:206.12.82.130#53
Aliases: 

Host 3.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.0.0.c.7.5.0.6.2.ip6.arpa not found: 3(NXDOMAIN)

As far as I can tell, this should be found.

The syslog for bind has some rather cryptic entries that may be related:

May 12 10:28:57 www3 named[16018]:   validating @0xb253cf10: . SOA: no valid signature found
May 12 10:28:57 www3 named[16018]:   validating @0xb253cf10: . NSEC: no valid signature found
May 12 10:28:57 www3 named[16018]:   validating @0xb253cf10: org NSEC: no valid signature found

On our outgoing mail server, we've recently upgraded to Debian Squeeze (stable), and we're having some odd issues with TLS authentication. I suspect it may be an issue with OpenSSL, or maybe my tinkering with TLS after the fact to try to get things working again. However, I've gone over Exim's configuration with a fine-toothed comb and gone through the original configuration checklist for authentication through TLS, and some clients are still having problems.

The specific problem we're having is that Gnome Evolution, Mozilla Thunderbird, and Eudora refuse to authenticate with TLS. Outlook and Outlook Express appear to not have a problem, and that represents the bulk of the clients connecting to the server, but the other clients use SSL properly.

Thunderbird for example, produces the error message "An error occurred during a connection to :25. Peer's public key is invalid. (Error code: sec_error_bad_key)" when I try connecting with STARTTLS and Encrypted passwords. For the life of me, I can find no reference to the use of public keys in the Exim configuration, and OpenSSL doesn't use them anymore, instead including the public key as part of the private key, and using an intermediate CA certificate.

Other tests I've done:

I can use swaks to successfully authenticate:

$ swaks -s smtp.lightspeed.ca -p 25 --ehlo office.lightspeed.ca -au
<myuser> -ap <mypass> -t <myaddress> -f <myaddress>

=== Trying smtp.lightspeed.ca:25...
=== Connected to smtp.lightspeed.ca.
<-  220 ns2.lightspeed.ca ESMTP Exim 4.72 Thu, 31 Mar 2011 08:52:20 -0700
 -> EHLO office.lightspeed.ca
<-  250-ns2.lightspeed.ca Hello office.lightspeed.ca [65.110.29.154]
<-  250-SIZE 52428800
<-  250-PIPELINING
<-  250-AUTH PLAIN LOGIN
<-  250-STARTTLS
<-  250 HELP
 -> AUTH LOGIN
<-  334 <encrypted>
 -> <encrypted>
<-  334 <encrypted>
 -> <encrypted>
<-  235 Authentication succeeded
 -> MAIL FROM:<myaddress>
<-  250 OK
 -> RCPT TO:<myaddress>
<-  250 Accepted
 -> DATA
<-  354 Enter message, ending with "." on a line by itself
 -> Date: Thu, 31 Mar 2011 08:52:15 -0699
 -> To: <myaddress>
 -> From: <myaddress>
 -> Subject: test Thu, 31 Mar 2011 08:52:15 -0699
 -> X-Mailer: swaks v20100211.0 jetmore.org/john/code/swaks/
 ->
 -> This is a test mailing
 ->
 -> .
<-  250 OK id=1Q5KAW-0005Ep-TX
 -> QUIT
<-  221 ns2.lightspeed.ca closing connection
=== Connection closed with remote host.

As you can see here, the Exim server is offering STARTTLS and the PLAIN and LOGIN authentication methods. And the authentication works.

If I try the OpenSSL method, the connection fails:

$ openssl s_client -starttls smtp -crlf -connect smtp.lightspeed.ca:25
CONNECTED(00000003)
depth=0
/serialNumber=EGKZzrdW-EpuM5jI3QaVFSdRqKZSh4QW/C=CA/O=ns2.lightspeed.ca/OU=GT90526192/OU=See
www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated -
QuickSSL(R)/CN=ns2.lightspeed.ca
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0
/serialNumber=EGKZzrdW-EpuM5jI3QaVFSdRqKZSh4QW/C=CA/O=ns2.lightspeed.ca/OU=GT90526192/OU=See
www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated -
QuickSSL(R)/CN=ns2.lightspeed.ca
verify error:num=27:certificate not trusted
verify return:1
depth=0
/serialNumber=EGKZzrdW-EpuM5jI3QaVFSdRqKZSh4QW/C=CA/O=ns2.lightspeed.ca/OU=GT90526192/OU=See
www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated -
QuickSSL(R)/CN=ns2.lightspeed.ca
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0
s:/serialNumber=EGKZzrdW-EpuM5jI3QaVFSdRqKZSh4QW/C=CA/O=ns2.lightspeed.ca/OU=GT90526192/OU=See
www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated -
QuickSSL(R)/CN=ns2.lightspeed.ca
   i:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA
---
Server certificate
-----BEGIN CERTIFICATE-----
<certificate>
-----END CERTIFICATE-----
subject=/serialNumber=EGKZzrdW-EpuM5jI3QaVFSdRqKZSh4QW/C=CA/O=ns2.lightspeed.ca/OU=GT90526192/OU=See
www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated -
QuickSSL(R)/CN=ns2.lightspeed.ca
issuer=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA
---
Acceptable client certificate CA names
/C=BR/O=ICP-Brasil/OU=Instituto Nacional de Tecnologia da Informacao -
ITI/L=Brasilia/ST=DF/CN=Autoridade Certificadora Raiz Brasileira
/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing
Authority/[email protected]
/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
/O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing
Authority/[email protected]
/C=DE/ST=Hessen/L=Fulda/O=Debconf/CN=Debconf CA/[email protected]
/C=FR/ST=France/L=Paris/O=PM/SGDN/OU=DCSSI/CN=IGC/A/[email protected]
/C=FR/ST=France/L=Paris/O=PM/SGDN/OU=DCSSI/CN=IGC/A/[email protected]
/C=US/ST=DC/L=Washington/O=ABA.ECOM, INC./CN=ABA.ECOM Root
CA/[email protected]
/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External
CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Class 1 CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Public CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Qualified CA Root
/C=US/O=America Online Inc./CN=America Online Root Certification Authority 1
/C=US/O=America Online Inc./CN=America Online Root Certification Authority 2
/C=US/O=AOL Time Warner Inc./OU=America Online Inc./CN=AOL Time Warner
Root Certification Authority 1
/C=US/O=AOL Time Warner Inc./OU=America Online Inc./CN=AOL Time Warner
Root Certification Authority 2
/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
/O=beTRUSTed/OU=beTRUSTed Root CAs/CN=beTRUSTed Root CA-Baltimore
Implementation
/C=WW/O=beTRUSTed/CN=beTRUSTed Root CAs/CN=beTRUSTed Root CA
/O=beTRUSTed/OU=beTRUSTed Root CAs/CN=beTRUSTed Root CA - Entrust
Implementation
/O=beTRUSTed/OU=beTRUSTed Root CAs/CN=beTRUSTed Root CA - RSA Implementation
/C=EU/O=AC Camerfirma SA CIF
A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root
/C=EU/O=AC Camerfirma SA CIF
A82743287/OU=http://www.chambersign.org/CN=Global Chambersign Root
/C=FR/O=Certplus/CN=Class 2 Primary CA
/C=PL/O=Unizeto Sp. z o.o./CN=Certum CA
/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA
Certificate Services
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
Certification Authority
/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=Secure
Certificate Services
/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=Trusted
Certificate Services
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV
Root CA
/C=US/O=Digital Signature Trust Co./OU=DSTCA E1
/C=us/ST=Utah/L=Salt Lake City/O=Digital Signature Trust Co./OU=DSTCA
X1/CN=DST RootCA X1/[email protected]
/C=US/O=Digital Signature Trust Co./OU=DSTCA E2
/C=us/ST=Utah/L=Salt Lake City/O=Digital Signature Trust Co./OU=DSTCA
X2/CN=DST RootCA X2/[email protected]
/C=US/O=Digital Signature Trust/OU=DST ACES/CN=DST ACES CA X6
/O=Digital Signature Trust Co./CN=DST Root CA X3
/O=Entrust.net/OU=www.entrust.net/GCCA_CPS incorp. by ref. (limits
liab.)/OU=(c) 2000 Entrust.net Limited/CN=Entrust.net Client Certification
Authority
/O=Entrust.net/OU=www.entrust.net/SSL_CPS incorp. by ref. (limits
liab.)/OU=(c) 2000 Entrust.net Limited/CN=Entrust.net Secure Server
Certification Authority
/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification
Authority (2048)
/C=US/O=Entrust.net/OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref.
limits liab./OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Client
Certification Authority
/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits
liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server
Certification Authority
/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by
reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification
Authority
/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
/C=US/O=Equifax Secure Inc./CN=Equifax Secure eBusiness CA-1
/C=US/O=Equifax Secure/OU=Equifax Secure eBusiness CA-2
/C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1
/C=ES/L=C/ Muntaner 244 Barcelona/CN=Autoridad de Certificacion
Firmaprofesional CIF A62634068/[email protected]
/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2
/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
/C=US/O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
/C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA 2
/C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA
/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE
CyberTrust Global Root
/C=US/O=GTE Corporation/CN=GTE CyberTrust Root
/C=ES/ST=Barcelona/L=Barcelona/O=IPS Internet publishing Services
s.l./[email protected] C.I.F.  B-60929452/OU=IPS CA Chained CAs
Certification Authority/CN=IPS CA Chained CAs Certification
Authority/[email protected]
/C=ES/ST=Barcelona/L=Barcelona/O=IPS Internet publishing Services
s.l./[email protected] C.I.F.  B-60929452/OU=IPS CA CLASE1 Certification
Authority/CN=IPS CA CLASE1 Certification
Authority/[email protected]
/C=ES/ST=Barcelona/L=Barcelona/O=IPS Internet publishing Services
s.l./[email protected] C.I.F.  B-60929452/OU=IPS CA CLASE3 Certification
Authority/CN=IPS CA CLASE3 Certification
Authority/[email protected]
/C=ES/ST=Barcelona/L=Barcelona/O=IPS Internet publishing Services
s.l./[email protected] C.I.F.  B-60929452/OU=IPS CA CLASEA1 Certification
Authority/CN=IPS CA CLASEA1 Certification
Authority/[email protected]
/C=ES/ST=Barcelona/L=Barcelona/O=IPS Internet publishing Services
s.l./[email protected] C.I.F.  B-60929452/OU=IPS CA CLASEA3 Certification
Authority/CN=IPS CA CLASEA3 Certification
Authority/[email protected]
/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad
CA/OU=Certificaciones/CN=IPS SERVIDORES/[email protected]
/C=ES/ST=Barcelona/L=Barcelona/O=IPS Internet publishing Services
s.l./[email protected] C.I.F.  B-60929452/OU=IPS CA Timestamping
Certification Authority/CN=IPS CA Timestamping Certification
Authority/[email protected]
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi
Kft./OU=Tanusitvanykiadok/CN=NetLock Uzleti (Class B) Tanusitvanykiado
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi
Kft./OU=Tanusitvanykiadok/CN=NetLock Expressz (Class C) Tanusitvanykiado
/C=HU/ST=Hungary/L=Budapest/O=NetLock Halozatbiztonsagi
Kft./OU=Tanusitvanykiadok/CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi
Kft./OU=Tanusitvanykiadok/CN=NetLock Minositett Kozjegyzoi (Class QA)
Tanusitvanykiado/[email protected]
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 3
/C=BM/O=QuoVadis Limited/OU=Root Certification Authority/CN=QuoVadis Root
Certification Authority
/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 3 Policy
Validation
Authority/CN=http://www.valicert.com//[email protected]
/O=RSA Security Inc/OU=RSA Security 1024 V3
/O=RSA Security Inc/OU=RSA Security 2048 V3
/C=US/O=SecureTrust Corporation/CN=Secure Global CA
/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
/C=JP/O=SECOM Trust.net/OU=Security Communication RootCA1
/C=FI/O=Sonera/CN=Sonera Class1 CA
/C=FI/O=Sonera/CN=Sonera Class2 CA
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA
/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification
Authority
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom
Certification Authority
/C=IL/ST=Israel/L=Eilat/O=StartCom Ltd./OU=CA Authority Dep./CN=Free SSL
Certification Authority/[email protected]
/C=ch/O=Swisscom/OU=Digital Certificate Services/CN=Swisscom Root CA 1
/C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2
/C=CH/O=SwissSign AG/CN=SwissSign Platinum CA - G2
/C=CH/O=SwissSign AG/CN=SwissSign Silver CA - G2
/C=TW/O=Government Root Certification Authority
/C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks
GmbH/OU=TC TrustCenter Class 2 CA/[email protected]
/C=DE/ST=Hamburg/L=Hamburg/O=TC TrustCenter for Security in Data Networks
GmbH/OU=TC TrustCenter Class 3 CA/[email protected]
/C=DK/O=TDC Internet/OU=TDC Internet Root CA
/C=DK/O=TDC/CN=TDC OCES CA
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification
Services Division/CN=Thawte Personal Basic
CA/[email protected]
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification
Services Division/CN=Thawte Personal Freemail
CA/[email protected]
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification
Services Division/CN=Thawte Personal Premium
CA/[email protected]
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification
Services Division/CN=Thawte Premium Server
CA/[email protected]
/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006
thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification
Services Division/CN=Thawte Server CA/[email protected]
/C=ZA/ST=Western Cape/L=Durbanville/O=Thawte/OU=Thawte
Certification/CN=Thawte Timestamping CA
/CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet
Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1/C=TR/L=ANKARA/O=(c) 2005
T\xC3\x9CRKTRUST Bilgi \xC4\xB0leti\xC5\x9Fim ve Bili\xC5\x9Fim
G\xC3\xBCvenli\xC4\x9Fi Hizmetleri A.\xC5\x9E.
/CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet
Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1/C=TR/L=Ankara/O=T\xC3\x9CRKTRUST
Bilgi \xC4\xB0leti\xC5\x9Fim ve Bili\xC5\x9Fim G\xC3\xBCvenli\xC4\x9Fi
Hizmetleri A.\xC5\x9E. (c) Kas\xC4\xB1m 2005
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Client Authentication
and Email
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Network Applications
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Object
/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1 Policy
Validation
Authority/CN=http://www.valicert.com//[email protected]
/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy
Validation
Authority/CN=http://www.valicert.com//[email protected]
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority -
G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust
Network
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 1 Public Primary
Certification Authority - G3
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority -
G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust
Network
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 2 Public Primary
Certification Authority - G3
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority -
G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust
Network
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G3
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary
Certification Authority - G5
/C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority -
G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust
Network
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign,
Inc. - For authorized use only/CN=VeriSign Class 4 Public Primary
Certification Authority - G3
/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority
/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)00/CN=VeriSign Time Stamping Authority CA
/C=US/O=VISA/OU=Visa International Service Association/CN=Visa eCommerce Root
/C=US/O=VISA/OU=Visa International Service Association/CN=GP Root 2
/C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo
Root Certificate Authority
/C=US/OU=www.xrampsecurity.com/O=XRamp Security Services Inc/CN=XRamp
Global Certification Authority
/C=BM/O=QuoVadis Limited/OU=Root Certification Authority/CN=QuoVadis Root
Certification Authority
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- CA Klasa 1
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- CA Klasa 2
/C=PL/O=TP Internet Sp. z o.o./CN=CC Signet - CA Klasa
3/serialNumber=Numer wpisu: 4
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- OCSP Klasa 2
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- OCSP Klasa 3
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- PCA Klasa 2
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- PCA Klasa 3
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- RootCA
/C=PL/O=TP Internet Sp. z o.o./OU=Centrum Certyfikacji Signet/CN=CC Signet
- TSA Klasa 1
/C=US/ST=Indiana/L=Indianapolis/O=Software in the Public
Interest/OU=hostmaster/CN=Certification
Authority/[email protected]
/C=US/ST=Indiana/L=Indianapolis/O=Software in the Public
Interest/OU=hostmaster/CN=Certificate
Authority/[email protected]
/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom
Root CA 2
---
SSL handshake has read 22345 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-DSS-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-DSS-AES256-SHA
    Session-ID:
510F41918AD4A65D88A43BC6ED66651F98842EBBF7975295F6808342F9AE7067
    Session-ID-ctx:
    Master-Key:
53D1F9E30DC867D662BC2F859B79319294F67D7EB8753237A181DBE41C84B69EF00721F63BFC8938613EB7B694D8C53F
    Key-Arg   : None
    Start Time: 1301593832
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
250 HELP
quit
221 ns2.lightspeed.ca closing connection
closed

PLEASE NOTE: I'm not interested in making this into a flame war! I understand that many people have strongly-held beliefs about this subject, in no small part because they've put a lot of effort into their firewalling solutions, and also because they've been indoctrinated to believe in their necessity.

However, I'm looking for answers from people who are experts in security. I believe that this is an important question, and the answer will benefit more than just myself and the company I work for. I've been running our server network for several years without a compromise, without any firewalling at all. None of the security compromises that we have had could have been prevented with a firewall.

I guess I've been working here too long, because when I say "servers", I always mean "services offered to the public", not "secret internal billing databases". As such, any rules we would have in any firewalls would have to allow access to the whole Internet. Also, our public-access servers are all in a dedicated datacenter separate from our office.

Someone else asked a similar question, and my answer was voted into negative numbers. This leads me to believe that either the people voting it down didn't really understand my answer, or I don't understand security enough to be doing what I'm currently doing.

This is my approach to server security:

1. Follow my operating system's security guidelines before connecting my server to the Internet.

2. Use TCP wrappers to restrict access to SSH (and other management services) to a small number of IP addresses.

3. Monitor the state of this server with Munin. And fix the egregious security problems inherent to Munin-node in its default configuration.

4. Nmap my new server (also before connecting my server to the Internet). If I were to firewall this server, this should be the exact set of ports incoming connections should be restricted to.

5. Install the server in the server room and give it a public IP address.

6. Keep the system secure by using my operating system's security updates feature.

My philosophy (and the basis of the question) is that strong host-based security removes the necessity of a firewall. The overall security philosophy says that strong host-based security is still required even if you have a firewall (see security guidelines). The reason for this is that a firewall that forwards public services to a server enables an attacker just as much as no firewall at all. It is the service itself that is vulnerable, and since offering that service to the entire Internet is a requirement of its operation, restricting access to it is not the point.

If there are ports available on the server that do not need to be accessed by the whole Internet, then that software needed to be shut down in step 1, and was verified by step 4. Should an attacker successfully break into the server through vulnerable software and open a port themselves, the attacker can (and do) just as easily defeat any firewall by making an outbound connection on a random port instead. The point of security isn't to defend yourself after a successful attack - that's already proven to be impossible - it's to keep the attackers out in the first place.

It's been suggested that there are other security considerations besides open ports - but to me that just sounds like defending one's faith. Any operating system/TCP stack vulnerabilities should be equally vulnerable whether or not a firewall exists - based on the fact that ports are being forwarded directly to that operating system/TCP stack. Likewise, running your firewall on the server itself as opposed to having it on the router (or worse, in both places) seems to be adding unnecessary layers of complexity. I understand the philosophy "security comes in layers", but there comes a point where it's like building a roof by stacking X number of layers of plywood on top of each other and then drilling a hole through all of them. Another layer of plywood isn't going to stop the leaks through that hole you're making on purpose.

To be honest, the only way I see a firewall being any use for servers is if it has dynamic rules preventing all connections to all servers from known attackers - like the RBLs for spam (which coincidentally, is pretty much what our mail server does). Unfortunately, I can't find any firewalls that do that. The next best thing is an IDS server, but that assumes that the attacker doesn't attack your real servers first, and that attackers bother to probe your entire network before attacking. Besides, these have been known to produce large numbers of false positives.

We have two Asterisk servers. One is a warm failover (ie, we have to make it work manually should the first one fail, but it gets regular configuration updates so it's always ready to be made live) and the other is the live server. They both have Digium Wildcard TE405P's in them, and the hardware and software is otherwise identical, but the last time we needed to use the failover server, things went poorly when it was plugged into the PRI line. Now, we're upgrading the failover box to Asterisk 1.6 and pressing it into service.

I really need a way of thoroughly testing (including testing under load) the TE405 hardware and configuration before we need it. I can't just set up and tear down a PRI line for testing for an hour or a day, and the expense of the line prevents us from having a complete backup. Likewise, just switching the cable from one server to the next is also highly disruptive.

This is a Canonical Question about IPv6 and NAT

Related:

• How does IPv6 subnetting work and how does it differ from IPv4 subnetting?
• How can I 'dip my toes' into dynamic IPv6 network addressing?
• IPv6 without nat but what about an isp change?

So our ISP has set up IPv6 recently, and I've been studying what the transition should entail before jumping into the fray.

I've noticed three very important issues:

1. Our office NAT router (an old Linksys BEFSR41) does not support IPv6. Nor does any newer router, AFAICT. The book I'm reading about IPv6 tells me that it makes NAT "unnecessary" anyway.

2. If we're supposed to just get rid of this router and plug everything directly to the Internet, I start to panic. There's no way in hell I'll put our billing database (With lots of credit card information!) on the internet for everyone to see. Even if I were to propose setting up Windows' firewall on it to allow only 6 addresses to have any access to it at all, I still break out in a cold sweat. I don't trust Windows, Windows' firewall, or the network at large enough to even be remotely comfortable with that.

3. There's a few old hardware devices (ie, printers) that have absolutely no IPv6 capability at all. And likely a laundry list of security issues that date back to around 1998. And likely no way to actually patch them in any way. And no funding for new printers.

I hear that IPv6 and IPSEC are supposed to make all this secure somehow, but without physically separated networks that make these devices invisible to the Internet, I really can't see how. I can likewise really see how any defences I create will be overrun in short order. I've been running servers on the Internet for years now and I'm quite familiar with the sort of things necessary to secure those, but putting something Private on the network like our billing database has always been completely out of the question.

What should I be replacing NAT with, if we don't have physically separate networks?

So, for the third time in about two weeks (maybe less), one of our customers has had their password compromised, and a spammer was sending mail with their username and password using our webmail. As a result, our outgoing mail server has been listed at Spamhaus, and a lot of our outgoing mail is being rejected.

I can't think of any way to prevent this from happening (although now our webmail server is using Sendmail instead of SMTP, but that just limits the scope of the problem), yet the big ISPs never seem to have a problem like this.

I'm a sysadmin for a smallish ISP, and we have our own mail server (qmail, of all the godforsaken things) that serves mail for about 300 domains and 5000 users in total. It's running out of disk space, and we have to replace the hardware to make it bigger.

So, I built a new mail server based on Exim, which uses Dovecot for POP/IMAP, and is modified to use MySQL for user authentication both on the Dovecot end and the Exim end (when receiving mail to verify the existence of an account before accepting mail for delivery). This was all based on the HOWTO at struction.de, and after getting all the kinks worked out, everything was going swimmingly, until I got to the part where users need to be able to administer their own accounts, or at the very least the domain hosting customers who like to create/delete accounts on a frequent basis.

Vexim is basically a dead project, so I avoided that. Someone recommended Postfixadmin.

Now, while it almost works, it's missing a big, fat feature that breaks the setup I have: user-defined spam scores that are stored in the MySQL database in the user's account. Just as importantly, it seems that the entire design of the system needs to be built around Postfixadmin, instead of putting Postfixadmin on top. I've just designed the entire system backwards.

I've been working on this project forever, and now I just want to chuck it all and buy some software that makes mail servers work properly the way we need them. I'm also not about to spend the next month or six building a new version of Postfixadmin (with my design and programming skills, a bad one at that) or just even modifying the current one.

Is there a way out of this situation?

I'm just installing a new mail server, using Exim 4 and the sa-exim Debian package. Part of the configuration uses Teergrubing (or tarpitting), and while it sounds like a great idea in theory, I also understand that a lot of spammers these days make it pointless. They either get around this problem by using huge botnets (which have other advantages for the spammer) or they just end the SMTP transaction immediately after sending the DATA portion of the message.

But my question is really "is this of enough use to actually foil most spammers?" I know that there's still lots of stupid spammers out there who use unsophisticated methods to send their junk. I'm just wondering whether tarpitting is worth it or not.

So, we bought some hardware for one of our aging servers.

And, for whatever reason that utterly baffles me, the driver files do not exist on the included CD. Instead, they exist in floppy disk image files on the CD, which first must be written to a floppy disk, from which you then copy the files. Unfortunately, every floppy disk we have is corrupt due to age. So I need a way to extract the files from that image.

Please note that the reason we don't just replace the server entirely (which is definitely due) is because that is not in the budget right now.

EDIT: the disk image is in UFS format apparently. Windows programs will not work!