RedHatDemos/SecurityDemos

Audit Lab issues

Closed this issue · 25 comments

simo5 commented
  • Lab 6.1 the password for auditlab user is not specified (turns out it is the usual r3dh4t1!) but it is requested to login from the workstation countrary to instructions.

-Lab 6.2 through 6.3.4
there is no success critieria shown, most labs ask you to perform actions but do not tell you how to validate they actually did anything useful, 6.3.2 does not give examples of what people should see no way to tell if it worked or not.
Note: everything seemed to work except perhaps the excercises about the project_tps_report.txt file:

$ chmod 0664 ~/project_tps_report.txt
chmod: cannot access '/home/auditlab/project_tps_report.txt': No such file or directory

Lab 6.3.5 is the only one that seem to show how the result of an action can be actually used, implicitly also validating that the action was performed correctly.

lkerner commented

@stevegrubb and @rgbriggs please take a look at this issue

jvymazal commented

At section 6.2.1 there is step 3 to edit audit config, however the configuration file present in snapshot is already updated per the commands so the editing (and subsequent reload/restart of daemon) is quite needless.

jvymazal commented

regarding the "no file" error from tps_report, perhaps preceding vi command should instruct to use :wq instead of :q! to exit? (that way everything works)

  • 👍1
ggbecker commented 
* Lab 6.1 the password for auditlab user is not specified (turns out it is the usual r3dh4t1!) but it is requested to login from the workstation countrary to instructions.

+1 on auditlab user asking for password

ggbecker commented

Section 6.2.1:
Fix the_audit.example.com_ string to the _audit.example.com_

ggbecker commented

At section 6.2.1 there is step 3 to edit audit config, however the configuration file present in snapshot is already updated per the commands so the editing (and subsequent reload/restart of daemon) is quite needless.

It looks like this is actually the default configuration for auditd.conf.

ggbecker commented

The title says Red Hat Enterprise Linux 7.5 even though the lab is run entirely in RHEL8. Suggest to remove the specific version 7.5.

As I understood Summit is mainly promoting RHEL8 whenever possible.

rgbriggs commented
stevegrubb commented

Pull request #121 was opened to fix some of the things pointed out here.

rgbriggs commented

Pull request #121 was opened to fix some of the things pointed out here.

Why did you drop the change from "killall ..." to "service audit reload" in the last of those three patches that went into the PR? (I had most of these fixes queued... I'll diff and see if any remain.)

stevegrubb commented

Pull request #121 was opened to fix some of the things pointed out here.

Why did you drop the change from "killall ..." to "service audit reload" in the last of those three patches that went into the PR? (I had most of these fixes queued... I'll diff and see if any remain.)

Because using the service command is the way that we tell everyone to use the audit system.

rgbriggs commented

@stevegrubb When you say (lines 26-27): "If done correctly, you should not need to enter a password." What is the correct way? Should there be no password on root and auditlab, or should it use the pre-installed ssh key? I'm now assuming you were talking about getting in to the bastion workstation, but still need a password to get into audit.example.com.

stevegrubb commented

@stevegrubb When you say (lines 26-27): "If done correctly, you should not need to enter a password." What is the correct way? Should there be no password on root and auditlab, or should it use the pre-installed ssh key?

Paul wrote that - not me. :-) It also seemed to work for me so I didn't change it. I think it uses the pre-installed key.

rgbriggs commented
rgbriggs commented
stevegrubb commented

On 2019-04-15 14:36, Steve Grubb wrote: > > Why did you drop the change from "killall ..." to "service audit reload" in the last of those three patches that went into the PR? (I had most of these fixes queued... I'll diff and see if any remain.) Because using the service command is the way that we tell everyone to use the audit system.
Sorry, I don't follow. The last patch that ended up in the pull request does not have the switch to "service audit reload"

I guess that was missed by mistake. Service is preferable.

dahaic commented

These are mostly nitpics I found in latest trial:

  • is there a reason for RHEL7.5 ? If yes, this should be explained. If not, we can say "but it does not matter, audit is the same as on RHEL8.0" or something. Basically acknowledging it's using not up-to-date system
  • shouldn't service command be replaced by systemctl?
  • shouldn't grub2-mkconfig be replaced by grubby?
rgbriggs commented
stevegrubb commented

For audit, service is a required command. We cannot move to systemctl. You will find systemctl is blocked for many audit tasks.

As for grub2-mkconfig vs grubby...I've always used grub2-mkconfig since it comes with the bootloader. They ought to work together.

lkerner commented

@stevegrubb and @rgbriggs : is this issue now resolved?

stevegrubb commented

@stevegrubb and @rgbriggs : is this issue now resolved?

Looks like it says 8.0 now. I suppose that could be changed to simply 8.

lkerner commented

@stevegrubb , not sure what you mean by 8.0 vs 8. Is this still an issue that needs to remain open for fixes or can I close this issue?

stevegrubb commented

I think the concern mentioned above is that the content mentions 8.0 which is version specific. When 8.1 ships, will this content still be correct? By deleting the ".0" it makes it generic for all releases of RHEL 8.

stevegrubb commented

@lkerner, I submitted a pull request. I think issue can be closed when that is merged.

lkerner commented

Thanks @stevegrubb . Closing issue based on pull request #194 by @stevegrubb .