[SOLVED] Installing an application correctly

Ztcoracat · 09-02-2012, 09:35 PM

After a few members gave me wise counsel I installed

Code:

rkhunter

I was a little confused after the last output of the terminal.
Besides Xiphos this is the first application that I have installed and want to be sure I didn't wreck my new OS.

Did I execute this correctly?
And does this mean that their have been 130 rootkits discovered? (I certainly hope not!)

Code:

ztcoracat@mock:~$ su
Password: 
root@mock:/home/ztcoracat# dpkg-reconfigure rkhunter
root@mock:/home/ztcoracat# rkhunter --propupd
[ Rootkit Hunter version 1.3.6 ]
File updated: searched for 162 files, found 130
root@mock:/home/ztcoracat#

abrinister · 09-02-2012, 10:09 PM

Code:

File updated: searched for 162 files, found 130

I think it's just telling you that it only found 130 files when it was looking for 162.

Alex Brinister

towheedm · 09-02-2012, 11:54 PM

After reading this post, I decided to give rkhunter a try.

Quote:

Originally Posted by Ztcoracat

root@mock:/home/ztcoracat# dpkg-reconfigure rkhunter[/CODE]

Why reconfigure the rkhunter package?

Quote:

Originally Posted by Ztcoracat

root@mock:/home/ztcoracat# rkhunter --propupd
[ Rootkit Hunter version 1.3.6 ]
File updated: searched for 162 files, found 130
root@mock:/home/ztcoracat# [/CODE]

This option causes rkhunter to update the file properties in it's database. It is looking for 162 files but only found 130. This simple means that you either don'y have some of the files installed, or rkhunter could not find them.

From the man pages:

Quote:

--bindir <directory>...
This option tells rkhunter which directories to look in to find
the various commands it requires. The default is the current
PATH environment variable, and the typical command directories
of /bin, /usr/bin, /sbin and so on.

So either the commands are not installed or they do not exist in the directories pointed to by your PATH env var.

After installing rkhunter, I immediately ran a check:

Code:

rkhunter -c

It displayed a few warnings.

I then did an update:

Code:

rkhunter --update
[ Rootkit Hunter version 1.3.6 ]

Checking rkhunter data files...
  Checking file mirrors.dat                                  [ No update ]
  Checking file programs_bad.dat                             [ Updated ]
  Checking file backdoorports.dat                            [ Updated ]
  Checking file suspscan.dat                                 [ No update ]
  Checking file i18n/cn                                      [ No update ]
  Checking file i18n/de                                      [ No update ]
  Checking file i18n/en                                      [ No update ]
  Checking file i18n/zh                                      [ No update ]
  Checking file i18n/zh.utf8                                 [ No update ]

.It updated a few of it's files.

I again ran a check with the same results prior to the update.

I decided to do a properties update and then another check:

Code:

rkhunter --propupd  && rkhunter -c

This resulted in 117 warnings in the file properties check, compared to zero prior to the propupd.

A look at the /var/log/rkhunter.log file showed that the propupd saved the checksum using a different HASH that was used for the commands.

After running the check with the --pkgmgr option:

Code:

rkhunter -c --pkgmgr DPKG

The errors again reverted to zero.

And:

Code:

rkhunter --propupd --pkgmgr DPKG

updated the files properties with the correct HASH.

Please read the manpages and log file very carefully before jumping to conclusions. For example, when I do a check, I get this in the summary:

Code:

Rootkit checks...
    Rootkits checked : 245
    Possible rootkits: 2
    Rootkit names    : Xzibit Rootkit, Xzibit Rootkit

Of course, you can immediately assume that I had two possible rootkits on my system. But a quick look at the logs revealed:

Code:

[00:49:10] Warning: Checking for possible rootkit strings    [ Warning ]
[00:49:10]          Found string 'hdparm' in file '/etc/init.d/hdparm'. Possible
 rootkit: Xzibit Rootkit
[00:49:10]          Found string 'hdparm' in file '/etc/init.d/.depend.boot'. Po
ssible rootkit: Xzibit Rootkit

Which of course is normal on my system so I consider this a possible false positive.

The long and short of it all is that you must read the manpages and logfile before coming to any conclusions.

After this I installed the unhidepackage and it's showing 3 hidden processes. Now I'll look into this.

Ztcoracat · 09-03-2012, 01:21 AM

Towheedm:

You asked why I reconfigured; I was only doing what a member posted and I followed his/her instructions in order to install this rkhunter. I was warned in advance prior to installing this application that it could produce a false positive to the ie

Xzibit

I was not aware of this properties update:

Code:

rkhunter --propupd && rkhunter -c

I was advised to run:

Code:

rkhunter -c

But only when I want to scan my system.
You are more skilled than I and I am still learning.

I installed rkhunter because I again was given counsel to do so.
I still have other packages I'd like to install that are not on my system.

Code:

Bastille, lynis, chkrootkit, tripwire, tiger, clamav,psad and others

