chkrootkit says...
Warren Post
Two results are interesting:
Checking `aliens'...
/dev/shm/pulse-shm-2062859958
[snip]
Checking `sniffer'... eth0: PF_PACKET(/sbin/dhclient)
Searching the web, I have found statements claiming that both of these
are false positives. But I dunno, especially that last one. I'm no
dhclient guru, but I'd be a little surprised if its default behavior is
to leave eth0 in promiscuous mode.
I'm running mdv2010.2; relevant software is:
chkrootkit-0.49-4mdv2010.1
task-pulseaudio-2010.0-4mdv2010.1
dhcp-client-4.1.2-0.2mdv2010.2
Thoughts, anyone?
--
Warren Post
http://my.opera.com/wpost/
Moe Trin
<igqrj7$vhm$1...@news.eternal-september.org>, Warren Post wrote:
>I'm playing with chkrootkit in an attempt to learn more about security.
I'm not really sure that's a good teacher. A lot of the testing is
run from a shell script, and it shows some major shortcomings. One of
the early tests is to look for the "55808" worm (a port scanner that
was active in mid-2003). It does this by
w55808 (){
W55808_FILES="${ROOTDIR}tmp/.../a ${ROOTDIR}tmp/.../r"
STATUS=0
for i in ${W55808_FILES}; do
if [ -f ${i} ]; then
STATUS=1
fi
done
if [ ${STATUS} -eq 1 ] ;then
echo "Warning: Possible 55808 Worm installed"
else
if [ "${QUIET}" != "t" ]; then echo "not infected"; fi
return ${NOT_INFECTED}
fi
if you're not familiar with shell scripting, it's looking for the
presence of '/tmp/.../a' or '/tmp/.../r' and if it finds either, it
says you MAY be 0wn3d - otherwise, your clean. Now you don't suppose
that the bad guys might do something earth-shaking and difficult like
changing the filename to '/tmp/.../A' or '/tmp/.../b' or somethin....
Learning about security? Ignoring the various HOWTOs, I'd start by
looking at the man page for 'rpm' under the VERIFICATION section, and
then think about this line from the Debian 'debsums' (a program with
functionality somewhat similar to 'rpm -V') man page:
debsums is intended primarily as a way of determining what installed
files have been locally modified by the administrator or damaged by
media errors and is of limited use as a security tool.
If you are looking for an integrity checker that can run from safe
media, do integrity checks on checksum databases and can be easily
configured to run periodically to warn the admin of changes see
other tools such as: aide, integrit, samhain, or tripwire.
and remember "It's only called paranoid when they AREN'T after you"
>Two results are interesting:
>
>Checking `aliens'...
>/dev/shm/pulse-shm-2062859958
grep for 'aliens' in the chkrootkit shell script. It's looking for
files in the /dev/ directory tree.
>Checking `sniffer'... eth0: PF_PACKET(/sbin/dhclient)
[compton ~]$ locate DHCP
/usr/share/FAQ/DHCP-FAQ.gz
/usr/share/HOWTO/DHCP.gz
[compton ~]$
>But I dunno, especially that last one. I'm no dhclient guru, but I'd
>be a little surprised if its default behavior is to leave eth0 in
>promiscuous mode.
Be surprised. On startup, dhclient has no clue what address is what,
so it broadcasts from 0.0.0.0 (me - I don't know my address) to the
world (255.255.255.255) hoping someone will answer. The DHCP server
replies with it's own source address, but the reply has to go to that
0.0.0.0 IP. The server eventually provides an IP, network mask, and
maybe a gateway IP, DNS server IPs, NTP server IP (bunch of RFCs,
start with RFC2131 and 2132
2131 Dynamic Host Configuration Protocol. R. Droms. March 1997.
(Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by
RFC3396, RFC4361, RFC5494) (Status: DRAFT STANDARD)
2132 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms.
March 1997. (Format: TXT=63670 bytes) (Obsoletes RFC1533)
(Updated by RFC3442, RFC3942, RFC4361, RFC4833, RFC5494) (Status:
DRAFT STANDARD)
and follow the chain), and a lease period. Once the dhclient has this
data, it _could_ reset the interface out of promiscuous mode, but most
don't. Half way through the lease, the client begins pestering the
server about renewing the lease, but it NORMALLY does this using it's
assigned addresses - IF IT REMEMBERS the IP of the server. If the
lease expires, start from scratch.
>chkrootkit-0.49-4mdv2010.1
chkrootkit-0.49 dates from September 30, 2009 (and as of two weeks ago
that was current). Not very much like the common windoze anti-mal-ware
that gets updated several times a day.
Old guy
Robert Riches
The _vast_ majority of chkrootkit reports are false positives.
It's rather poorly design/written. However, as long as the false
positives don't happen too often, it can give a modest bit of
assurance.
--
Robert Riches
spamt...@jacob21819.net
(Yes, that is one of my email addresses.)
Doug Laidlaw
I run rkhunter from the repositories. I don't know if it is any better.
The changelog shows mainly bugfixes.
Doug.
Warren Post
(big snip)
Thanks, that reply is very helpful. So you see, I *am* learning about
security -- just not from chkrootkit, but from you and Robert.
Moe Trin
>Moe Trin wrote:
>> Warren Post wrote:
>>>I'm playing with chkrootkit in an attempt to learn more about security.
>> I'm not really sure that's a good teacher. A lot of the testing is
>> run from a shell script, and it shows some major shortcomings.
>> If you are looking for an integrity checker that can run from safe
>> media, do integrity checks on checksum databases and can be easily
>> configured to run periodically to warn the admin of changes see
>> other tools such as: aide, integrit, samhain, or tripwire.
>> chkrootkit-0.49 dates from September 30, 2009 (and as of two weeks ago
>> that was current). Not very much like the common windoze anti-mal-ware
>> that gets updated several times a day.
>I run rkhunter from the repositories. I don't know if it is any better.
>The changelog shows mainly bugfixes.
As of two weeks ago, rkhunter-1.3.8 (November 16, 2010) was the latest,
and the Changelog from 1.3.6 (Nov. 29, 2009) was about 200 lines. It
has many of the same short-comings of chkrootkit, but is at least a
bit more up-to-date. I still don't bother with either, as they are
trivial to fool/bypass/subvert, and I don't think the CPU cycles they
waste (never mind the disk space) are worth it.
You _really_ need to define your threat model, and take appropriate
steps based on that assessment. Are you playing on the bad side of
town (or allowing connections to insecure services from the bad side
of town)? Then you probably want to get your head examined, or at
the very least run your system from Read-Only media. Less paranoid?
You should be running an Intrusion Detection System or a file
Integrity Checker, such as aide, integrit, samhain, or tripwire from
media not normally installed/mounted (to prevent someone "fixing" the
tool).
A major problem with most integrity checkers (and this extends to
tools like rkhunter) is that they try to compare what the files look
like "now" as opposed to a (presumed) clean condition some time ago.
Are you keeping your system updated with the latest security (and any
or all other) updates? An integrity checker should detect those
updates and scream about the files being different. Thus, you have
to run the integrity checker, see what it's bitching about, decide if
the warning is good/bad, and if you did update something, you _then_
(after running the integrity checker and seeing nothing else is bad)
have to take a "new" snapshot to which the integrity checker can make
comparisons next time it's run. And as mentioned, this needs to be
run from media that isn't accessible to the bad guys. Not as trivial
as it may seem.
Old guy
Moe Trin
>Thanks, that reply is very helpful.
You're welcome!
>So you see, I *am* learning about security -- just not from chkrootkit,
>but from you and Robert.
642561 Mar 10 2003 Secure-Programs-HOWTO
155096 Jan 23 2004 Security-HOWTO
278012 Jul 23 2002 Security-Quickstart-HOWTO
287057 Jul 23 2002 Security-Quickstart-Redhat-HOWTO
The last two are essentially the same, differing in inetd verses
xinetd for the most part. The LDP (http://tldp.org/guides.html) has
(or had) additional material, such as
* Securing & Optimizing Linux: The Ultimate Solution
version: 2.0
author: Gerhard Mourani, <gmou...@openna.com>
last update: July 2002
available formats:
1. PDF (6.2MB)
2. Example server configuration files (tar file; described in
book as "floppy.tgz").
older version: Securing and Optimizing Linux Red Hat Edition - A
Hands on Guide
version: 1.3
author: Gerhard Mourani, <gmou...@openna.com>
last update: August 2000
* Linux Administrator's Security Guide
Removed at the request of the author (book is now more "dynamic").
Please access the Linux Administrator's Security Guide at the
following location:
http://www.seifried.org/security/index.php/Linux_Security
and Debian has a "Securing Debian Manual" available there.
A lot of security is common sense - things like not trusting ANY user
input (if you read the Bugtraq mailing list, you know how often "$FOO
not sanitizing user input" is listed as an exploit vector), or simple
lack of thinking. Tools like chkrootkit look for things that have
been seen in the past (as much as 11 years in the past, which is more
than useless). A disadvantage of this type of tool is that it won't
find "new" or "zero-day" exploits except through incompetence of
mal-ware author. Integrity checkers such as 'tripwire' look at changes
between what is assumed to be a "clean" condition, and what's there now.
A major disadvantage of these tools is the need to constantly update
the "clean condition" database. 'rkhunter' mentioned by Doug attempts
to do both, but falls short as an integrity checker because it depends
on a built-in database rather than an actual snapshot. Tradeoffs,
tradeoffs - what is sufficient to handle your threat model?
Old guy
Doug Laidlaw
Exactly: it isn't trivial. I ran Tripwire for a while. I would have been
doing nothing else. Fine for a sysadmin, but not for a solo desktop. It
too was based on "what has changed?". Now I simply run a firewall, and
don't do silly things like running as root. It showed up a file that
shouldn't have been where it was, but that Mandriva had put there. I have
forgotten the full story, but it was in a directory that never has anything
"foreign," but under Mandriva it was there, and not removable (another sign
of a rootkit.) The only sign of its belonging was that it wasn't hidden.
rkhunter may be more up-to-date, but as I wrote, it has no new features, no
new rootkits to find. The changelog is all bugfixes or distro upgrades.
Doug.
Moe Trin
<evvc08-...@dougshost.douglaidlaw.net>, Doug Laidlaw wrote:
>Moe Trin wrote:
>> You _really_ need to define your threat model, and take appropriate
>> steps based on that assessment. Are you playing on the bad side of
>> town (or allowing connections to insecure services from the bad side
>> of town)? Then you probably want to get your head examined, or at
>> the very least run your system from Read-Only media. Less paranoid?
>> You should be running an Intrusion Detection System or a file
>> Integrity Checker, such as aide, integrit, samhain, or tripwire from
>> media not normally installed/mounted (to prevent someone "fixing" the
>> tool).
>> if you did update something, you _then_ (after running the integrity
>> checker and seeing nothing else is bad) have to take a "new"
>> snapshot to which the integrity checker can make comparisons next
>> time it's run. And as mentioned, this needs to be run from media
>> that isn't accessible to the bad guys. Not as trivial as it may seem.
>Exactly: it isn't trivial. I ran Tripwire for a while. I would have
>been doing nothing else. Fine for a sysadmin, but not for a solo
>desktop. It too was based on "what has changed?".
It's not exactly easy for a sysadmin either - which is why the idea of
running from 'Read-Only' media is mentioned. It's a lot easier to just
burn a new CD/DVD and reboot onto that when there is a change. Back in
the 1980s, some SCSI hard disks even came with a jumper that could be
installed (more normally, a pair of leads running to a front panel
switch) that disabled writing to the drive.
>Now I simply run a firewall, and don't do silly things like running
>as root.
Now where's all the excitement if you do that. Geez, Doug, you'd be
no fun at parties AT ALL! ;-)
>I have forgotten the full story, but it was in a directory that never
>has anything "foreign," but under Mandriva it was there, and not
>removable (another sign of a rootkit.)
By that, I assume you mean it had the immutable bit set - yes, that is
normally a bad sign, and most integrity checkers don't look at that.
>The only sign of its belonging was that it wasn't hidden.
which could be reverse psychology on the part of a mal-ware author.
When they _are_ out to get you, always check your paperwork.
Old guy
P.S. I'm paid extra for paranoia.