The server's host firewall is ufw, and its rule 1 already allows SSH from anywhere. Type the command that blocks every connection from the attacking address and takes effect ahead of that allow rule.

sudo ufw insert 1 deny from 203.0.113.9

Which control would have stopped this attack from getting in?

Multifactor authentication on every account

Put the team's actions in the order of the incident response process.

1. Write the playbook, list the team's contacts, and set up offline backups; 2. Notice the ransom note and the endpoint agent's alert; 3. Confirm the incident, identify the ransomware strain, and find every affected system; 4. Isolate the workstation and segment the network so the malware cannot spread; 5. Remove the malware and close the hole it came in through; 6. Restore from clean backups and monitor closely for the attacker's return; 7. Write the report and change the controls and plans that fell short

The incident is confirmed. What do you do first with the infected workstation?

Isolate it from the network and leave it powered on

Pick every item that belongs in the lessons-learned report.

What happened, in order, with times; What worked in the response; What did not work or was slow; The controls and plans to change

Match each job to the PKI piece that does it.

Issues and signs certificates: Certificate authority (CA); Verifies the applicant's identity before anything is issued: Registration authority (RA); A list of revoked certificate serial numbers that clients download: Certificate revocation list (CRL); Answers a real-time question about whether one certificate is revoked: OCSP; The file the server sends to request a certificate: Certificate signing request (CSR); The key that must never leave the server: Private key

Pick every check a browser makes on the portal's certificate before it trusts it.

The certificate has not expired; The certificate chains to a trusted root; The name on the certificate matches the site's hostname; The certificate has not been revoked

CompTIA Security+ SY0-701

CompTIA Security+ SY0-701 PBQ Practice

Performance-based questions ask you to do the task, not pick the letter. The real exam opens with a handful. Here are 3 of the course's 10, with every task answered and explained: Security+ PBQs, SY0-701 performance-based questions, Security+ PBQ practice.

Find the attack in the log

A clinic's Linux file server, files01, accepts SSH logins from staff and from a backup host. The security analyst pulls the authentication log for the early hours of the morning after an alert. A copy of the attacker's script, found later, held one common password and a list of staff usernames.

Oct 14 02:12:55 files01 sshd[3102]: Accepted publickey for backup from 10.0.4.15 port 40112 ssh2
Oct 14 02:13:07 files01 sshd[3120]: Failed password for adavis from 203.0.113.9 port 51022 ssh2
Oct 14 02:13:07 files01 sshd[3121]: Failed password for bchen from 203.0.113.9 port 51024 ssh2
Oct 14 02:13:07 files01 sshd[3122]: Failed password for cortiz from 203.0.113.9 port 51026 ssh2
Oct 14 02:13:07 files01 sshd[3123]: Failed password for dpatel from 203.0.113.9 port 51028 ssh2
Oct 14 02:13:08 files01 sshd[3124]: Failed password for ewong from 203.0.113.9 port 51030 ssh2
Oct 14 02:13:08 files01 sshd[3125]: Failed password for fmoore from 203.0.113.9 port 51032 ssh2
Oct 14 02:13:08 files01 sshd[3126]: Failed password for gsingh from 203.0.113.9 port 51034 ssh2
Oct 14 02:13:08 files01 sshd[3127]: Failed password for hnguyen from 203.0.113.9 port 51036 ssh2
Oct 14 02:13:09 files01 sshd[3128]: Accepted password for jlopez from 203.0.113.9 port 51040 ssh2
Oct 14 02:15:01 files01 CRON[3140]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 14 02:21:40 files01 sshd[3155]: Accepted password for mlee from 10.0.4.22 port 40230 ssh2

