Re: [Tiger-devel] CVS Tiger patches 20030926

[Javier Fernández-Sanguino Peña]

On Sat, Sep 27, 2003 at 12:16:13AM +0200, unspawn wrote:
> 
> I think I should apologize in advance for this being a rather longish 
> email, and also in the case any of the issues below have been discussed on 
> the tiger-user ML.

I also apologise for answering so late.

(I skip 1 and 2 since I already commented on them)

> 3. Linux, check_inittab better grep string for ctr?altdel

This has been fixed already.

> 4. Generic?, Task #2083: Check for /dev/null in history

Thanks, I will included this. Have to remove the bashisms, though, in order 
to ensure portability.

> 5. Task #1643: Include checks for RedHat using rpm -VA Even though we've
> got full-fledged support for filesystem integrity detection on most if not
> all platforms, I still think this could serve a purpose, especially as
> baseline for newbies who haven't installed and integrity detection
> package. The "problem" is the md5sum database should be saved to read-only
> media to be trustworthy, and will loose accuracy over time (only when
> removing/upgrading ofcourse).

[BTW, did you provide a patch with this one, I don't find it in the tar.gz]
Even if not on read-only media, an rpm -VA database is still useful since 
many script-kiddies/worms/rootkits will just blindly overwrite files 
without taking care of "fixing" the md5sum database of the package 
management system. Granted, it will only be useful for some attacks, but if 
these attacks are 90% of the attacks one will suffer its still quite 
useful.

> 
> 6. Updated RPM spec file now allows for relocation.
> 

Thanks. Updated.

> 
> Misc notes:
> Known Goods
> I did a quick 'n dirty comparison between my (trusted) rpm database and 
> the baseline from Known Goods. Local RH7.1 rpmdb vs Knowngoods' 
(...)
> WARNING: 239 of 46525 computed checksums did NOT match
> IMHO pretty useless unless you are AND in a forensics situation AND are
> can/need to match the sums to a specific package version's contents. And
> even then...

True. I tested this too in a forensic analysis and will probably remove the 
intention to integrate with Knowngoods' information.

> systems/Linux/2/check_listeningprocs
> - IMHO 127.0.0.1 should be grepped as ^127. since it's a /8, isn't it?

Yes. I will add this in the future.

> - Should we differentiate between public network ranges and bogons?   

I don't really think we should. After all, even if using bogons, they could
be NATTed somewhere outside and the host could be available as a public
server. This is not something that can be easily determined, and since, as
you describe, bogon addresses are not that easy to determine I would skip
that check (BTW, it's easier just to 'whois XXX' and let others tell us
it's IANAs reserve space
:-)

> systems/Linux/2
> There's a few more things I would like to add, but I'm not sure if it's
> usefull, and if I should invest time, because these will only apply to 
> OS=Linux.
> - How about adding sniffer detection? This kind of fits in with
> promiscuous mode detection. If you grep /proc/net/packet -ve ^sk for
> sniffer entries, then you can grep lsof output for the inode (awk field
> 9) and determine the processname. Why? because sniffers don't always
> *need* to put the interface in promiscuous mode. Meaningfull or not?

Meaningful. However, if this is already done by chkrootkit I would just 
keep it out. Since chkrootkit and check_rootkit do overlap in some places 
and since 'check_rootkit' can call chkrootkit I think it's best to use that 
one instead of trying to reproduce all its code in a single module.

> - I'm a great fan of using ro partitions and using extended attributes.
> Now I'm aware this could well lead to overhead, but what if we added   
> checks for both? I'm thinking about messages with respect to crucial   
> system files, so if /sbin is not on a ro mounted partition then
> if the FStype is ext?, then if the contents of /sbin are NOT chattered
> +iu, we could fire off an informational message this could be enabled?

That could be a useful check. I'm also a fan of using ro partitions, if 
anything, they prevent me from breaking stuff :-)

Notice, however, that many rootkits will use extended attributes to block
changes of files modified by rootkits so I would not rely too much on that
check. It would be wise to do this check for /usr, /bin and /sbin at least. 
It could also warn the user if /tmp is in the same partition as / (or if
/home is). I think an "advisor" of improper partition setups would really
be useful. Care to code it? :-)

Regards

Javi

signature.asc
Description: Digital signature