l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
January 6: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2008 Aug 11 15:44

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Verify Ubuntu files
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Verify Ubuntu files



Brian Lavender wrote:
> Is there a way to verify the integrity of binary files in an Ubuntu
> system? I just back from Defcon and I was wondering if I can inventory
> installed packages to make sure they are still the same.



Brian:

	You ask a very hard question which does not have a simple
	answer.

	I assume when you say you would like to know if the installed
	packages are the same you are not meaning if a package has
	been installed without your knowledge. And what you really
	mean is 'have any of the binaries on your systems changed
	from the time their were installed?'.

	But first lets take a simple look at things. You may want to
	have a list of all of your current packages. You can do this
	with the following command line:

dpkg --get-selections | grep '[[:space:]]install$' | awk '{print $1}'

	This will give you the list of all packages you have installed.
	I like to run this command after I have done a base install
	to get that list and save it to a file. Then every so often
	I run the command to have the current list. This now give me
	way I can find what packages I have installed by doing a
	diff on the two files. And it can may doing a restore from
	bare metal a lot faster (install the OS, install the addition
	packages and you are back to the same starting point).

	But this does not solve the question you asked because you
	don't know if a file on your system has been altered. There
	is really only two ways to know and they really do the same
	thing. So lets *assume* that right now you are starting from
	bare metal. You should do the following in any real secure
	environment (and trust me I don't do this on my home systems
	but I could). Follow the Bare Metal install, and then do
	either 'Network Tripwire' or 'Local Tripwire'.

	Bare Metal install to 'working' system.

	1) Install the OS
	2) Save the list of packages
	3) Record any changes made to configs at this time in writing
	4) Install any addition packages to bring system to level needed
	5) Save the list of both the OS packages and added packages
	6) Record any changes made to configs in writing
	
	Network Tripwire
	1) On Security Server install Tripwire
	2) Network new system so the Security Server can mount the hard
	   drive(s) remotely.
	3) Run Tripwire and build database of all current files with
	   their timestamps,size and MD5 values.
	4) Unmount the drives
	6) Daily do step#2 and check tripwire database with current
	   values. Not any changes as this can be a security issue.

	Local Tripwire
	1) Install the Tripwire software.
	2) Use a removable device (USB, hard-drive, floppy)
	3) Build Tripwire database on the above device
	4) Remove the above device
	5) Daily connect the above removable device and run the
 	   tripwire audit.

	Using Bacula instead of Tripwire.

	I assume that you want to have a back-up of your data on the
	system(s). The best tool out there is Bacula, it is a true
	client/server and can be set-up to also perform a tripwire
	style audit.  So when you back-up your system also have it
	create an audit of all of your files.

	In any case *DO NOT* keep the audit file on the system you
	are auditing. The reason it it can be altered and hid that
	you have different information then what you believe you have.

	And it is a good idea if the system being audit does not have
	any reference to the security server (your NFS files may need to
	show it but otherwise there should be none). You security server
	MUST be secure. It should be on a in house network only which
	can not be reached from the outside.

	I have heard of cases where people wanted to have the client
	system mount the security server and then run the tripwire
	audit locally and write to the security server. THIS IS A BAD
	IDEA!!!

	I hope this gives you some idea of what you can do. When I
	was at Netcom I did some of this. But let me say right now
	you really need to know what files to audit and how to audit
	them or you *will* be spending a lot of time tweaking your
	tripwire configures. For example, directories like /var/mail
	is not a good system to audit (it changes too much). The
	same goes for /var/log. With /var/log you look to insure that
	files are there and the owner/group and permissions are correct
	not the timestamps or the size.  It will take some time to learn
	how to config Tripwire.

							Tony
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!