By contract we are required to collect all system logs and store them for a period of time to be used for forensic investigations or other troubleshooting events (SIEM collection). I need to know if there is a file (such as syslog.conf) that I can edit with the Log Forwarder DNS (or IP). I also need to know the syntax. (I'm running OneFS 188.8.131.52)
Any information would be greatly appreciated.
Solved! Go to Solution.
Thanks for the link, it is very helpfu... one question - I added the syslog IP by using the isi_log_server add command and then I did a isi_for_array -sq 'killall -HUP syslogd'. Is there a command to restart the syslog daemon or does it restart on its own?
Yes, it will be restarted by the system.
Syslogging to a server by hostname will work as well as by IP address.
In either case usually both client and server should
be forward and reversely resolvable (by DNS or /etc/hosts).
We use Nessus to scan the syslogs, but Nessus does not use a password to authenticate, rather it uses an authorized key. Someone on my team has given me the instructions to create this key, but this being somewhat of a striped down version of FreeBSD, I don't feel confident that the commands I was given will not actually create the key. My question is, can I create a key for Nessus to use to authenticate to OneFS via SSH? If so, what are the commands to create the keys. I'm running OneFS 184.108.40.206.
Here are the commands I was given (striped down to protect identity):
chmod 700 /home/nessusid/.ssh
chown nessusid:root /home/nessusid/.ssh
echo "ssh-rsa some generated key here== firstname.lastname@example.org " > /home/nessusid/.ssh/authorized_keys
chmod 640 /home/nessusid/.ssh/authorized_keys
chown nessusid:root /home/nessusid/.ssh/authorized_keys
Any assistance would be greatly apprecited.
that's apparently all standard steps one will also find in many how-tos etc.
"nessusid" must be a recognized (e.g. local) user on the Isilon
with home dir as listed and login enabled.
Beware of dynamic IP pools on the Isilon -- use static IP addresses
with Nessus and ssh only. Nessus, or better ssh, will choke when
an IP moves to another node; not only will an existing connection
break, but attempts for new connections will fail and complain
about a "changed host key". Unless one can tell Nessus to
not check the host key (as in
ssh -o StrictHostKeychecking=no).