I''d like to hear some suggestions about securely administering a
system remotely. Here''s the application: a project is going to
scatter some server machines around the US. The server machines will
be running Linux, with the only network servers being a custom
application.
Ignoring the separate question of physical security, how can I
remotely check the system''s integrity using Tripwire, ''rpm
--verify'',
or some other mechanism? An obvious first solution is to leave a
CD-ROM in the machine containing the RPMs (Tripwire database,
whatever), but a cracker could just put a Trojan version of RPM in
place. You could put the RPM binary on the CD too, but then a cracker
would just have to modify the shell to recognize when the RPM binary
on the CD is being run, and substitute the Trojan version. Inserting
a back door into the kernel''s implementation of exec() would handle
shells, C scripts, and anything else that tries to run that binary.
Putting RPM on the CD raises the bar, requiring a more sophisticated
attacker, but it doesn''t solve the problem.
If the machine was sitting in front of you, you''d just reboot
it with a boot floppy, and run a known-good version of RPM from the
floppy, but that''s not an option when the machine''s on the
other side
of the country; someone local would have to reboot the machine every
so often, run the verification, and then reboot again.
(Hmm... a cracker could modify the shutdown scripts to restore
the original versions of binaries, so the verify would report nothing.
Perhaps even the check from floppy is no guarantee of anything.)
Any suggestions?
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
Facts were never pleasing to him. He acquired them with reluctance and got rid
of them with relief. He was never on terms with them until he had stood them
on their heads.
-- J.M. Barrie
I seem to remember a discussion here a while back about a hacker inserting a malicious kernel module that modified all the filesystem code to hide all traces of its presence. The basic decision was that it comes down to what would be a reasonable level of protection. As long as you can come up with something to protect yourself, you can probably come up with some way to get around it. The question becomes, is the exploit worth the effort it would take to write? I personally think that putting the tripwire binary and its database on a PHYSICALLY locked drive is sufficient. Of course, you need to make sure that the script that cron exicutes to run tripwire is check, so a hacker can''t simply change the script to mail a fake report. Or, to be really sure, ssh in and run the tripwire verify yourself. With the number of insecure machines out there, unless you had some REALLY valuable data, I can''t see a hacker going through enough trouble to rewrite parts of the kernel to cover their tracks. I think it they would probably just go find a less secure machine. Scott On Tue, 12 May 1998, Andrew Kuchling wrote:> I''d like to hear some suggestions about securely administering a > system remotely. Here''s the application: a project is going to > scatter some server machines around the US. The server machines will > be running Linux, with the only network servers being a custom > application. > > Ignoring the separate question of physical security, how can I > remotely check the system''s integrity using Tripwire, ''rpm --verify'', > or some other mechanism? An obvious first solution is to leave a > CD-ROM in the machine containing the RPMs (Tripwire database, > whatever), but a cracker could just put a Trojan version of RPM in > place. You could put the RPM binary on the CD too, but then a cracker > would just have to modify the shell to recognize when the RPM binary > on the CD is being run, and substitute the Trojan version. Inserting > a back door into the kernel''s implementation of exec() would handle > shells, C scripts, and anything else that tries to run that binary. > Putting RPM on the CD raises the bar, requiring a more sophisticated > attacker, but it doesn''t solve the problem. > > If the machine was sitting in front of you, you''d just reboot > it with a boot floppy, and run a known-good version of RPM from the > floppy, but that''s not an option when the machine''s on the other side > of the country; someone local would have to reboot the machine every > so often, run the verification, and then reboot again. > > (Hmm... a cracker could modify the shutdown scripts to restore > the original versions of binaries, so the verify would report nothing. > Perhaps even the check from floppy is no guarantee of anything.) > > Any suggestions? > > -- > A.M. Kuchling http://starship.skyport.net/crew/amk/ > Facts were never pleasing to him. He acquired them with reluctance and got rid > of them with relief. He was never on terms with them until he had stood them > on their heads. > -- J.M. Barrie > > -- > ---------------------------------------------------------------------- > Please refer to the information about this list as well as general > information about Linux security at http://www.aoy.com/Linux/Security. > ---------------------------------------------------------------------- > > To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null >======================================================================Scott Venier *Consultant for Ingematics, scott@compu-aid.com A division of Compu-Aid, Inc. -----------------------------------------------------------------------
On Tue, May 12/98, Andrew Kuchling <akuchlin@cnri.reston.va.us> wrote:> I''d like to hear some suggestions about securely administering a > system remotely. Here''s the application: a project is going to > scatter some server machines around the US. The server machines will > be running Linux, with the only network servers being a custom > application.Then don''t activate anything else other than sshd for access to the box. If you don''t have easy physical access to the box you might also want to consider a second box with only sshd and a serial connection to the first box, and add the serial console patches for the kernel.> > Ignoring the separate question of physical security, how can I > remotely check the system''s integrity using Tripwire, ''rpm --verify'', > or some other mechanism? An obvious first solution is to leave a > CD-ROM in the machine containing the RPMs (Tripwire database, > whatever), but a cracker could just put a Trojan version of RPM in > place. You could put the RPM binary on the CD too, but then a cracker > would just have to modify the shell to recognize when the RPM binary > on the CD is being run, and substitute the Trojan version. Inserting > a back door into the kernel''s implementation of exec() would handle > shells, C scripts, and anything else that tries to run that binary. > Putting RPM on the CD raises the bar, requiring a more sophisticated > attacker, but it doesn''t solve the problem.Why not eliminate the possibility of someone changing the binaries completely by running them from the cdrom. Put as much of the filesystem on cd as you can. Use a bootable cdrom. If you can''t use a bootable cd, boot from a write protected floppy. Does anyone know if any of the cdrom filesystems can support symlinks? If not you would have to mount the root filesystem on a ramdisk I suppose. Only have variable data stored on the local hard drive and better yet have copies written back to your home machine in real time. -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y*
For the ultimate in paranoid systems that don''t change much, you could
put a
CD in that is bootable and boot a live file system from it.
Then you could mount your hard drive for storing logs and your data.
Assuming everything but data is on the CD it would make things much more
difficult for a hacker to install and make changes.
This again assumes that user home directories and root directory and all
programs are on a CD.
The only problem is that it makes it impossible for you to make changes to
the system to fix holes or other problems. Of course, as long as you keep
your original system in tact, then updates are as simple burning a new CD
and fedex it to the remote locations, shutdown, change CDs, reboot, and new
system.
I don''t know how feasible this is, I haven''t done it or even
seen it done,
but I have thought about it. And, after seeing the SuSE cd boot it made
realize how feasible it could be.
Greg
-----Original Message-----
From: Andrew Kuchling [mailto:akuchlin@cnri.reston.va.us]
Sent: Tuesday, May 12, 1998 3:55 PM
To: linux-security@redhat.com
Subject: [linux-security] Checking remote servers
I''d like to hear some suggestions about securely administering a
system remotely. Here''s the application: a project is going to
scatter some server machines around the US. The server machines will
be running Linux, with the only network servers being a custom
application.
Ignoring the separate question of physical security, how can I
remotely check the system''s integrity using Tripwire, ''rpm
--verify'',
or some other mechanism? An obvious first solution is to leave a
CD-ROM in the machine containing the RPMs (Tripwire database,
whatever), but a cracker could just put a Trojan version of RPM in
place. You could put the RPM binary on the CD too, but then a cracker
would just have to modify the shell to recognize when the RPM binary
on the CD is being run, and substitute the Trojan version. Inserting
a back door into the kernel''s implementation of exec() would handle
shells, C scripts, and anything else that tries to run that binary.
Putting RPM on the CD raises the bar, requiring a more sophisticated
attacker, but it doesn''t solve the problem.
If the machine was sitting in front of you, you''d just reboot
it with a boot floppy, and run a known-good version of RPM from the
floppy, but that''s not an option when the machine''s on the
other side
of the country; someone local would have to reboot the machine every
so often, run the verification, and then reboot again.
(Hmm... a cracker could modify the shutdown scripts to restore
the original versions of binaries, so the verify would report nothing.
Perhaps even the check from floppy is no guarantee of anything.)
Any suggestions?
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
Facts were never pleasing to him. He acquired them with reluctance and got
rid
of them with relief. He was never on terms with them until he had stood them
on their heads.
-- J.M. Barrie
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null
At 04:54 PM 5/12/98 -0400, you wrote:>I''d like to hear some suggestions about securely administering a >system remotely. Here''s the application: a project is going to >scatter some server machines around the US. The server machines will >be running Linux, with the only network servers being a custom >application.What I have done several times in situations like this is to setup the system and get rid of all unnecessary kernels and files and write a bootable cd of just what is needed for the system to function. This will only work assuming that no changes need to be made to the configuration and users are not using the system. but works well for firewalls and other like machines where no one should be using them. If an attacker even was able to get access to the console with a boot disk they couldn''t make any changes. A combination of a bootable cd with the kernel and key possibly exploitable files and a small hd for other programs and their databases in theory would be make a fairly secure system but not very customizable or easily upgradeable. Tyler Walden - tylerw@comfortcare.net
On Tue, 12 May 1998, Andrew Kuchling wrote:> I''d like to hear some suggestions about securely administering a > system remotely. Here''s the application: a project is going to > scatter some server machines around the US. The server machines will > be running Linux, with the only network servers being a custom > application.In this case what kind of administering do you need? You won''t use any other services but the custom application. I don''t think any cracker could break in into an absolutely closed system except for when you had the custom application written with security wholes. Right?> (Hmm... a cracker could modify the shutdown scripts to restore > the original versions of binaries, so the verify would report nothing. > Perhaps even the check from floppy is no guarantee of anything.)Well.. a cracker can simply change everything in your system... So how will you detect him? Easy, by not allowing him to get into it. Best regards, Kalin. ------------------------------------------------------------------------ Kalin Bogatzevski, XaX World Co. President, BIS OnLine Internet Alliance - e-mail:kalin@biscom.net, kalin@xax.bg; URL: http://biscom.net/~kalin - - ICQ: 2580422; phone/fax/mail: +359-2-9631210; mobile: (0799)44463; - - address: 12, Tzanko Tzerkovski str., 1164 SOFIA; BULGARIA -
PaZeN writes:>How many users are going to need access to each system? >Where are these users logging in from? (i.e. telnet, dumb terminals, > xterminals, etc)? >What is the single app/daemon that you need to run? >What kind of breakin are you most afraid of internel or external?The application involves connecting a server machine to a controllable microscope; these microscopes would be at fabrication sites all over the place. (Centralizing them is not an option.) Users would run client programs that connect to a custom daemon written for this application that lets them control the microscope and view images; The machines therefore need only run sshd (to let the administrator log in) and the custom server; no sendmail, named, ftpd, or anything else need be running. Users would be connecting over the Internet at large, not via a private network, so the servers are vulnerable to the same attacks as any Unix system. Obviously physical security and the security of the daemon are also very important, but they''re not what I''d like to discuss. Discussing this with a friend last night, he suggested burning a CD-ROM with a live filesystem, and running off the CD. The hard drive would then be only used for storing data files and /tmp; if logging is done to another machine, there are no logs to be written locally. That''s a very good idea, I think; if the system can be set up to boot from the CD-ROM and then mount it as /, that would make substituting Trojans very difficult. Fixing bugs in the system would then require burning a new CD and sending it via Fedex, which would be highly annoying, but that can probably be tolerable. Kevin Smith wrote:>I would use tripwire... (definately not rpm -Va)... use tripwire, which >you should have on a cdrom, including all of the checksums... all of it >on the unmodifiable cdrom... or even store it all locally, and write a >script that will ssh into the machine, install a tool to get the checksums >or whatever you need... run all the tests on the checksums locally, andHm; what''s wrong with ''rpm -Va''? Obviously, this would have to be run against RPMs on the CD, not against the possibly compromised database on the hard drive. Or is it that rpm only has MD5 checksums? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ People marry most happily with their own kind. The trouble lies in the fact that people usually marry at an age where they do not really know what their own kind is. -- Robertson Davies, _A Voice from the Attic_
On Tue, 12 May 1998 16:54:32 -0400 (EDT), <akuchlin@cnri.reston.va.us> wrote:> I''d like to hear some suggestions about securely administering a > system remotely. Here''s the application: a project is going to > scatter some server machines around the US. The server machines will > be running Linux, with the only network servers being a custom > application.So you start with a machine that has only the basic installed users: [ from /etc/passwd on a shadow system ] root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: adm:x:3:4:adm:/var/adm: lp:x:4:7:lp:/var/spool/lpd: sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail: news:x:9:13:news:/var/spool/news: uucp:x:10:14:uucp:/var/spool/uucp: operator:x:11:0:operator:/root: games:x:12:100:games:/usr/games: gopher:x:13:30:gopher:/usr/lib/gopher-data: ftp:x:14:50:FTP User:/ftp: nobody:x:99:99:Nobody:/: This machine should only be running the following applications: init update crond kerneld kflushd kswapd syslogd klogd CUSTOM APPLICATION At this point (forgetting about physical access) you have to assume that your custom application is secure. So how do you access the machine, your choices include ssh, kerberose, OTP. Installing one of these methods and logging in as root should be secure. Adding users to this machine that are not you bring to light an entirely new discussion and you''ll need to weight what programs they need run, how much privelege they need, etc. [mod: I''d cut down on the "default users" even more if I''d go this route. (check if you need "nobody". If not, just leave "root"!). I''d add one account for the system administrator. Scan for setuid programs on the system. Most of them aren''t needed. Remove the setuid bit. --REW] -- Bryan C. Andregg * <bandregg@redhat.com> * Red Hat Software "Hey, wait a minute, you clowns are on dope!" -- Owen Cheese in ''Shakes the Clown''
Quoting Andrew Kuchling (akuchlin@cnri.reston.va.us):> If the machine was sitting in front of you, you''d just reboot > it with a boot floppy, and run a known-good version of RPM from the > floppy, but that''s not an option when the machine''s on the other side > of the country; someone local would have to reboot the machine every > so often, run the verification, and then reboot again.Why not put the whole root fs on a cdrom and run from there? Put the hard drives on a separate controller that doesn''t have boot code. Mike Stone
The best and easiest way to Admin Remote Servers is to connect via a call-back system and admin it using telco lines. Then you would have relitively little chance of being attacked via the internet, and all but the best system crackers know how to subvert call-back (those you can''t stop anyways). There is a cheaper/easier way to change a write protected filesystem. This is to use a ZIP/Jaz disk from iomega (www.iomega.com). With these disks you can write protect the disk using a password. That is what I would do. PAZEN, AAmaral, pazen@pazen.ml.org. P A Z E N eMail:pazen@pazen.ml.org Consulting WWW:http://pazen.ml.org UNIX (SVR4 & *BSD*), NT, C/C++, COBOL, SQL, HTML, XML * Linux Powered * "Intelligence is a double edged sword, weild a shotgun" On Wed, 13 May 1998, Andrew Kuchling wrote: //PaZeN writes: //>How many users are going to need access to each system? //>Where are these users logging in from? (i.e. telnet, dumb terminals, //> xterminals, etc)? //>What is the single app/daemon that you need to run? //>What kind of breakin are you most afraid of internel or external? // // The application involves connecting a server machine to a //controllable microscope; these microscopes would be at fabrication //sites all over the place. (Centralizing them is not an option.) //Users would run client programs that connect to a custom daemon //written for this application that lets them control the microscope and //view images; The machines therefore need only run sshd (to let the //administrator log in) and the custom server; no sendmail, named, ftpd, //or anything else need be running. // // Users would be connecting over the Internet at large, not //via a private network, so the servers are vulnerable to the same //attacks as any Unix system. Obviously physical security and the //security of the daemon are also very important, but they''re not what //I''d like to discuss. // // Discussing this with a friend last night, he suggested burning //a CD-ROM with a live filesystem, and running off the CD. The hard //drive would then be only used for storing data files and /tmp; if //logging is done to another machine, there are no logs to be written //locally. That''s a very good idea, I think; if the system can be set //up to boot from the CD-ROM and then mount it as /, that would make //substituting Trojans very difficult. Fixing bugs in the system would //then require burning a new CD and sending it via Fedex, which would be //highly annoying, but that can probably be tolerable. // //Kevin Smith wrote: //>I would use tripwire... (definately not rpm -Va)... use tripwire, which //>you should have on a cdrom, including all of the checksums... all of it //>on the unmodifiable cdrom... or even store it all locally, and write a //>script that will ssh into the machine, install a tool to get the checksums //>or whatever you need... run all the tests on the checksums locally, and // // Hm; what''s wrong with ''rpm -Va''? Obviously, this would have //to be run against RPMs on the CD, not against the possibly compromised //database on the hard drive. Or is it that rpm only has MD5 checksums? // //-- //A.M. Kuchling http://starship.skyport.net/crew/amk/ //People marry most happily with their own kind. The trouble lies in the fact //that people usually marry at an age where they do not really know what their //own kind is. // -- Robertson Davies, _A Voice from the Attic_ // //-- //---------------------------------------------------------------------- //Please refer to the information about this list as well as general //information about Linux security at http://www.aoy.com/Linux/Security. //---------------------------------------------------------------------- // //To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null //
-----BEGIN PGP SIGNED MESSAGE----- On Tue, 12 May 1998 jhenders@bogon.com wrote:> Why not eliminate the possibility of someone changing the binaries > completely by running them from the cdrom. Put as much of the filesystemFedexing the new CD''s around means having somone walk to the box, so if he / she is already there, why not have him/her punch the speed button which is easily attached to the write protect switch of some SCSI hd''s? Makes maintaining easier, I''d think. When you leave two partitions for /var and /tmp rw but mounted noexec, suid/sgid and nouser there shouldn''t be a geat chance for a intruder to get some custom login to run. And overwriting some apps with a logfile should be prevented by the ro filesystem. Ipfwadm with strict reject rules should keep you from beeing visible to the average imap2, smtp, finger etc. portscanning CyBERDuDe :-) Yours Pluto /*------------------------------------------------------------------*\ Free information! Freedom through knowledge. Wisdom for all!! =:-) Key fingerprint: 1F 3F EA 94 D0 56 A6 86 4D 19 C4 56 6C F9 43 44 ----- Your todays fortune cookie ------ I do hate sums. There is no greater mistake than to call arithmetic an exact science. There are permutations and aberrations discernible to minds entirely noble like mine; subtle variations which ordinary accountants fail to discover; hidden laws of number which it requires a mind like mine to perceive. For instance, if you add a sum from the bottom up, and then again from the top down, the result is always different. -- Mrs. La Touche (19th cent.) ----- End of fortune ------ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAgUBNV3SW8SyBNtyYarNAQE4CgQAnra9sWi9CqXU/BRyY3tRksXbBZHlIvGl ssK2BGV1ooVHvYYDhAWFVmJD/YYS42D1w9q4wZJsDw/GqZAyK0nIUnydDy5XMyRC EM0J4w5QEEQ2aF1y2j56Py//6a5W7vMDSmbWM2cMbkg30dPOUncyhruWVIAQB0Zj tvDYzdqXx1k=kmP8 -----END PGP SIGNATURE-----
What about running a system entirely from a ramdisk, installed from an initrd? Paul Moody from down under uses this for a flash-bootable system using a 40MB flash disk (it contains initrd and a compressed ram disk image). He recommends a system with 64MB total memory, used mostly by ramdisk. Of course the same can be done with a regular IDE disk; the IDE disk can be write-protected, even, withouth the usual problems with /tmp See Paul''s Embedded Linux page at http://users.bigpond.com/paulmoody
> With the number of insecure machines out there, unless you had some REALLY > valuable data, I can''t see a hacker going through enough trouble to > rewrite parts of the kernel to cover their tracks. I think it they would > probably just go find a less secure machine.I think you are wrong here. A lot of hackers are kick-oriented. They want to get a kick out of hacking, or even need to get a kick out of it. Hacking a less secure machine is not an option there. Problem with these hackers is, there is no real way to stop them, because if there is a small way in, they will most probably find it. Ulrik De Bie
On Sat, 16 May 1998, PaZeN wrote:> The best and easiest way to Admin Remote Servers is to connect via a > call-back system and admin it using telco lines. Then you would have > relitively little chance of being attacked via the internet, and all but > the best system crackers know how to subvert call-back (those you can''t > stop anyways). There is a cheaper/easier way to change a write > protected filesystem. This is to use a ZIP/Jaz disk from iomega > (www.iomega.com). With these disks you can write protect the disk using > a password. That is what I would do.1) Single-modem callbacks are notoriously insecure. Just feed a dialtone down the line when you''re ready to hang up and be called back. Most modems won''t actually hang up when you do this. Double-modem callbacks can be subverted with a bit of call-forwarding. What you''re doing here is assigning trust based on your entry via an obscure door, yet unguarded door. Instead, you may wish to use a pair of point-to-point encryption boxes and use a good modem that can accept a password. [mod: Yeah, if you have such crappy software, you deserve to be hacked: your software should MAKE VERY SURE that indeed the line is given up, even if the other side pulls tricks on you. (Drop DTR should make the modem hangup. Always.) Can you do call-forwarding from a DIFFERENT line in the states? Not here. -- REW] 2) Because Zip and Jaz drives are write-protected through software, an intruder can easily flip the write-protection off once he has root access. You should be using a 3.5" MO drive or hard drive with the write-protect jumper engaged. [mod: This is the firmware in the drive right? Can you subvert that from the host end? --REW] -- David Griffith dgriffi@ultrix6.cs.csubak.edu
Also remember that mgetty can be set up to allow incoming calls by phone number assuming that you have caller ID and a modem that supports caller ID. This would be harder to get past as the hacker would have to guess what phone numbers are allowed. Mark Spieth A good day is where schools have all the money they need, And the Air Force has to hold a bake-sale to buy a bomber. -----Original Message----- From: PaZeN [SMTP:pazen@pazen.ml.org] Sent: Saturday, May 16, 1998 6:15 AM To: linux-security@redhat.com Subject: [linux-security] Re: Re: Checking remote servers The best and easiest way to Admin Remote Servers is to connect via a call-back system and admin it using telco lines. Then you would have relitively little chance of being attacked via the internet, and all but the best system crackers know how to subvert call-back (those you can''t stop anyways). There is a cheaper/easier way to change a write protected filesystem. This is to use a ZIP/Jaz disk from iomega (www.iomega.com). With these disks you can write protect the disk using a password. That is what I would do. PAZEN, AAmaral, pazen@pazen.ml.org. P A Z E N eMail:pazen@pazen.ml.org Consulting WWW:http://pazen.ml.org UNIX (SVR4 & *BSD*), NT, C/C++, COBOL, SQL, HTML, XML * Linux Powered * "Intelligence is a double edged sword, weild a shotgun" On Wed, 13 May 1998, Andrew Kuchling wrote: //PaZeN writes: //>How many users are going to need access to each system? //>Where are these users logging in from? (i.e. telnet, dumb terminals, //> xterminals, etc)? //>What is the single app/daemon that you need to run? //>What kind of breakin are you most afraid of internel or external? // // The application involves connecting a server machine to a //controllable microscope; these microscopes would be at fabrication //sites all over the place. (Centralizing them is not an option.) //Users would run client programs that connect to a custom daemon //written for this application that lets them control the microscope and //view images; The machines therefore need only run sshd (to let the //administrator log in) and the custom server; no sendmail, named, ftpd, //or anything else need be running. // // Users would be connecting over the Internet at large, not //via a private network, so the servers are vulnerable to the same //attacks as any Unix system. Obviously physical security and the //security of the daemon are also very important, but they''re not what //I''d like to discuss. // // Discussing this with a friend last night, he suggested burning //a CD-ROM with a live filesystem, and running off the CD. The hard //drive would then be only used for storing data files and /tmp; if //logging is done to another machine, there are no logs to be written //locally. That''s a very good idea, I think; if the system can be set //up to boot from the CD-ROM and then mount it as /, that would make //substituting Trojans very difficult. Fixing bugs in the system would //then require burning a new CD and sending it via Fedex, which would be //highly annoying, but that can probably be tolerable. // //Kevin Smith wrote: //>I would use tripwire... (definately not rpm -Va)... use tripwire, which //>you should have on a cdrom, including all of the checksums... all of it //>on the unmodifiable cdrom... or even store it all locally, and write a //>script that will ssh into the machine, install a tool to get the checksums //>or whatever you need... run all the tests on the checksums locally, and // // Hm; what''s wrong with ''rpm -Va''? Obviously, this would have //to be run against RPMs on the CD, not against the possibly compromised //database on the hard drive. Or is it that rpm only has MD5 checksums? // //-- //A.M. Kuchling http://starship.skyport.net/crew/amk/ //People marry most happily with their own kind. The trouble lies in the fact //that people usually marry at an age where they do not really know what their //own kind is. // -- Robertson Davies, _A Voice from the Attic_ // //-- //---------------------------------------------------------------------- //Please refer to the information about this list as well as general //information about Linux security at http://www.aoy.com/Linux/Security. //---------------------------------------------------------------------- // //To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null // -- ---------------------------------------------------------------------- Please refer to the information about this list as well as general information about Linux security at http://www.aoy.com/Linux/Security. ---------------------------------------------------------------------- To unsubscribe: mail -s unsubscribe linux-security-request@redhat.com < /dev/null
Scott Venier wrote:
If the machine was sitting in front of you, you''d just reboot
> > it with a boot floppy, and run a known-good version of RPM from the
> > floppy, but that''s not an option when the machine''s
on the other side
> > of the country; someone local would have to reboot the machine every
> > so often, run the verification, and then reboot again.
> >
> > (Hmm... a cracker could modify the shutdown scripts to restore
> > the original versions of binaries, so the verify would report nothing.
> > Perhaps even the check from floppy is no guarantee of anything.)
> >
> > Any suggestions?
mke2fs /dev/xxxx :(
Seems like having an OS with a publicly available kernel source could
be a serious security hazard! Saying that, once they are in then I
think your basically done, apart from a complete re-install there is
no way to be completely sure that you have gotten rid of everything.
Only way to win is not to play (Shut up all the holes so nothing can
get in!).
I''ll obviously not share our security measures on the list, but the
more routers and firewalls and knots you tie in the Ethernet cable the
better, then a simple hole in something that just about anybody with a
serious presence on the net runs can let the world in!
It is also apparent that many people who run Linux systems do not
really know much about security or where to keep track of bugs and
updates which makes Linux a prime target not to mention it''s
popularity!
Saying that though, if a DNS was behind a firewall that let ONLY DNS
though and nothing else except from maybe specified IP addresses then
the chance of being done would be substantially reduced.
[mod: Not this time. A cracker having root-access (through the DNS
bug) will not be stopped by a few firewall rules saying only DNS is
going to go in. Sure having access to "telnet" into the machine is a
bit more comfortable, but root-access through DNS is good enough to
subvert the whole machien. --REW]
[mod: Whole article reformatted. -REW]
--
Leigh Porter
Michael H. Warfield
1998-May-25 13:30 UTC
Re: [linux-security] Re: Checking remote servers
Leigh Porter enscribed thusly:> Scott Venier wrote:> If the machine was sitting in front of you, you''d just reboot> > > it with a boot floppy, and run a known-good version of RPM from the > > > floppy, but that''s not an option when the machine''s on the other side > > > of the country; someone local would have to reboot the machine every > > > so often, run the verification, and then reboot again. > > > > > > (Hmm... a cracker could modify the shutdown scripts to restore > > > the original versions of binaries, so the verify would report nothing. > > > Perhaps even the check from floppy is no guarantee of anything.)Hmmm... Including the shutdown / startup scripts? Those would be some of the first things I would check. If he restores everything back, then he would cut himself off from running again. :-)> > > Any suggestions?What you do really depends on how secure you want that remote system. You need some form of physical security one way or the other. Given that, you can take the extreme approach of building a system image on CD-R and keeping it in the system. Boot from the CD-R and validate the system from CD-R at boot. Rebuild, log, and/or alarm any anonmolies. Then also use periodic programs to validate the running system. Tripwire does a good job there. Liberal use of "append only" and "immutable" flags on all critical files and logs. Alarm all "append only" and "immutable" violations attempts and log them. Log all events off to another autonomous system whose sole job is life is to log. No loadable modules in the kernel! Is any of this 100% fool proof. No. It doesn''t have to be. You should understand more about your system than the person trying to break into it. If your preventative measure slow him down enough that he eventually trips over some of your alarm measures, changes are very good that you will catch anyone attempting to tamper with the system. You can layer on enough security perimeters, check points, auditing, alarms, etc, etc, etc to make a system a pretty tough nut to crack even if they KNEW what you had on the system.> mke2fs /dev/xxxx :(> Seems like having an OS with a publicly available kernel source could > be a serious security hazard! Saying that, once they are in then I > think your basically done, apart from a complete re-install there is > no way to be completely sure that you have gotten rid of everything.Having an OS with a publicly available kernel source is a security advantage. When the ping of death appeared, they measured the Linux patch time in hours. The author of "teardrop" announced it to the general world when he saw the fix go into the Linux source database. If you don''t have publicly available sources, the only ones with the sources with be stuborn uncooperative manufacturers and the crackers. The only way the individual who published the three "getadmin" Windows NT exploits could have known about those three archane tricks (one was writing to a peculiar offset off of a global structure) was to have some sort of sources (not that anyone would admit that). As soon as one was fixed, he posted the next. They were just a little too "peculiar" in what they exploited. Just because YOU, Joe Blow public, doesn''t have sources, it doesn''t mean those same sources are not available to the crackers. Ever take a peek at some the the hacker/cracker "toolz" CD''s. Don''t believe that they don''t have sources to a lot of this stuff...> Only way to win is not to play (Shut up all the holes so nothing can > get in!).> I''ll obviously not share our security measures on the list, but the > more routers and firewalls and knots you tie in the Ethernet cable the > better, then a simple hole in something that just about anybody with a > serious presence on the net runs can let the world in!Security through obscurity is no security. I share my security techniques. I''m a strong advocate of a layered approach to security with combinations of firewalls, filtering routers, and host based security along with detection software mining the gaps between the security perimeters. You don''t have to divulge IP addresses, host names, or locations of security perimeters to help others understand good security techniques. BTW... Anytime someone uses the word "obviously" its not. Lot''s of security people share techniques and information. That''s how we improve security. We learn from each other.> It is also apparent that many people who run Linux systems do not > really know much about security or where to keep track of bugs and > updates which makes Linux a prime target not to mention it''s > popularity!To make this statement about Linux and not say it about everyone is totally bogus. I''m sorry, but we run into people who have not patched Solaris, SunOS, AIX, HP/UX, and IRIX systems with patches from years ago. That DNS problem affected everyone running those versions of bind. Sun Microsystems sat on the socket bug that Alan Cox reported to them for over a year! We are just finally getting some of these companies conditioned to NOT bury security problems and hope no one else finds out. We still have a long way to go with the end users. How do you EXPLAIN to these people that FINGER is a security hole that needs to be plugged! Even if they are not using it, people using all walks of UNIX leave it turned on, just because it''s there out of the box. Most flavors of UNIX (and Windows, it turns out) are pretty much vulnerable to sequence number prediction. That can be great fun if you want to forge stuff (let''s hope the spammers don''t figure that trick out). Or how about ftp bounce attacks. Yeah buddy. That one''s a fun one on lots of systems (other than newer distributions of Linux). Think those sysadmins rush right out and patch those systems? Not. It''s really quite discusting to see some of them get upset when they get hit by a security scan and all of these violations show up. Like a child caught with his hand in the cookie jar, it''s the fault of the scanner that he got his butt in trouble for not keeping his system up to date.> Saying that though, if a DNS was behind a firewall that let ONLY DNS > though and nothing else except from maybe specified IP addresses then > the chance of being done would be substantially reduced.Oh oh... Someone''s forgetting about spoofing... :-)> [mod: Not this time. A cracker having root-access (through the DNS > bug) will not be stopped by a few firewall rules saying only DNS is > going to go in. Sure having access to "telnet" into the machine is a > bit more comfortable, but root-access through DNS is good enough to > subvert the whole machien. --REW]Sorry about the rant. It just raises the hair on the back of my neck when I hear some "hide it! hide it! hide it!" individual complains that publicly available sources were somehow a security risk. A security professional should know better (assuming that''s what this person is).> [mod: Whole article reformatted. -REW]> -- > Leigh Porter> -- > ---------------------------------------------------------------------- > Please refer to the information about this list as well as general > information about Linux security at http://www.aoy.com/Linux/Security. > ---------------------------------------------------------------------- > > To unsubscribe: > mail -s unsubscribe linux-security-request@redhat.com < /dev/nullMike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Another solution I know of is employed by a friend working for a bank in the US. They use encrypting modems, end to end. The client-side modem requires an inserted key card to activate. This may be overkill for the application, and then again, it may not. But it is a handy thing to know is out there. Dale Babiy, Network & Integration Specialist, Yukon Territorial Govt, Dept of Education -----Original Message----- [mod: -- Deleted by moderator -- REW :-]
Michael H. Warfield wrote:> Is any of this 100% fool proof. No. It doesn''t have to be. > You should understand more about your system than the person trying > to break into it. If your preventative measure slow him down enough > that he eventually trips over some of your alarm measures, changes > are very good that you will catch anyone attempting to tamper with > the system. You can layer on enough security perimeters, check > points, auditing, alarms, etc, etc, etc to make a system a pretty > tough nut to crack even if they KNEW what you had on the system.Yes but most admins do not understand more than the attacker, like with systemsthat come pre-configured to gateway SMTP mail to the whole net, systems need to be supplied with security-aware defaults.> Having an OS with a publicly available kernel source is a > security advantage.It can also be a dis-advantage, see below. Wether the advantages of publicallyavaliable source (Security flaws get found sooner, fixed sooner) or the advantages of ono=publically avaliable source (Flaws may never get found, but if they do may take forever to get fixed) are better, well..> The only way the individual who published the three "getadmin" > Windows NT exploits could have known about those three archane tricks > (one was writing to a peculiar offset off of a global structure) was to > have some sort of sources (not that anyone would admit that). As soon as > one was fixed, he posted the next. They were just a little too "peculiar" > in what they exploited.Yes, this was odd. MS has liscenced the NT source to quite a few companies now, itwould not take much for the source to leak out. This is a problem of attackers having access to source nobody else has access to, obviously putting them at an advantage!> Just because YOU, Joe Blow public, doesn''t have sources, it > doesn''t mean those same sources are not available to the crackers. > Ever take a peek at some the the hacker/cracker "toolz" CD''s. Don''t > believe that they don''t have sources to a lot of this stuff...NT kernel source code on a "toolz" cd ;-) That would be interesting!> BTW... Anytime someone uses the word "obviously" its not. Lot''s > of security people share techniques and information. That''s how we improve > security. We learn from each other.I did not mean not sharing techniques and information, I meant the generalsecurity overview - we have this firewall here, this acl there etc. Sharing information is not like sharing company security policy!> > It is also apparent that many people who run Linux systems do not > > really know much about security or where to keep track of bugs and > > updates which makes Linux a prime target not to mention it''s > > popularity! > > To make this statement about Linux and not say it about everyone > is totally bogus.Ok sorry, I cannot disagree here!> Oh oh... Someone''s forgetting about spoofing... :-)Ok so people can spoof, still, a peopery configured router/firewall is better than nothing.> Sorry about the rant. It just raises the hair on the back > of my neck when I hear some "hide it! hide it! hide it!" > individual complains that publicly available sources were somehow a > security risk. A security professional should know better (assuming > that''s what this person is).I am not a security professional :) I am not a hide it person, publically avaliable source code has done more for Linux than anything else, apart from maybe the hundreds of people who have coded for it. Publically avaliable source does however mean that it is a lot easier for people to find security flaws in the OS, if the source code is sealed behind closed doors then the security flaws that are there may never be found then again when they are found they will take a long time to be patched and may never be patched! [mod: Reformatted.... Please take the time to make your posts readable.... Even with vi, it''s just a few minutes of work, and it''s worth it if you''re going to share the output with thousands of others. -- REW] -- Leigh Porter
There was a company up here that supplied on the fly data encryption and compression via a modified router. It was called the "Warp" box. They used 3des encryption, and I think a gzip(Lempel-Ziv LZ77) compression algorithm. Though I think this company is being dissolved, it was quite a nice feature for people with 56k links which would get their total throughput boosted, and fairly secure.> Another solution I know of is employed by a friend working for a bank in > the US. They use encrypting modems, end to end. The client-side modem > requires an inserted key card to activate. This may be overkill for the > application, and then again, it may not. But it is a handy thing to > know is out there.Isn''t this something like a SecureID type system? Regards.
> Publically avaliable source does however mean that it is a lot easier > for people to find security flaws in the OS, if the source code is > sealed behind closed doors then the security flaws that are there may > never be found then again when they are found they will take a long > time to be patched and may never be patched!Most, if not all of the Unix based operating system vendors HAVE licensed their source code to companies willing to pay. This in turn has caused it to get out on the internet, if you have the proper connections, it is not hard to get your hands on.
At 18:47 12/05/98 -0400, you wrote:>With the number of insecure machines out there, unless you had some REALLY >valuable data, I can''t see a hacker going through enough trouble to >rewrite parts of the kernel to cover their tracks. I think it they would >probably just go find a less secure machine.I disagree, to an extend. Hacking an insecure machine is not a challenge, experimented hackers like difficulty. Furthermore, it is a good thing to experience on not sensible servers some attack scheme to reproduce them on major servers, that do not have the same sense of humor. Anyway, if you are really hacked by a l33t hacker, he will not damage your system, and he may even mail you a fix if he is in a good mood. It is oubvious that if you are the keeper of valuable data, you cannot even allow such intrusion. Of course, those who just try /cgi-bin/php?/etc/passwd and classic holes without really understanding what they are doing will not cause you problem if you are doing your job seriously. But, well, I have seen military servers that let the shadowed password file accessible via anonymous ftp (and the passwords worked), so I suppose everything is possible... --- ArthaXerxes - network hacker/hunter Evaluation of your security for free and without any prior request. ArthaXerxes'' Archive > http://altern.org/xerxes/ SMI FAQ bêta > http://altern.org/xerxes/smi/
Quetzacoatl KukulKhan
1998-May-27 15:05 UTC
Re: [linux-security] Re: Checking remote servers
ArthaXerxes wrote:> I disagree, to an extend. > Hacking an insecure machine is not a challenge, experimented hackers > like difficulty. Furthermore, it is a good thing to experience on > not sensible servers some attack scheme to reproduce them on major > servers, that do not have the same sense of humor.Some youngsters out there only know a little bit about network and UNIX, then visit security site outside there, http://rootshell.com or whatever, found some script/programs compile and simply run them. When they found some errors in the program, their feet get numbed. Then they simply claim themselves hacker? Do you guys agree with that claim? Kukulkhan NetSecure UTM [mod: As we all know, there are different requirements for securing different machines. As we all know there are different types of crackers. So, lets cut out the "I think all crackers are xxyyzz" discussion OK? --REW]
>> application, and then again, it may not. But it is a handy thing to >> know is out there.>Isn''t this something like a SecureID type system?No, SecureID is merely a one time password system for people not swift enough to handle S/Key :). That''s basically what it is. The little card you carry around has a function such that f(time)=x. Your server computes f(time)=x, f(time-1)=x1 f(time+1)=X2. This way it creates a ''window'' of possible passwords, and can keep track of clock drift on your token card. Time is measured in 60 second windows normally. An elegant solution and it looks very impressive to people whom you are trying to convince you are secure :). You append a PIN to the front of it, so that if someone simply steals your token you''re safe, but it doesn''t do any encryption, etc... The solution I was referring to on the other hand is a modem set that has an encryption alg implemented. The client''s key is stored in the card. It should be totally transparent to any end applications/authentication mechanisms. You could in fact run SecureID over it. Cheers/Dale
Joey Mitchell Comeau
1998-May-27 16:30 UTC
Re: [linux-security] Re: Checking remote servers
Hi there. just a quick note.> Anyway, if you are really hacked by a l33t hacker, he will not damage your > system, and he may even mail you a fix if he is in a good mood.That is a gross generalization. Just because someon has (well, whatever it is that hackers have, be it talent or just technical knowledge.) does not mean that they will all fit the same moral profile. There are plenty of talented assholes out there. they may even outnumber your "l33t hacker" ''s> It is oubvious that if you are the keeper of valuable data, you cannot even > allow such intrusion.Nor can you stop it before it happens. New security holes and bugs are found all the time. Odds are that someone out there(leet''s?) will know about them before it gets posted to bug-traq or linux-security. But you should take all the precautions you can if you are in charge of confidential valuble info.(or it shouldn''t be available via the net. standalones are the only 100% unhackable computer types i know.)> Of course, those who just try /cgi-bin/php?/etc/passwd and classic holes > without really understanding what they are doing will not cause you problem > if you are doing your job seriously.I believe that it is phf :P If you are doing your job seriously phf would not be there. and your /etc/passwd would be shadowed.> But, well, I have seen military servers that let the shadowed password file > accessible via anonymous ftp (and the passwords worked), so I suppose > everything is possible...Why wouldn''t they? Joey Comeau. aw096@chebucto.ns.ca
At 17:10 26/05/98 -0600, you wrote:>> Publically avaliable source does however mean that it is a lot easier >> for people to find security flaws in the OS, if the source code is >> sealed behind closed doors then the security flaws that are there may >> never be found then again when they are found they will take a long >> time to be patched and may never be patched! > >Most, if not all of the Unix based operating system vendors HAVE licensed >their source code to companies willing to pay. This in turn has caused it >to get out on the internet, if you have the proper connections, it is not >hard to get your hands on.It is true I have seen many more security holes on Linux (generally speaking) than on AIX or HPUX. I think it''s because : - you can install Linux at home and play with it for free. It implies many more people know Linux. It also allows hackers to do tests at home. - Linux is more used than AIX (for example), so there are more chances one will find a hole. - Also, commercial Unix are generally runned by big companies (I said "generally"), so they also "generally" try to hire skilled people, (Especially Banks, Banks just love AIX) but I have seen some exceptions. On the other hand, a lot of people just run Linux with only the help of a book and good willing people. - The fact commercial Unix are used by big companies also affraid a bit the average hacker. Protect your system and replace "Linux 2.0.34" by "AIX - bouh !" :-) You can not imagine how much the way your server look can prevent lamers from doing attacks. Really, when they see the linux prompt they think that they have the same system at home... Psychology is essential in security. (cf Social Engineering) [mod: And -=I=- think it is because you don''t -=SEE=- as many AIX/HPUX bugs as you see about Linux. Many of the bugs are present in all versions, even AIX/HPUX. Currently some of the Linux alerts go out, deliberately not mentioning that AIX/Solaris/HPUX are vulnerable too. Because those (poor :-) guys didn''t have a fix yet. -- REW] Of course the l33t fellow will just hack you and change your motd, reducing your honour to nothing before the very eyes of your users. Considering bugs, well except BIG bugs, if your system is well administred, it does not cause much problems. (Well administrated does not imply Nazi Security. :-) Furthermore, I think it is more clever to concentrate on classic security flaws since advanced security flaws will only be exploited by skilled hackers, and you will not face them often. And after all, the only security hole is the human. (do not flame me because I have said "AIX" and "HPUX". It exists you know :-) --- ArthaXerxes - network hacker/hunter Evaluation of your security for free and without any prior request. ArthaXerxes'' Archive > http://altern.org/xerxes/ SMI FAQ b=EAta > http://altern.org/xerxes/smi/