I only know how to get into the man pages by typing" man man
I do not understand how to find other information within the man pages (I'm still learning)

I appreciate you explaining thing and am on my way to learn from the man pages as you have advised;
Thank You

towheedm · 09-03-2012, 08:21 AM

Quote:

Originally Posted by Ztcoracat

I was not aware of this properties update:

Code:

rkhunter --propupd && rkhunter -c

I was advised to run:

Code:

rkhunter -c

The properties update option is --propupd. The check option is -c or --check. The && between the two command:

Code:

rkhunter --propupd && rkhunter -c

Tells BASH to run rkhunter with the propupd option and if that command is successful, then run rkhunter with the check option.

If you're using Squeeze, then use the propupd option together with the pkgmgr option:

Code:

rkhunter --propupd --pkgmgr DPKG

This tells rkhunter to use the hash that was used by the dpkg package manager when updating the file properties.

Quote:

Originally Posted by Ztcoracat

I only know how to get into the man pages by typing" man man
I do not understand how to find other information within the man pages (I'm still learning)

The manual pages or manpages contains most of the help information on a particular program/application/utility and it's respective command-line options.

The command man man gives you the manpages for the man command, which tells you how to use man.

Most external apps will have a manpage. Entering man <command> brings up the man page for that command. For example:

Code:

man ls    # Show the manpage for the ls command
man rkhunter    # Show the manpage for rkhunter.

At the end of some manpages, you may see references to other manpages. For example, at the end of the fstab manpage, you'll see:

Code:

SEE ALSO
       getmntent(3), mount(8), swapon(8), fs(5), nfs(5)

To access those manpages, you enter:

Code:

man <n> <command>    # Where <n> is the number in brackets

Some commands may have it's full documentation via the Texinfo manual. For example, at the end of the manpage for the ls command:

Code:

SEE ALSO
       The full documentation for ls is maintained as a  Texinfo  manual.   If
       the  info and ls programs are properly installed at your site, the com‐
       mand

              info coreutils 'ls invocation'

       should give you access to the complete manual.

To access the info pages for ls, you would use:

Code:

info coreutils 'ls invocation'

Quote:

Originally Posted by Ztcoracat

You are more skilled than I and I am still learning.

I doubt that I'm more skilled than you, and believe me, I'm still learning also.

Ztcoracat · 09-04-2012, 02:59 PM

Towheedm:

I understand now how properties update was made.
The first 4 letters in properties and the up in the word update made sense when I read it.
I often wondered how commands were written out and made.
Thank You showing me that by example.

As far as the man pages I'm still a little confused.
If I understand your example:

Code:

<man> <n> <command> # where <n> is the # in brackets

Does the '<n>' mean name of application or etc.?
And by # please give me a example I'm thinking something like this but I'm probably wrong:

Code:

man gimp update <2.6> ?

I've learned something good today from you, thanks; that's one less thing I'm in the dark about-

towheedm · 09-04-2012, 11:14 PM

Quote:

Originally Posted by Ztcoracat

I often wondered how commands were written out and made.
Thank You showing me that by example.

While that may be true sometimes, but do not take it literally as some options may not necessarily be a true representation of their meaning. Always check the help or manpages for the use of any particular options.

Quote:

Originally Posted by Ztcoracat

As far as the man pages I'm still a little confused.
If I understand your example:

Code:

<man> <n> <command> # where <n> is the # in brackets

Does the '<n>' mean name of application or etc.?
And by # please give me a example I'm thinking something like this but I'm probably wrong:

Code:

man gimp update <2.6> ?

No, that is certainly not what I meant in my previous post.

Let's take a look at the manpages for the man command:

Code:

man man

From the Synopsis, the general command for man is:

Code:

man [section] page

And from the Description:

Code:

DESCRIPTION
       man is the system's manual pager. Each page argument given  to  man  is
       normally  the  name of a program, utility or function.  The manual page
       associated with each of these arguments is then found and displayed.  A
       section,  if  provided, will direct man to look only in that section of
       the manual.  The default action is to search in all  of  the  available
       sections, following a pre-defined order and to show only the first page
       found, even if page exists in several sections.

From this, we see that the [section] option to man is optional, and if not specified man will find and display the first page found.

Now, there may be several pages for man in different sections. For example, there may be a manpage for man in section 1 and also also one in section 7. So how do we display the specific page?

That's where the [sectopn] option comes in. If specified, it tells man in what section to look for the manpages were are interested in.

Therefore, to display the manpages for man from section 7, we enter:

Code:

man 7 man

You will notice that this manpage is different.

Now, if you go to the end of manpages for man from section 7, you will see:

Code:

SEE ALSO
       apropos(1),  groff(1),  man(1),  man2html(1), groff_mdoc(7), whatis(1),
       groff_man(7), groff_www(7), man-pages(7), mdoc(7)

So that groff(1) means to see the manpages for the groff command found in section 1:

Code:

man 1 groff

and similarly groff_man(7):

Code:

man  7 groff_man

tells man to display the manpages for groff_man from section 7.

Again, you should thoroughly read and understand the contents from:

Code:

man man
info man

Hope this explains it a bit more.

Ztcoracat · 09-05-2012, 07:29 PM

The examples that you gave in code like

Code:

man 1 groff

helped me to understand; Thank You

In regard to how commands are made you said;
"do not take it literally as some options may not necessarily be a true representation of their meaning."
I needed that confirmation as well as I was taking that literally-
Now I know better.

I will throughly read the contents in the terminal for:

Code:

man man
info man

Until you helped me I was not aware how important the man pages are and how well they can teach me.
I see now that the man pages are considered to be one's friend.