No, ASPnix shared services are not PCI compliant. Our web hosting packages are setup from the start to be as secure as possible, however, certain aspects of the server such as legacy non-secure FTP ports cannot be closed or disabled.

This limitation exists to maintain compatibility with older client software and workflows that still depend on traditional FTP. For any site that accepts, processes, or stores credit card data, the open insecure ports place the entire shared environment outside PCI DSS compliance. The standard demands that all unnecessary services and clear-text protocols be eliminated; shared servers cannot selectively disable them without breaking other customers' operations.

#PCI DSS Requirements for Secure Networks

PCI DSS defines technical and operational standards for protecting cardholder data. Among its core mandates are building secure networks, eliminating unnecessary default services, encrypting data in transit, and maintaining ongoing vulnerability management. Any open port that permits unencrypted communication, especially one that can carry authentication credentials, violates these rules. In a shared hosting model the infrastructure is multi-tenant, so individual customers cannot alter kernel-level or service configurations that would otherwise allow full compliance.

#ASPnix Shared Hosting Security Configuration

Servers are hardened with current patches, restrictive firewall rules, and least-privilege access wherever possible. The design prioritizes both security and stability across hundreds of concurrent sites. The single unavoidable exception is the retention of legacy FTP ports to support customers who rely on older publishing tools or automated scripts. Because these ports must remain listening, the server cannot pass a PCI audit even though day-to-day web traffic can still be fully encrypted.

#The Specific Impact of Legacy FTP

Plain FTP transmits usernames, passwords, and file contents without encryption. Packet sniffers on the same network segment or compromised routers can capture this data. PCI DSS explicitly prohibits such exposure for any system in scope. Since the FTP service cannot be disabled at the host level, every site on the server is considered to share the same non-compliant environment. The practical result is that direct credit-card processing on shared hosting requires additional controls outside the hosting layer or, preferably, complete removal of card data from your infrastructure.

#Enforcing HTTPS Redirects

All production traffic must use encrypted transport. Add the following URL rewrite rule to your site's web.config file to automatically redirect HTTP requests to HTTPS. This is a required baseline for any site that could handle sensitive information.

xml 
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Redirect to HTTPS" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="^OFF$" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

#Secure File Transfer Alternatives

  • Configure all publishing tools and deployment scripts to use FTPS (FTP over explicit TLS) or SFTP instead of plain FTP.
  • Disable any client-side option that falls back to unencrypted FTP.
  • Avoid storing credentials in plain-text batch files or source control.

#Practical Recommendations

  • Offload payment processing to a third-party gateway so cardholder data never touches your server.
  • Perform regular application security reviews and keep all frameworks, libraries, and CMS components patched.
  • Enable detailed logging and review it for anomalous access patterns.
  • Use strong, unique passwords and IP-restricted administrative interfaces.

The practical takeaway is that shared hosting meets the security needs of most informational and lightly interactive sites, but direct card processing requires either a dedicated environment under your full control or, far more commonly, an architecture that removes cardholder data from your scope entirely. Evaluate your payment flow, implement the HTTPS redirect shown above, switch to encrypted file transfer, and consider tokenization services so PCI compliance burden stays with specialized providers rather than your hosting account.