Pick every log line that is part of the attack.
1. Oct 14 02:12:55 files01 sshd[3102]: Accepted publickey for backup from 10.0.4.15 port 40112 ssh2
2. Oct 14 02:13:07 files01 sshd[3120]: Failed password for adavis from 203.0.113.9 port 51022 ssh2
3. Oct 14 02:13:07 files01 sshd[3121]: Failed password for bchen from 203.0.113.9 port 51024 ssh2
4. Oct 14 02:13:07 files01 sshd[3122]: Failed password for cortiz from 203.0.113.9 port 51026 ssh2
5. Oct 14 02:13:07 files01 sshd[3123]: Failed password for dpatel from 203.0.113.9 port 51028 ssh2
6. Oct 14 02:13:08 files01 sshd[3124]: Failed password for ewong from 203.0.113.9 port 51030 ssh2
7. Oct 14 02:13:08 files01 sshd[3125]: Failed password for fmoore from 203.0.113.9 port 51032 ssh2
8. Oct 14 02:13:08 files01 sshd[3126]: Failed password for gsingh from 203.0.113.9 port 51034 ssh2
9. Oct 14 02:13:08 files01 sshd[3127]: Failed password for hnguyen from 203.0.113.9 port 51036 ssh2
10. Oct 14 02:13:09 files01 sshd[3128]: Accepted password for jlopez from 203.0.113.9 port 51040 ssh2
11. Oct 14 02:15:01 files01 CRON[3140]: pam_unix(cron:session): session opened for user root by (uid=0)
12. Oct 14 02:21:40 files01 sshd[3155]: Accepted password for mlee from 10.0.4.22 port 40230 ssh2
Expected: Oct 14 02:13:07 files01 sshd[3120]: Failed password for adavis from 203.0.113.9 port 51022 ssh2; Oct 14 02:13:07 files01 sshd[3121]: Failed password for bchen from 203.0.113.9 port 51024 ssh2; Oct 14 02:13:07 files01 sshd[3122]: Failed password for cortiz from 203.0.113.9 port 51026 ssh2; Oct 14 02:13:07 files01 sshd[3123]: Failed password for dpatel from 203.0.113.9 port 51028 ssh2; Oct 14 02:13:08 files01 sshd[3124]: Failed password for ewong from 203.0.113.9 port 51030 ssh2; Oct 14 02:13:08 files01 sshd[3125]: Failed password for fmoore from 203.0.113.9 port 51032 ssh2; Oct 14 02:13:08 files01 sshd[3126]: Failed password for gsingh from 203.0.113.9 port 51034 ssh2; Oct 14 02:13:08 files01 sshd[3127]: Failed password for hnguyen from 203.0.113.9 port 51036 ssh2; Oct 14 02:13:09 files01 sshd[3128]: Accepted password for jlopez from 203.0.113.9 port 51040 ssh2
The attack is the eight failed logins for eight different usernames from 203.0.113.9 inside two seconds, plus the accepted login for jlopez from the same address a second later, which is the attacker getting in. The publickey login from the backup host, the scheduled cron session, and mlee's login from an internal address are normal activity, so they are not part of it.
Which attack does the log show?
1. Password spraying
2. Brute force against one account
3. Credential stuffing with pairs leaked from another site
4. Credential replay of a captured session token
Expected: Password spraying
Password spraying tries one common password against many accounts, and its tell is many accounts with a single failed login in the same window, exactly what this log shows. Brute force hammers one account with many guesses, credential stuffing replays username and password pairs leaked from another site rather than one password, and credential replay reuses a captured hash or token instead of guessing.
The server's host firewall is ufw, and its rule 1 already allows SSH from anywhere. Type the command that blocks every connection from the attacking address and takes effect ahead of that allow rule.
Expected: sudo ufw insert 1 deny from 203.0.113.9
ufw and iptables check rules in order and the first match wins, so a deny appended below the SSH allow rule would never be reached for SSH, the very traffic the attacker uses; ufw insert 1 deny from 203.0.113.9 puts the block at the top. The same rule written directly in iptables, iptables -I INPUT -s 203.0.113.9 -j DROP, inserts at the top too and is accepted; blocking addresses is part of containment. ufw prepend deny from 203.0.113.9 also inserts at the top and is accepted.
Which control would have stopped this attack from getting in?
1. Multifactor authentication on every account
2. Account lockout after five failed attempts
3. A longer password expiry period
4. Encrypting the authentication log
Expected: Multifactor authentication on every account
MFA stops spraying, because a guessed password alone no longer opens the account. Account lockout does not, because spraying makes only one attempt per account and stays under the threshold; password expiry and encrypting the log do nothing to stop the guess.

From the lesson Log Data and Data Sources. See also Password Attacks and Indicators of Compromise.

A ransomware note appears on a workstation

A front-desk workstation at a clinic shows a ransom note, and the endpoint agent raises an alert at the same moment. The response team works the incident from its playbook. Months earlier the team wrote that playbook, listed its contacts, and set up offline backups.

