Archive

Posts Tagged ‘security’

resolved – auditd STDERR: Error deleting rule Error sending enable request (Operation not permitted)

September 19th, 2014 No comments

Today when I try to restart auditd, the following error message prompted:

[2014-09-18T19:26:41+00:00] ERROR: service[auditd] (cookbook-devops-kernelaudit::default line 14) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /sbin/service auditd restart ----
STDOUT: Stopping auditd: [  OK  ]
Starting auditd: [FAILED]
STDERR: Error deleting rule (Operation not permitted)
Error sending enable request (Operation not permitted)
---- End output of /sbin/service auditd restart ----
Ran /sbin/service auditd restart returned 1

After some reading of manpage auditd, I realized that when audit "enabled" was set to 2(locked), any attempt to change the configuration in this mode will be audited and denied. And that maybe the reason of "STDERR: Error deleting rule (Operation not permitted)", "Error sending enable request (Operation not permitted)". Here's from man page of auditctl:

-e [0..2] Set enabled flag. When 0 is passed, this can be used to temporarily disable auditing. When 1 is passed as an argument, it will enable auditing. To lock the audit configuration so that it can't be changed, pass a 2 as the argument. Locking the configuration is intended to be the last command in audit.rules for anyone wishing this feature to be active. Any attempt to change the configuration in this mode will be audited and denied. The configuration can only be changed by rebooting the machine.

You can run auditctl -s to check the current setting:

[root@centos-doxer ~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=3154 rate_limit=0 backlog_limit=320 lost=0 backlog=0

And you can run auditctl -e <0|1|2> to change this attribute on the fly, or you can add -e <0|1|2> in /etc/audit/audit.rules. Please note after you modify this, a reboot is a must to make this into effect.

403 CoachingSessionExceeded – McAfee the culprit

December 18th, 2012 No comments

Today I tried access one website within company's network which was very important to me. But the site loaded incompletely and so was not usable.

As always, company network is somehow restricted, for example, only output port 80 and 443 are enabled in my company's network. As many companies do, McAfee software is used to restrict internal employees surfing the internet. So I firstly thought McAfee was the culprit.

As I'm using chrome browser, so I press F12 to open the developer tools. On "Network" tab(you may need ctrl+F5 to forcely refresh the website), I found the following error status:

Then I opened that url source in a new tab, and the following page occured:

So everything sorted! I clicked the button "click here if you have read ....", and then went back to the site, refresh, and later everything was ok!

McAfee Solidcore agent and McAfee agent management

June 14th, 2012 No comments

The File Integrity Monitoring (FIM) agents on Solaris and Redhat servers is made up of 2 components, a Solidcore Agent and a McAfee Agent.

  • The Solidcore agent is the element that performs the file monitoring. It runs as a kernel module and needs a kernel restart ( reboot ) to disable it.
  • The McAfee agent is responsible for communication back to a central McAfee Enterprise Policy Orchestrator ( EPO ) server. It runs as a service (cma) that can be stopped with minimal impact to the running server. The software can also easily be removed or reinstalled without and impact.

With both Solidocre and a Mcafee agent running, the centralised ePO will control the 'policy' of files to be monitored on the host. this can be overridden in the OS if need be using commands in the Additional Tasks section below.

Status check
To query the status of solidcore on a server ( as root ) run
# sadmin status

To query the policy a server is running with, the local config needs to be 'unlocked' To do this, 'recover' the config and query the policy.
# sadmin recover #( password required, available from the epo administrator )
# sadmin mon list
# sadmin lockdown

Restart
The McAfee agent has an associated service 'cma' which can be stopped and restarted while the server is running.
- Stopping the service
service cma stop

- Starting the service
service cma start

The Solidcore agent has an associated service 'scsrvc'
- Stopping the service
service scsrvc stop

- Starting the service
service scsrvc start

Note:
The solidcore agent runs as part of the UNIX kernel. Stopping the 'scsrvc' service doesn't fully disable the solidcore software.
To do this :
- Open the local configuration for editing
sadmin recover #{ password needed from the ePO Administrator )

- Set the agent to be disabled at next reboot
sadmin disable

- Close the local configuration for edits
sadmin lockdown

'REBOOT'

when the server comes back the agent will be disabled. This can be confiremd by running :
sadmin status

resolved pca 403 forbidden server error on solaris

April 28th, 2012 No comments

Today when I was patching a solaris 5.9 host, error occurred with error message as follows after entering MOS(my oracle support) user/password:

122300 56 < 63 RS- 22 SunOS 5.9: Kernel Patch
Looking for 122300-63 (2/52)
Trying Oracle
Please enter My Oracle Support Account User: [email protected]
Please enter My Oracle Support Account Password:
Trying https://getupdates.oracle.com/ (zip) (1/1)
Failed (Error 403: Forbidden)
Failed (patch not found)

Then I went to http://support.oracle.com and searched patch 122300-63. The patching info page says I'll need "Vintage Solaris download access/privilege" to download this patch, but obviously none of my CSI had this Vintage Solaris download access/privilege.

As this account issue may take some time to resolve, so I choose cluster patch or you may say patchset method to do the patching on solaris 9. Here's the steps we need to do cluster patching on solaris 5.9:

  • 1.download latest cluster patching package that satisfies your host here http://wesunsolve.net/bundles
  • 2.unzip the package and have a read of Recommended.README file comes with the package
  • 3.ensure there's enough free space on /, /var(better >4Gb)
  • 4. Now run ./install_patchset or ./install_cluster(you can add -nosave parameter if  you have limited free space on /, /var, but you will not be able to backout individual patches if the need arises)
  • 5.For more installation messages refer to the installation logfile:    /var/sadm/install_data/<patchset-name>_log
  • 6.reboot your machine to make all patches applied to your host.

NB:

If you have raid 1(mirror) on your solaris system, you can try first patch submirror and then apply to all system if server runs well after booting up. You can refer to the following for more infomation:

http://www.doxer.org/solaris-patching-trick-%E2%80%93-first-patch-submirror-then-sync-between-mirrors/