Are they false ?

[bitsnpcs]

[member=5916]trinidad[/member] I do not feel able to cope with the links at this time. I do not think it will be possible for me to do this level of Linux discussed on them either. It is above beginner level.
I will try to work through the links and tasks at a future time, when I rebuild some confidence in using computers.

I am not confident there will be any success at all for me in trying that, but I will try at some stage.

Even though it is highly unlikely to be solved, I will say it as solved as there is nothing else that can be done. There is no marking option etc.

[valtam]

Whenever I look at my reports from rkhunter and chkrootkit I simply Google them. They always turn out to be false positives and are usually widely known/discussed.

[bitsnpcs]

I will do this.

[trinidad]

@bitnpcs  Yes!!! There is so much information on the web about Linux that you can often just copy and paste the code to a search box, especially if it concerns security. Linux is a vast global community.

TC

[bitsnpcs]

Thanks, I'll post back once completed

[bitsnpcs]

So far I am still manually doing the checks from Ubuntu security page.

For some reason there are auth.log and auth.log.1, the same occurs for many other logs, I am unsure if this is normal, I have not found info on that yet.

One thing I noticed in the both auth.log is login at 06:25:01 hours, every day for same duration since the 8th November (my oldest log date), it takes root/su, using a default in the distro, Linuxquestions says this is used as default for "Samba and Apache to run services in distros", then afterwards it removes its session.
I am unsure why or which services it is running at this time each day ?

It can also be used to backdoor distros, they advice using /dev/null instead to prevent that possibility.
I am not sure on that.

These are the only unknowns in auth.log/s.
Syslog is clear.

I will continue on with the processes and report back.

[bitsnpcs]

Still on the first of security links.

I have solved the above one, in that it is something internal in distro, and it is not trying access externally. Its common behaviour in many Linux distros.

ufw logs clear.

netstat

Code:

sudo watch netstat -anlp

shows no foreign connection or any to /bin/sh or /bin/su

trace backs running clear currently. ( I was allowed to connect LL, for this and can show them montoring and ufw results)

rkhunter, I have discovered it is false positive, something to do with package manager, Debian say its been fixed.

rkhunter wiki has this for updates which I had done before using it and since then.

Code:

sudo rkhunter --propupd

On ubuntu forums notice the help

Code:

sudo rkhunter - h

from this I found a way to update the database

Code:

sudo rkhunter --update

Neither are on the rkhunter wiki it is a different method and commands.

This found and updated the list of false positives in rkhunter that propupd didn't find.

I then edited the rkhunter.conf file as admin saved and used

Code:

sudo rkhunter -C

As per the conf to update rkhunter with these changes.

It now runs with no results detected, only everything Okay, not found, or clear.

I have updated LL and notice that both Perl and Pulse have many updates it may help in chkrootkit which I'll start on tomorrow.

Update -
.bash_profile, .bash_rc, .profile, /etc/profile - all clear of other uses

Update 2 -
samba activity noted above, this is a cron job to back up samba password each day.
no cron jobs set at root
cron.d empty/no issues found
cron.daily / all clean no issues found
cron.hourly, cron.monthly empty/no issues found
cron.weekly all clean no issues found
All checking manually.

Code:

printenv

no backdoors, hooks escalated priviledges found , all clean.

/etc/ld.so.conf.d
no malicious linkages found

/etc/rc.local clean
/etc/rc0 thru 6 all files checked all clean
/etc/init.d clean
/etc/network all files clean
/etc/NetworkManager all files clean 

[JmaCWQ]

For some reason there are auth.log and auth.log.1, the same occurs for many other logs, I am unsure if this is normal, I have not found info on that yet.

That is normal, just the logs being rotated auto by the system, the .1's are the older logs.

[bitsnpcs]

[quote author=bitsnpcs link=topic=4797.msg36646#msg36646 date=1510784410]
For some reason there are auth.log and auth.log.1, the same occurs for many other logs, I am unsure if this is normal, I have not found info on that yet.

That is normal, just the logs being rotated auto by the system, the .1's are the older logs.
[/quote]

Thank You for answering and explaining it to me

[bitsnpcs]

I have done searching it says chkrootkit Ebury is a known false positive, relate to -G

To test for Ebury older versions using shared memory segments I ran

Code:

sudo find /lib* -type f -name libns2.so

Clean

To test for Ebury newer version using Unix domain sockets I ran

Code:

sudo netstat -nap | grep "@/proc/udevd"

Clean

To prevent false positive due to added -G it uses -e Gg in this command, where I found an explanation of the command on Ubuntu threads.

Code:

ssh -G 2>&1 | grep -e illegal -e unknown -e Gg > /dev/null && echo "System clean" || echo "System infected"

The result was -