Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter jkzsjk

    (@jkzsjk)

    Hi @shanedelierrr,

    Any updates on the matter so far?

    Thread Starter jkzsjk

    (@jkzsjk)

    Hi @shanedelierrr,

    Apologies for the late response as well, I have already reached out as per instructed.

    Looking forward to your/SolidWP’s support, thank you & appreciate it!

    Thread Starter jkzsjk

    (@jkzsjk)

    Hi @shanedelierrr,

    Any updates so far?

    Thread Starter jkzsjk

    (@jkzsjk)

    Hi @shanedelierrr,

    Thanks again for the feedback and explanation especially, appreciate it!

    So, what’s happening is that the failed scans are running via Cron, and during those scans, Solid Security picks up the host IP because of how it’s resolved on the server and returns an error (which is the expected behavior) because it thinks it’s a private site.

    Yes, this is exactly what’s happening to me so far. If it’s triggered manually (via WordPress admin’s security dashboard), it would work fine with the public URL but failing with private IP when triggered via Cron.

    The scanner will use get_home_url to retrieve the URL to scan. You may be experiencing an error if your home URL is set dynamically based on the request URL. When running Cron, often times there is no site URL, and so the IP address of the machine is being provided instead. You’ll need to update your server configuration to ensure get_home_url returns valid values in all runtimes.

    Would defining WP_HOME & WP_SITEURL beforehand help? I noticed they weren’t defined in my environment so far, so I did it subsequently but the results are still the same. The only other difference it made was it fixed wp itsec site-scanner scan for me. The CLI triggered scan would fail with https://127.0.0.1 as URL prior to this. When Cron site scan happens, when get_home_url is triggered, does it replace/define WP_HOME & WP_SITEURL for me?

    Moving forward, can you please check into how your site’s URL is being configured on your server? Please also check and let us know how Kubernetes handles DNS resolutions because it could be causing inconsistencies in how URLs are resolved on your site.

    Besides the 2 aforementioned variables, are there any others I should check? In my WordPress General settings page, I could see WordPress Address (URL) & Site Address (URL) are defined correctly with my public facing URL though. Would appreciate it if you could share what other Kubernetes components I should check as well. E.g. pod container’s /etc/hosts file/DNS pods logs or configuration & etc.

    Thread Starter jkzsjk

    (@jkzsjk)

    Hi @shanedelierrr,

    Would appreciate your assistance on the matter, many thanks in advance.

    Thread Starter jkzsjk

    (@jkzsjk)

    Hi, @shanedelierrr

    Sorry for replying late as this item was deprioritised on my end previously.

    Can you please confirm if the Site Scan ever had a successful scan on your site before?

    Yes.

    Can you please confirm if the Site Scan ever had a successful scan on your site before? If so, it started having issues after enabling basic auth, but when you tried removing basic auth it did not help, correct?

    Yes & yes, but sometimes (even with Basic Auth still enabled) it might still be successful.

    Is your site publicly accessible? If so, can you please double-check that the Licensed URL in WP Admin > Settings > SolidWP Licensing is correct? Please try also to re-license the plugin after saving the correct Licensed URL.

    Yes, publicly accessible but we’re not licensed. We’re using the free iThemes security plugin.

    If the issue persists, please try to whitelist the Site Scanner’s IP address via NGiNX Ingress to bypass the basic auth.

    Will consider doing this, thank you! Though It’s worth noting that all successful attempts we’ve had so far, had never needed this whitelisting to be done.

    Additionally, here’s more context. Usually when it’s successful (do note that the difference in URL, i.e. url =>), the logs would look like this:

    id               => 3674473
    module => site-scanner
    type => critical-issue
    code => vulnerable-software
    timestamp => 2024-08-15 15:09:37
    init_timestamp => 2024-08-15 15:09:36
    remote_ip => 204.246.166.146
    user_id => [empty string]
    url => https://www.<REDACTED>.com/
    memory_current => 8295960
    memory_peak => 8497448
    data => Array
    results => Array
    url => https://www.<REDACTED>.com
    version => 1.0
    entries => Array
    blacklist => Array
    0 => Array
    report_details => https://transparencyreport.google.com/safe-browsing/search?url=www.<REDACTED>.com
    status => clean
    vendor => Array
    slug => google
    label => Google Safe Browsing
    vulnerabilities => Array
    0 => Array
    type => wordpress
    issues => Array
    0 => Array
    title => WordPress core < 6.5.5 - Contributor+ Path Traversal (Windows Only) vulnerability
    description => Contributor+ Path Traversal (Windows Only)

    When it’s failing (10.1.0.1 is a sample of internal IP):

    id               => 3674444
    module => site-scanner
    type => warning
    code => scan-failure-client-error
    timestamp => 2024-08-15 03:09:34
    init_timestamp => 2024-08-15 03:09:32
    remote_ip => 10.9.68.67
    user_id => [empty string]
    url => https://10.1.0.1:8443/wp-login.php
    memory_current => 7858472
    memory_peak => 7895080
    data => Array
    results => Object WP_Error
    errors => Array
    site_verification_failed.private_host => Array
    0 => Unable to determine if the scan target is allowed: Scan target is not publicly accessible.
    error_data => Array
    site_verification_failed.private_host => Array
    url => https://10.1.0.1:8443
    cached => [boolean] false

    My next few questions are:

    • Am aware that free and paying are able to do site scan, but is paying necessary for specific support to resolve this issue?
    • How is the URL get decided or set when scan is triggered? With the same WordPress instance, we would occasionally see it in the form of public URL or internal private IP otherwise.
    • Is it correct to assume the site scanning will always be done successfully via public internet? Or it will fail otherwise?

    Thanks for reading & looking forward to your further assistance, appreciate it!

    Thread Starter jkzsjk

    (@jkzsjk)

    Hi @shanedelierrr,

    Thanks for the reply.

    Was this site recently moved from a staging site to a live one?

    No.

    Which plugin version are you using, the Solid Security Pro version or the Basic version?

    iThemes Security Pro, version 7.1.3 currently.

    Also, which basic authentication are you using?

    As mentioned, my WordPress is hosted on AWS EKS, behind NGiNX Ingress. The basic authentication is enabled via Ingress object with the following annotations:

    nginx.ingress.kubernetes.io/auth-secret: <namespace>/<secret-name>
    nginx.ingress.kubernetes.io/auth-secret-type: auth-file
    nginx.ingress.kubernetes.io/auth-type: basic

    Can Solid Security scan your site if the basic authentication is disabled?

    We did try this to check, the answer is no as well. Whenever it fails, we’d notice that the Security dashboard logs would show the following:

    • Host: It’s a private IP, beginning with 10 (e.g. 10.0.0.1). Upon further checking, this IP belongs to cluster’s worker node’s IP.
    • URL: The URL would be https://10.0.33.21:8443/wp-login.php. This IP belongs to the WordPress deployment pod within the cluster.


    Not sure what else we could be missing, looking forward to your next reply. Appreciate the help!

Viewing 7 replies - 1 through 7 (of 7 total)