Is it possible to segregate the area that requires write permissions as one ramdisk partition, mount is as rw and mount the other portion as ro? If I'm not wrong, /dev requires rw. Why not declare as a separate partion in linuxrc when generating /dev directory? Locate mount and df in directories that are not in the path so that the hacker cannot get to it easily. In lrcfg, during backup, mount the device as rw, backup and then mount it back as ro.
I'm not very dexterous with linux boot sequence. If my idea makes sense, can this be incorporated by someone more skilled please? Mohan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brad Fritz Sent: Sunday, August 25, 2002 9:41 AM To: [EMAIL PROTECTED] Subject: [leaf-user] [long] boot media write protection and change detection (was: Are there other "Soekris"...) On Sat, 24 Aug 2002 13:35:18 MST Craig wrote: > Are there other "svelte" looking devices that LEAF can be installed on > like these Soekris type devices [snip] > Are these devices really "secure" in the sense > that they're somehow read only like a write protected floppy or CD-R? Probably obvious to everyone here, but with all the emphasis on write-protected boot media lately, it might be worth mentioning that hardware write-protected boot media is only good if you detect when unauthorized changes are made to the (writable) ramdisk. It's not much good to have a clean boot image if you don't know to reboot and restore it. One approach to increasing protection afforded by the write- protected boot media would be to run the firewall in a nearly halted state as described in SysAdmin at http://www.samag.com/documents/s=1824/sam0201d/0201d.htm although that approach has significant limitations...like not being able to run sshd for remote administration. IMO, it would be really cool to augment the security of write-protected boot media with an integrity checking system. Possibly one that computes file checksums and compares them to known good checksums. Like Tripwire or AIDE I guess, although I haven't used either of those tools yet. Such a system would also make me feel more comfortable running compact flash LEAF boxen without boot media write protection. Computing checksums on low-end LEAF boxes might not be a great idea, so I was thinking of an approach like this... 1. Setup a central, well-protected management server that has ssh public-key access to the LEAF servers to be monitored. The management server would have ssh, rsync and a tripwire(-like) package installed. (Actually I already have this system setup minus tripwire/aide.) 2. At regular intervals the management server would use rsync over ssh (with public key authentication) to update a local copy of the remote LEAF file system.[1] 3. The tripwire(-like) tool would be run on the local copy of the remote image to compare file signatures to known good signatures in a database. An administrator would be notified if signatures of important files had changed. One of the weaknesses of the system would be that a skilled attacker could replace sshd with a modified version that spits back archived original copies of the checked files rather than the versions in service. If rsync is being used, it would probably be even easier to deceive the management host. Alright, enough of my rambling; just a few questions and then I will wrap it up... Is anyone here already doing something like this with LEAF? Does anyone see flaws with the described approach that I have overlooked? Would anyone like to offer suggestions for improvements? --Brad [1] Using rsync would be optional. A full copy could be transferred if network bandwidth is more plentiful than spare CPU cycles on the LEAF system. ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
