Recently, I realized from the scan reports that the Windows credential set created and set to Foundstone to enhance the scan capabilities as McAfee recommends was not working properly.
Under the Windows Host > Windows Access > Access Report Summary By System section of the report, I had no Administration or Authentication Access (empty circle) on my Windows targets. The scan was configured to use the Windows credential set. Also, that account was included in admin group on the target server.
I am not sure if I should be able to see Foundstone account on the Event Viewer > Security Logs of the target Windows server after a scan but the thing is that I checked just in case and I didn't see anything...Neither successful nor failed login attempt through that account...
I know that Foundstone should be a stand-alone box, and therefore, not part of our domain (or at least this is what I was told). Does anyone think that this is the problem why Foundstone cannot use that account while scanning a target? If not and explaining why not, any other idea around the possible cause for that is more than welcome!!
If I was seeing a failed login attempt on any log I would just change the password on both ends and I would try again because I would assume that a mistype error would be the cause of that issue. But now, I have no clue...
Any help is greatly appreciated!
If I do not receive anything, i guess I will raise a support request ticket.
I usually enable CSV reporting for the scans. The CSV output includes "Authenticated Hosts" which:
1. Lists windows hosts if there are any issues (else lists nothing)
2. Lists *nix host auth successes AND fails
I did generate the report for the scan I was checking enabling CSV as yousuggested.
I had 1 XML file (named as csvmanifest.xml) and 2 excel files (named as network_assets.csv and vulnerabilities.csv) produced. None of them had any output named as "Authenticated Hosts"... That means that the scan performed successfully a credentialled scan as it was configured to?
On the pdf report, I see that No Access was achieved under the Windows Host > Windows Access > Access Report Summary By System section...
Just to clarify here that the above example was for a windows credentialled scan.
The auth fails should be logged in the auth hosts csv..
Here are some things you can check
Overall I think this is worth submitting to support, as it may potentially be a bug. They will probably do a remote session and ask to see the logs and your config.
Most of the support reps you get when you contact support via phone are awesome-Chuck Schott, Robert Hunt, Jack hess(Props) all rock!
Yes, Windows Vulns is ticked. Everything is ticked. I never remove anything. I know that FS is smart enough to perform only the applicable scripts on every occasion. At least, this is what I have seen so far from my reports and this is what I was told by McAfee in the past.
In Service Discovery, I always set it to All!
It is up to date to the latest version of 6.8 and has the latest features (OS Fingerprints, Language, etc)
I will try to check those daily logs as I think they will be my last hope of proving that my credential sets configured in the past do not work.
Continuing from my last reply:
OS identification (Windows) uses credentials: Yes
Total successful Windows OS SMB connections using individual credentials: 0
Total successful Windows OS SMB connections using domain credentials: 0
Total successful Windows OS SMB connections using default credentials: 0
CModuleSubscan::Start() called by Windows Host Assessment
2 windows hosts in scan starting for subscan 0, batch 0.
1 credential sets provided for scanning.
Server1 (x.x.x.x): Warning (80070035): Processing for this host
[3 more times of the same error message]
Server2 (x.x.x.x): Warning (80070035): Processing for this host
[3 more times of the same error message]
GetCredentialSet: ID = 3 (0)
So, based on that log, I think I have the proof I wanted that the credential set does not work.
Please correct me if I am wrong!
The tool FSDiag gives you a fairly simple way to try an authentication. I got it from McAfee but don't recall the URL. Check the Knowledgebase.
Double-check the service port access. Do you have a guinea pig target you can test against? Take a look at its windows firewall settings. Try turning off the windows firewall and repeating your scan (or using FSDiag from the scan engine) -- does this change your result? If so, turn the fireall back on, check its settings again, and put Wireshark (tcpdump) on the target and have it listen for connections from the scan engine.
Message was edited by: jldunn on 10/31/11 6:22:27 PM CDTMessage was edited by: jldunn on 10/31/11 6:36:41 PM CDT
I double-checked whether windows firewall was on but as I thought it is off.
So, that is not possible to have caused the issue.
Now, I am suspecting that epo909 is right since we get the same error messages and since we both have had our Foundstones (him 7.0, me 6.8) updated to their latest patches...
This is the exact same problem I having since the upgrade for version 7.0. I am pretty sure this is a bug.
We tested fsdiag, created multiple accounts with all kinds of passwords, always with the same results, the password is somewhat corrupted in someway. One thing is clear, after the upgrade credentials are no longer stored in the sameway as in 6.8: the table scancomponents.credentials no longer stores passwordhash collumn for new credentials, only the XML version of the credentials is present. Maybe this is working as intended...
Anyway i have an SR open for the last 3 weeks without solution. Maybe I need to pay for platinum in order to get decent support.
I've had similar issues with support if I submitted via the online portal. Give them a call and present them with your SR and you usually will get a tech to help..if that doesn't work, escalate to the support managers at email@example.com
Chuckled out loud to the platinum support comment.on 11/1/11 9:16:12 AM EDT