Put the team's actions in the order of the incident response process.
Items: Write the playbook, list the team's contacts, and set up offline backups; Notice the ransom note and the endpoint agent's alert; Confirm the incident, identify the ransomware strain, and find every affected system; Isolate the workstation and segment the network so the malware cannot spread; Remove the malware and close the hole it came in through; Restore from clean backups and monitor closely for the attacker's return; Write the report and change the controls and plans that fell short
Expected: 1. Write the playbook, list the team's contacts, and set up offline backups; 2. Notice the ransom note and the endpoint agent's alert; 3. Confirm the incident, identify the ransomware strain, and find every affected system; 4. Isolate the workstation and segment the network so the malware cannot spread; 5. Remove the malware and close the hole it came in through; 6. Restore from clean backups and monitor closely for the attacker's return; 7. Write the report and change the controls and plans that fell short
The order is preparation, detection, analysis, containment, eradication, recovery, and lessons learned. The playbook and backups are preparation, the note and alert are detection, confirming and scoping is analysis, isolating is containment, removing the malware is eradication, restoring from clean sources is recovery, and the report closes the case and feeds preparation.
The incident is confirmed. What do you do first with the infected workstation?
1. Isolate it from the network and leave it powered on
2. Power it off immediately
3. Restore it from last night's backup
4. Reimage it and return it to the front desk
Expected: Isolate it from the network and leave it powered on
After an incident is confirmed the next step is always containment, so the host comes off the network to stop the spread. Powering it off destroys the contents of memory, volatile evidence that is captured before a system is shut down; restoring or reimaging now skips analysis and eradication and would put the host back before the cause is removed.
Pick every item that belongs in the lessons-learned report.
1. What happened, in order, with times
2. What worked in the response
3. What did not work or was slow
4. The controls and plans to change
5. The administrator passwords used during recovery
Expected: What happened, in order, with times; What worked in the response; What did not work or was slow; The controls and plans to change
Lessons learned reviews what happened, what worked, what did not, and which controls and plans to change, then feeds that back into preparation. Passwords are credentials, not findings, and never belong in a report.

From the lesson The Incident Response Process.

Who does what in PKI

A clinic is putting a certificate on its patient portal for the first time. The new administrator has a list of the PKI pieces involved and needs to know what each one does.

Match each job to the PKI piece that does it.
Items: Issues and signs certificates; Verifies the applicant's identity before anything is issued; A list of revoked certificate serial numbers that clients download; Answers a real-time question about whether one certificate is revoked; The file the server sends to request a certificate; The key that must never leave the server. Slots: Certificate authority (CA); Registration authority (RA); Certificate revocation list (CRL); OCSP; Certificate signing request (CSR); Private key; Public key
Expected: Issues and signs certificates: Certificate authority (CA); Verifies the applicant's identity before anything is issued: Registration authority (RA); A list of revoked certificate serial numbers that clients download: Certificate revocation list (CRL); Answers a real-time question about whether one certificate is revoked: OCSP; The file the server sends to request a certificate: Certificate signing request (CSR); The key that must never leave the server: Private key
The CA issues and signs certificates, the RA verifies the requester before the CA issues anything, the CRL is a periodically downloaded list of revoked serial numbers, OCSP answers one certificate's status in real time, and the CSR carries the public key and identity details to the CA. The private key is generated on the server and never leaves it; the public key is the half that goes into the CSR and the certificate, so it is the slot left over.
A patient's browser must send a secret that only the portal server can read. Which key encrypts it?
1. The server's public key
2. The server's private key
3. The browser's private key
4. The certificate authority's private key
Expected: The server's public key
To encrypt something only the recipient can read, use the recipient's public key; only the matching private key, which stays on the server, can decrypt. Encrypting with a private key is how a signature proves who sent something, not how a secret is kept.
Pick every check a browser makes on the portal's certificate before it trusts it.
1. The certificate has not expired
2. The certificate chains to a trusted root
3. The name on the certificate matches the site's hostname
4. The certificate has not been revoked
5. The certificate file is under a certain size
Expected: The certificate has not expired; The certificate chains to a trusted root; The name on the certificate matches the site's hostname; The certificate has not been revoked
A browser warns when a certificate is expired, does not chain to a trusted root, has been revoked (checked through a CRL or OCSP), or names a different host; that is why wildcard and subject alternative name certificates exist, to cover more names. File size plays no part in trust.

From the lesson PKI and Certificates.

Questions people ask

How many PBQs are on the CompTIA Security+ SY0-701 exam?

CompTIA does not publish the count. Expect a handful at the start of the exam, each taking longer than a multiple-choice question.

Can you skip a PBQ and come back to it?

Yes. Flag it, answer the multiple-choice questions, and return with the time you have left.

Are PBQs weighted more than other questions?

CompTIA does not disclose its weighting. Treat each task inside a PBQ as a question you can get right or wrong.

How does SecPlus Academy practice PBQs?

The course has 10 interactive PBQs: drag items into order, match terms, pick lines in a log, fill a configuration, type a command. Every task is graded and explained, and the official-format test opens with 3 of them.