Monthly Archives: February 2009

Making VisualSVN PCI compliant

One of AIS’s customers is currently performing PCI Compliance Audits.  One of the core tenants of PCI compliance is the hardening of all external facing corporate e-assets.

During the course of the auditing, the SVN port was noted as a security risk (I.E. the port failed the audit due to weak encryption).  While the practice of an external facing SVN port in a PCI compliant organization is a point of debate, this customer had legitimate corporate need to continue supporting the SVN environment.

Kudos for the solution do not fall to AIS as the solution was divined by the customer’s internal PCI guru.  In the interest of knowledge sharing, the customer has granted AIS the right to publish the solution here.

VisualSVN Server is a very robust, easy to administer, and easier to install SVN server based on the Apache server.  While making an Apache install PCI compliant is a well documented process, translating those steps to VisualSVN server proved to be a little more difficult.


  • Disable TraceRoute
  • Enable SSL3 and TSL1
  • Disable weak encryption


  1. Locate the configuration directory (Conf) located in the VisualSVN server install directory
  2. Add the following lines into the httpd-customer.conf file

TraceEnable off
SSLProtocol -ALL +SSLv3 +TLSv1

dasBlog “Mail to Weblog” IPV6 setup

One of my clients recently installed dasblog.  While the overall installation was exceptionally painless, the “Mail to Weblog” feature refused to work within the customers environment.  After much hair pulling, we were able to track the issue down to an IPV6 issue within the POP3 handling of the Mail to Weblog feature.

Target Environment
The customer’s environment consisted of an edge server running IIS7 and the exchange POP3 client on a single Hyper-V image.  The Exchange server was a standard install on a Hyper-V image running standalone on bare iron.

The Errors
Whenever dasBlog would activate, the log file would contain an error line of Pop3ServerError: System.Net.Sockets.SocketException: An address incompatible with the requested protocol was used fe80::8d30:bd51:31d9:60ac%15:110.

Root Cause
This particular client is IPV4 centric…which confused us in that the error contained an IPV6 address.  Upon closer examination, all IPV6 protocols were active within exchange and the firewall was open for port 110 on both IPV4 and IPV6 protocols so the IPV6 address should not have been blocked.  This was not making sense.  To confound us even more, we were referencing the actual server by name (In this case which returned an IPV4 address from the DNS.

OK.. so where was the IPV6 address coming from and why was it causing POP3 problems?

After a bit of network sleuthing, it appeared the Hyper-V Virtual Machine bus was translating the IP into a localhost call.  The localhost call within Hyper-V then translated the IP address into an IPV6 address from the lmhosts file.

We removed the IPV6 address from the server’s hosts file.  To remove the IPV6 localhost IP, perform the following actions:

Locate the hosts file at

Comment out the ::1 IPV6 address.  Your entries should look like this when completed       localhost
#::1             localhost

Future Research?
We did not have the time to research why the call to the POP3 service was failing under IPV6.  Our guess is the Lesnikowski routines may not be IPV6 compliant or there maybe an ASP.NET trust issue.  With the Web Mail feature now working under IPV4, we declared victory and headed for coffee!

Full Error Text

code    650    message    <span>Pop3ServerError:<br/>System.Net.Sockets.SocketException: An address incompatible with the requested protocol was used fe80::8d30:bd51:31d9:60ac%15:110
&lt;br&gt;   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
&lt;br&gt;   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
&lt;br&gt;   at Lesnikowski.Pawel.Mail.Pop3.Pop3.Connect()
&lt;br&gt;   at newtelligence.DasBlog.Web.Services.MailToWeblog.Run()<br/> while processing .</span>