[SECURITY] [DSA-308-1] New gzip packages fix insecure temporary file creation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 308-1 [EMAIL PROTECTED] http://www.debian.org/security/ Matt Zimmerman June 6th, 2003 http://www.debian.org/security/faq - -- Package: gzip Vulnerability : insecure temporary files Problem-Type : local Debian-specific: no CVE Ids: CVE-1999-1332, CAN-2003-0367 Paul Szabo discovered that znew, a script included in the gzip package, creates its temporary files without taking precautions to avoid a symlink attack (CAN-2003-0367). The gzexe script has a similar vulnerability which was patched in an earlier release but inadvertently reverted. For the stable distribution (woody) both problems have been fixed in version 1.3.2-3woody1. For the old stable distribution (potato) CAN-2003-0367 has been fixed in version 1.2.4-33.2. This version is not vulnerable to CVE-1999-1332 due to an earlier patch. For the unstable distribution (sid) this problem will be fixed soon. We recommend that you update your gzip package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1.dsc Size/MD5 checksum: 577 affc0d3b073378cd2dc13c2a6772810a http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1.diff.gz Size/MD5 checksum: 5554 abd3dee3183d8c20f58c792206cec6e5 http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2.orig.tar.gz Size/MD5 checksum: 311011 57bff96b6b4bcbb060566bdbed29485d Alpha architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_alpha.deb Size/MD5 checksum:76240 8b1022a3708b29162831ae85307cb4de ARM architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_arm.deb Size/MD5 checksum:68538 8f640e909866da6602c2854375fa3b70 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_i386.deb Size/MD5 checksum:61868 a224c831e1a801e980801b63fde5a031 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_ia64.deb Size/MD5 checksum:86622 67e08c2b9b1011544b8303376f920df7 HP Precision architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_hppa.deb Size/MD5 checksum:72366 334d7a9b874026c95ea4a3b37b693691 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_m68k.deb Size/MD5 checksum:61134 0e8cc087cfb00ec478c48c6f0b177ea1 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_mips.deb Size/MD5 checksum:71524 acc8077c42714b77a73e55ae77a6493f Little endian MIPS architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_mipsel.deb Size/MD5 checksum:71388 c81151864b2453826712ac969e73535c PowerPC architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_powerpc.deb Size/MD5 checksum:69062 91de386eef5133dbd777934a3ff6668f IBM S/390 architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_s390.deb Size/MD5 checksum:66508 391497f880223b95fbf2b6b3d72160eb Sun Sparc architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.3.2-3woody1_sparc.deb Size/MD5 checksum:70058 3c9c0854327fec243b228108ec29f4b8 Debian GNU/Linux 2.2 alias potato - - Source archives: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.2.4-33.2.dsc Size/MD5 checksum: 542 0c5d9c072d3b99c09cf139799b1c1031 http://security.debian.org/pool/updates/main/g/gzip/gzip_1.2.4-33.2.diff.gz Size/MD5 checksum:10142 0cec25832d0eaff865a27489f0757d8b http://security.debian.org/pool/updates/main/g/gzip/gzip_1.2.4.orig.tar.gz Size/MD5 checksum: 220976 b94b3e07797e0cbf3622bb2fe5682f0b Alpha architecture: http://security.debian.org/pool/updates/main/g/gzip/gzip_1.2.4-33.2_alpha.deb Size/MD5 checksum:78936 a17b1e7130835c9f08bec9b0ff715bb1 ARM architecture:
[SECURITY] [DSA-309-1] New eterm packages fix buffer overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 309-1 [EMAIL PROTECTED] http://www.debian.org/security/ Matt Zimmerman June 6th, 2003 http://www.debian.org/security/faq - -- Package: eterm Vulnerability : buffer overflow Problem-Type : local Bugtraq ID : 7708 bazarr discovered that eterm is vulnerable to a buffer overflow of the ETERMPATH environment variable. This bug can be exploited to gain the privileges of the group utmp on a system where eterm is installed. For the stable distribution (woody), this problem has been fixed in version 0.9.2-0pre2002042903.1. The old stable distribution (potato) is not affected by this bug. For the unstable distribution (sid) this problem will be fixed soon. We recommend that you update your eterm package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1.dsc Size/MD5 checksum: 580 93e4f7a311340b12531333ab0606ef86 http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1.tar.gz Size/MD5 checksum: 669179 c749cbc4b08e75892d2f1c7184c91845 Alpha architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_alpha.deb Size/MD5 checksum: 389906 382018a77b71a278eaef04472caf604d ARM architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_arm.deb Size/MD5 checksum: 374132 731d78fcaef37260c19a892a09aec8dd Intel IA-32 architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_i386.deb Size/MD5 checksum: 332332 62c775be2dc796a881667cac80bf69a8 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_ia64.deb Size/MD5 checksum: 450196 7ec5a565f8939f8a4f6ad87b83e895cf HP Precision architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_hppa.deb Size/MD5 checksum: 390204 6f29ccd6ad78296fc1646df68ecbd803 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_m68k.deb Size/MD5 checksum: 336852 95830a081e2c990d2ec6a67a27d5b7f6 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_mips.deb Size/MD5 checksum: 335768 7fc79db933e042e409c96298b326c0b1 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_mipsel.deb Size/MD5 checksum: 335020 a93317df7718a0d4825a3625cd3caa45 PowerPC architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_powerpc.deb Size/MD5 checksum: 365208 5f2735b435d7a63a46787033340d8e35 IBM S/390 architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_s390.deb Size/MD5 checksum: 356098 118b70aa96874ec4215949a48776b2e3 Sun Sparc architecture: http://security.debian.org/pool/updates/main/e/eterm/eterm_0.9.2-0pre2002042903.1_sparc.deb Size/MD5 checksum: 368856 bc4c4ebf144a4e9f2ae7001f0726aaff These files will probably be moved into the stable distribution on its next revision. - - For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: [EMAIL PROTECTED] Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+4UkXArxCt0PiXR4RAjVtAKC2BMaMiMqxoGRvnS1I1ErCnky/NACfSDyx fIXPBrUJ7KP1xsTwAU9G4UQ= =h+rg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote: We'd like to protect that content, so that even if someone unplugs the machine and connects the HD to another Linux box, they can't access that information. Of course it's difficult to do, but we think there might be a possibility to achieve success. Against a sophisticated attacker, it's totally impossible to do what you want. They could run bochs an boot the x86 emulator from the new hard drive, and examine the contents of the system's memory whenever they wanted. Obviously, that's not easy, since you have to figure out where the encryption key is in memory (if that's what you used to protect the drive). From a practical point of view, if you just want to defend against casual attackers, encryption might do the trick. Use an encrypted filesystem, and hide the key somewhere in the kernel or something else outside the encrypted FS. When the system boots, it gets the key and uses it to mount the drive. It you add some code to the kernel to hide an obfuscated key in memory, and maybe make it available by reading /proc/sekret, or a char device, you could have the system boot up without requiring a password (which would be no good, because whoever has the password could use it when they move the drive to another machine.) Err, just thought of a problem with this: The kernel is GPLed, so you are required to give a copy of the source to anyone with a copy of the binary. Given that, they'd know where to look in the kernel binary for the key, even if the source you supplied has the secret key changed to something else. You'd have to embed the secret key into something else. (Linus apparently has no problem with binary-only kernel modules, so that's an option!) The trick to all this is not to give away where to look for the key in any boot scripts or initial ramdisk that could be read by putting the disk in another machine. A line like /bin/gen-password | mount -o loop ... pretty much gives the game away. I guess the best way really is to stash stuff in the kernel, since then you'll at least know who's asking for the source. Still, a script reading from /proc/sekret is a giveaway. If someone put the drive in another machine, they could edit the boot scripts so that it printed out the password. Then, you could boot from the drive, get the password, then put the drive back into another computer and mount the encrypted filesystem. So, all you can really do is make things tricky for people who aren't experts, and hopefully don't find this message with google. :) Here's what I suggest, after having thought about it while writing this message: Use an initrd. Scramble it by XORing it with a pattern[1]. Hack the kernel so it descrambles it at boot time. Put the password in the initrd, or in the kernel. (Even if you put the password in the kernel, you want to hide the initrd, because it will have mount(8) getting a password from /proc/sekret, or something.) Use some sort of encrypted filesystem on the hard drive. [1]using strong encryption wouldn't matter, because it's just as easy to disassemble the part of the kernel that unscrambles it to get the key is the same amount of work as finding out what it's XORed with, unless they figure it out from known-plaintext (the GZIP header). Make sure your pattern's not too short, so they have to disassemble the kernel or ask you for the source. If you know who's asking for the source, that's much better than not knowing who's hacking your work. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , s.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
You can encode your php scripts (in standalone cgi mode or apache served) with the open source gpl php encoder/optimizer turck mmcache. The readme says that the encoding it's not recommended for production use yet, but it works like a charm. Good Luck, Koba On Thu, 5 Jun 2003 09:30:51 +0200, Luis Gomez - InfoEmergencias [EMAIL PROTECTED] wrote: Hello world... In my company, we've been working for some months in what I consider a rather interesting product... but well, this mail is not spam ;) Seriously, the fact is this: we are going to install Linux servers in some companies, in order to serve mail, files, databases... We have developed a complete control panel in HTML and PHP, accessing MySQL databases and using some selfmade scripts that pickup the data in the MySQL db and transform these data into the config files of each service. We'd like to protect that content, so that even if someone unplugs the machine and connects the HD to another Linux box, they can't access that information. Of course it's difficult to do, but we think there might be a possibility to achieve success. So the question is obvious: could someone shine a light in our path? :-) TIA The Pope -- Koba -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
Against a sophisticated attacker, it's totally impossible to do what you want. They could run bochs an boot the x86 emulator from the new hard drive, and examine the contents of the system's memory whenever they wanted. Obviously, that's not easy, since you have to figure out where the encryption key is in memory (if that's what you used to protect the drive). I'd just like to add that you could try not storing the key on the machine at all. You could encrypt the content drives only, that way the system can boot by itself but can't decrypt the data until you login manually (ssh) and decrypt the drives by hand. The obvious disadvantage is of course that your data will be unavailable every time the system gets rebooted until you get a chance to login. Again, it's not a perfect solution but i think it adds another significant hurdle for the cracker. The trick then becomes figuring out if your system has been trojaned or is running in an emulator after a reboot... -ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
Hey there, --On Thursday, June 05, 2003 11:14:36 AM +0200 Marcel Weber [EMAIL PROTECTED] wrote: Luis Gomez - InfoEmergencias wrote: We're already looking at that (btw, IIRC loop-aes is included into the cryptoapi of kerneli.org). The problem is what Dariush points: if your machine has the pass to mount the filesystem, someone can put the HD in another machine, remove the root password, put the HD back in my original server, boot it, login as root and access whatever content we have there. Or just find the script that mounts the ciphered filesystem, look at its password and mount the ciphered fs himself :-( What about taking some computer / server specific things to generate the password? Say, the mac address of the NIC, the CPUs ID, some other stuff from the bios? Take all this things, make a md5 hash and use it as password. Of course, it would not be very secure, as anyone that has access to the computer could figure out how this password is put together. It would rather be security by obscurity... The built in certificates of a TWCP (or whatever it is called, you know the hardware side of these palladium stuff) would come handy for such a purpose... Making the encryption key hardware dependent would make it a hard job to decrypt the harddrive in another computer... On the other hand - what will you do if your server gets a hardware problem and you have to replace/expand the system with a new NIC, add another CPU, exchange anything in the box. So after a simple hardware problem all your own data is lost as well, even if the harddrive is not having any problems. Just my 2 cents. :-) Harry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
Think about this: Use a encrypted loopback. To get the key without storing it on the computer: Get some kind of unique combined fingerprint of the computer and hd through a c/c++ programmed algorithm and sending them to a secure password server using some kind of (variable server provided salt) hashing with md5. The server can encrypt the loopback KEY using the fingerprint as a passphrase and send it sniff safe. Isn't this going to safe enought for some cases? -- Koba On Thu, 5 Jun 2003 12:16:21 -0300, Peter Cordes [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote: We'd like to protect that content, so that even if someone unplugs the machine and connects the HD to another Linux box, they can't access that information. Of course it's difficult to do, but we think there might be a possibility to achieve success. Against a sophisticated attacker, it's totally impossible to do what you want. They could run bochs an boot the x86 emulator from the new hard drive, and examine the contents of the system's memory whenever they wanted. Obviously, that's not easy, since you have to figure out where the encryption key is in memory (if that's what you used to protect the drive). From a practical point of view, if you just want to defend against casual attackers, encryption might do the trick. Use an encrypted filesystem, and hide the key somewhere in the kernel or something else outside the encrypted FS. When the system boots, it gets the key and uses it to mount the drive. It you add some code to the kernel to hide an obfuscated key in memory, and maybe make it available by reading /proc/sekret, or a char device, you could have the system boot up without requiring a password (which would be no good, because whoever has the password could use it when they move the drive to another machine.) Err, just thought of a problem with this: The kernel is GPLed, so you are required to give a copy of the source to anyone with a copy of the binary. Given that, they'd know where to look in the kernel binary for the key, even if the source you supplied has the secret key changed to something else. You'd have to embed the secret key into something else. (Linus apparently has no problem with binary-only kernel modules, so that's an option!) The trick to all this is not to give away where to look for the key in any boot scripts or initial ramdisk that could be read by putting the disk in another machine. A line like /bin/gen-password | mount -o loop ... pretty much gives the game away. I guess the best way really is to stash stuff in the kernel, since then you'll at least know who's asking for the source. Still, a script reading from /proc/sekret is a giveaway. If someone put the drive in another machine, they could edit the boot scripts so that it printed out the password. Then, you could boot from the drive, get the password, then put the drive back into another computer and mount the encrypted filesystem. So, all you can really do is make things tricky for people who aren't experts, and hopefully don't find this message with google. :) Here's what I suggest, after having thought about it while writing this message: Use an initrd. Scramble it by XORing it with a pattern[1]. Hack the kernel so it descrambles it at boot time. Put the password in the initrd, or in the kernel. (Even if you put the password in the kernel, you want to hide the initrd, because it will have mount(8) getting a password from /proc/sekret, or something.) Use some sort of encrypted filesystem on the hard drive. [1]using strong encryption wouldn't matter, because it's just as easy to disassemble the part of the kernel that unscrambles it to get the key is the same amount of work as finding out what it's XORed with, unless they figure it out from known-plaintext (the GZIP header). Make sure your pattern's not too short, so they have to disassemble the kernel or ask you for the source. If you know who's asking for the source, that's much better than not knowing who's hacking your work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
Harry Brueckner wrote: On the other hand - what will you do if your server gets a hardware problem and you have to replace/expand the system with a new NIC, add another CPU, exchange anything in the box. So after a simple hardware problem all your own data is lost as well, even if the harddrive is not having any problems. Just my 2 cents. :-) Forget my backup mail, except that even encrypted data should be backuped, except if it is data, that can be restored with no hassles... Seriously: I read, that only the configuration files have to be protected and not the user data itself. As the creation of the configuration data is an automated job, you could easily restore the system after a upgrade. The following scenario would be possible: - One central configuration server - On boot up the client initializes an encrypted /etc or whatever using a special hardware dependent password - The actual configuration files get copied in a secure way (for example scp) from the configuration server to the client using a certificate, that is stored in the protected area. This works as long as no hardware is changed. In the case of a hardware change, it would be no big deal doing an automatic recreation of the encrypted filesystem, with some special boot disk, that creates a new encrypted file system with the right hardware key. Even this would be secure as for a successful recreation you would need the right certificate to get the config files from the configuration server. Regards Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
On Thu, Jun 05, 2003 at 12:53:43PM -0300, Koba wrote: Think about this: Use a encrypted loopback. To get the key without storing it on the computer: Get some kind of unique combined fingerprint of the computer and hd through a c/c++ programmed algorithm and sending them to a secure password server using some kind of (variable server provided salt) hashing with md5. The server can encrypt the loopback KEY using the fingerprint as a passphrase and send it sniff safe. Isn't this going to safe enought for some cases? If the attacker runs it under an x86 emulator like bochs, they don't need to sniff the network, just look at memory after it's decrypted. Also, what I suggested was an attempt to avoid dependence on a network. I'd be pretty unhappy if I bought something that required a connection to some authentication server before it would decide to function for me. Going too far with this risks pissing off people who had no plans to hack the thing, but dislike the explicit distrust of them. I mean, that's as bad as buying a DVD and finding out that it's illegal to watch it on a GNU system... You don't want to make your clients feel like you think they're criminals, or your adversaries. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , s.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
On Thu, 5 Jun 2003 14:15:45 -0300, Peter Cordes [EMAIL PROTECTED] wrote: If the attacker runs it under an x86 emulator like bochs, they don't need to sniff the network, just look at memory after it's decrypted. Also, what I suggested was an attempt to avoid dependence on a network. I'd be pretty unhappy if I bought something that required a connection to some authentication server before it would decide to function for me. Going too far with this risks pissing off people who had no plans to hack the thing, but dislike the explicit distrust of them. I mean, that's as bad as buying a DVD and finding out that it's illegal to watch it on a GNU system... You don't want to make your clients feel like you think they're criminals, or your adversaries. The idea is that if the attacker uses an x86 emulator the machine fingerprint won't be the same, there must be some way get a different one. I think there are some scenarios where this may be applicable. Server renting is not something strange here. -- Koba -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users - THANKS!!
Good evening (here in Spain) to all of you. I want to sincerely thank you all for the great feedback received on this topic. I would never have expected to receive some 20 answers in such a short time! Let me take my time to write your names, because you deserve it: Thank you Dariush, Adam, Marcel, Lars, Thomas, Peter, Harry, Koba, Ross, Adrian, and all the others who read the mail. We've seen lots of interesting points, some of which I'll comment now: - REMOTE PASSWORD SERVER. It avoids me from having to hardcode the cipher key somewhere in the filesystem, but presents two handicaps: What if they lose connection to the Net? and What if they put the HD in another machine, remove the root password, and put it back in the original machine? By doing this, the system would boot normally, would get the cipher key and mount the protected contents, and later they could login as root and access those contents. - CIPHER KEY BASED ON THE HARDWARE. They can still remove the root password and boot the drive again with its original hardware. Moreover it has the disadvantage of having to recalculate the password and recipher the container if any hardware component changes. I still have to study Marcel's point about Palladium. - MANUALLY ENTER THE PASSWORD LOGGING REMOTELY WHEN SYSTEM BOOTS UP. This one introduces the sixth sense of the sysadmin (i.e., me) who could take a look around before entering the pass (check that /etc/passwd is untouched, noone is logged in...). Even in that case the machine could have been trojanized, although we could check that point with software packages such as Tiger or Samhain (eh Javier!! ;D ) making it more difficult for a potential intruder to neutralize all of our monitoring tools. - TEMPORARILY MOUNT, LET PROGRAMS READ FILES INTO MEMORY, THEN UNMOUNT. Unfortunately this one isn't possible, as the protected data won't be config files for services, but rather .html and .php pages which need to be accessed very often. It was a good point, I must say. Other interesting things to look at: - LICENSING ISSUES. As Peter Cordes commented, the kernel is GPL so if we integrate code into it, we cannot provide a binary-only version, we should also give away the sources (or use modules, but we want a monolythic kernel for obvious security reasons). However I don't see the problem in thinking of something like this, implementing it, documenting, giving away to the community... and later configuring it for our particular needs, so that a client cannot (initially, at least) break it. I have to leave right now, and I'm taking a copy of this mail to discuss it with my colleagues. Will continue writing on the topic later or tomorrow, probably. Again, thanks to all for your great pieces of advice Yours The Pope - Luis Gomez -- Luis Gomez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users
W licie z czw, 05-06-2003, godz. 07:30, Luis Gomez - InfoEmergencias pisze: Hello! We'd like to protect that content, so that even if someone unplugs the machine and connects the HD to another Linux box, they can't access that information. Of course it's difficult to do, but we think there might be a possibility to achieve success. You have to understand that giving to someone physical access to the machine, You are in fact giving him all. All the software solutions to protect the contents could be just simply disassembled. So You can only make it more difficult i.e. by rewriting filesystem so it wont be understandable by other machines, changing boot code or doing something simmilar. But this solution has two sides: It will be much more difficult to support such device. If You want to protect Your code, You can use some kind of hardware keys to decrypt executables on the fly. Of course this is still not the perfect solution, because someone, can sniff decoded code and use it later. If You want be sure that no one will take out You code, You should implement some kind of autodestruction ( H2SO4, TNT, C4, small nuclear bomb etc...) which will destroy HDD (or all device), when someone will try to open the box. And please think about Open Source - this is also the way to make money. And You don't need to wory about the code securiy. Anyway good luck!!! -- Jaroslaw Tabor [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Scanning with reverse connections?
I've noticed some strange traffic on our firewalls recently. Someone (Or multiple someones) are attempting to send tcp packets inbound to our network FROM well known ports (e.g. port 80) to multiple port numbers, and usually multiple addresses as well. Sometimes they are randomised, (Port and/or target IP address), sometime sthey are sequential, or only one host etc. I'm seeing these from multiple IP addresses so it appears to be quite distributed. Is this a well known method? I've been searching and haven't found anything. I know it's not legitimate traffic because the hosts being scanning for don't actually have the ability to open these connections outbound, so they're not an expired connection in the firewall being caught... TIA Hamish. -- I don't suffer from Insanity... | Linux User #16396 I enjoy every minute of it... | | http://www.travellingkiwi.com/ | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scanning with reverse connections?
On Thu, Jun 05, 2003 at 08:29:10PM +0100, Hamish Marson wrote: I've noticed some strange traffic on our firewalls recently. Someone (Or multiple someones) are attempting to send tcp packets inbound to our network FROM well known ports (e.g. port 80) to multiple port numbers, and usually multiple addresses as well. Sometimes they are randomised, (Port and/or target IP address), sometime sthey are sequential, or only one host etc. I'm seeing these from multiple IP addresses so it appears to be quite distributed. Are you sure that you are not just looking at the packages being answered? For example when a user sends an HTTP request then one connection will be someting like: 10.0.0.1:12491 - 192.168.54.19:80 ...and the reply then would be... 192.168.54.19:80 - 10.0.0.1:12491 So most probably you see just the second. That's the way TCP works. Sequential port numbers may show up because the counter of used high-ports (1024 ff.) is just increased. Christoph -- ~ ~ .signature [Modified] 3 lines --100%--3,41 All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scanning with reverse connections?
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: I've noticed some strange traffic on our firewalls recently. Someone (Or multiple someones) are attempting to send tcp packets inbound to our network FROM well known ports (e.g. port 80) Some firewalls that don't do proper connection tracking can be bypassed that way. With a properly configured iptables firewall this shouldn't be a problem. ipchains based firewalls are more likely to fall victom to this trick. Treat it the same as any other attempt to break into your systems. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html Text is a way we cheat time. -- Patrick Nielsen Hayden -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel-source 2.4.20 + grsecurity + freeswan
Hi, currently I'm setting up a gateway machine for a small office network. After the recent threads about rooted woody boxes I feel it would be iresponsible to set up a box without a grsecurity patched kernel. The problem is I also need the box to be a VPN gateway. One of the reasons I got the deal was because I said IPSEC would be a good solution, so I don't want to back out and use another VPN option like openvpn. There seem to be problems using both the grsecurity and the freeswan patches (at least I haven't been successfull applying the patches - I tried the debian versions and the official ones from the different project sites of the patches and the kernel sources). Does anybody have debian/stable boxes running kernels with grsecurity and freeswan? Any hints/experiences to share? Is there another solution I'm missing that you would suggest? Google turned up plenty of hits, but I didn't find any solutions. Thank you and best regards, Vinai -- Secure eMail with gnupg: See http://www.gnupg.org/ pgp0.pgp Description: PGP signature
Re: Scanning with reverse connections?
On Thu, Jun 05, 2003 at 10:02:53PM +0200, Christoph Haas wrote: So most probably you see just the second. That's the way TCP works. Sequential port numbers may show up because the counter of used high-ports (1024 ff.) is just increased. No, it's not at all uncommon to see incoming traffic from well known ports. It's an easy way to bypass weakly configured firewalls. Snort can detect such activity. Nmap can generate it using the -g flag. Here's what the nmap man page has to say about it: -g portnumber Sets the source port number used in scans. Many naive firewall and packet filter installations make an exception in their rule- set to allow DNS (53) or FTP-DATA (20) packets to come through and establish a connection. Obviously this completely subverts the security advantages of the firewall since intruders can just masquerade as FTP or DNS by modifying their source port. Obvi- ously for a UDP scan you should try 53 first and TCP scans should try 20 before 53. Note that this is only a request -- nmap will honor it only if and when it is able to. For example, you can't do TCP ISN sampling all from one host:port to one host:port, so nmap changes the source port even if you used -g. I see it all the time. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgp0.pgp Description: PGP signature
Re: kernel-source 2.4.20 + grsecurity + freeswan
On Thursday 05 June 2003 22:32, Vinai Kopp wrote: Hi Vinai, There seem to be problems using both the grsecurity and the freeswan patches (at least I haven't been successfull applying the patches - I tried the debian versions and the official ones from the different project sites of the patches and the kernel sources). Does anybody have debian/stable boxes running kernels with grsecurity and freeswan? Any hints/experiences to share? http://sf.net/projects/wolk/ http://sourceforge.net/forum/forum.php?forum_id=272768 -- ciao, Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users - THANKS!!
On Thu, Jun 05, 2003 at 08:58:43PM +0200, Luis Gomez - InfoEmergencias wrote: Other interesting things to look at: - LICENSING ISSUES. As Peter Cordes commented, the kernel is GPL so if we integrate code into it, we cannot provide a binary-only version, we should also give away the sources (or use modules, but we want a monolythic kernel for obvious security reasons). However I don't see the problem in thinking of something like this, implementing it, documenting, giving away to the community... and later configuring it for our particular needs, so that a client cannot (initially, at least) break it. I suppose if you used a BSD system, you could do this kernel modification and not have to provide the source. The userland side of the system is going to be very similar. Geoff Crompton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-source 2.4.20 + grsecurity + freeswan
On Thu, Jun 05, 2003 at 10:32:59PM +0200, Vinai Kopp wrote: Hi, currently I'm setting up a gateway machine for a small office network. After the recent threads about rooted woody boxes I feel it would be iresponsible to set up a box without a grsecurity patched kernel. The problem is I also need the box to be a VPN gateway. One of the reasons I got the deal was because I said IPSEC would be a good solution, so I don't want to back out and use another VPN option like openvpn. There seem to be problems using both the grsecurity and the freeswan patches (at least I haven't been successfull applying the patches - I tried the debian versions and the official ones from the different project sites of the patches and the kernel sources). Does anybody have debian/stable boxes running kernels with grsecurity and freeswan? Any hints/experiences to share? Is there another solution I'm missing that you would suggest? Google turned up plenty of hits, but I didn't find any solutions. Thank you and best regards, Vinai You might want to have a look at adamantix.org. It is a woody based distro with freeswan, PAX, and RSBAC kernel patches, plus all the packages are compiled with the gcc stack smashing patch. -- Peter Hicks GnuPG public key: http://jah.net/~petong/public_key.txt Key Fingerprint: 4E24 3C78 A165 537C 729C 8D25 3547 3CE9 9E7D 42B6 There are no controlled substances, only controlled people. - Thomas Szasz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-source 2.4.20 + grsecurity + freeswan
Vinai == Vinai Kopp [EMAIL PROTECTED] writes: [...] Vinai There seem to be problems using both the grsecurity and the Vinai freeswan patches (at least I haven't been successfull applying Vinai the patches - I tried the debian versions and the official ones Vinai from the different project sites of the patches and the kernel Vinai sources). I have a Debian/sid machine running a 2.4.20 kernel with both patches applied (along with a whole bunch of other patches), and had no problems applying the patches. The patches and kernel sources I got from the sid repository maybe about a month ago. I would imagine that there shouldn't be much of an issue using the patches and kernel sources from sid on a stable box. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgp0.pgp Description: PGP signature
Re: Scanning with reverse connections?
Hamish Marson [EMAIL PROTECTED] writes: I've noticed some strange traffic on our firewalls recently. Someone (Or multiple someones) are attempting to send tcp packets inbound to our network FROM well known ports (e.g. port 80) to multiple port numbers, and usually multiple addresses as well. Most likely, that's backscatter from a DoS attack. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OPENSSL
Hi there I'm trying to generate a 40-bit certificate using OPENSSL.Can anybody tell me if this is possible and with which package? Thanx LeRoux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-source 2.4.20 + grsecurity + freeswan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have debian (stable) with a stock kernel from kernel.org (2.4.20) with FreeSwan 1.99 and grsecurity 1.99h. Worked without a problem so far. The order of pachtes was first FreeSwan, then grsec, if that makes any difference... Good luck, Peter - -- Dipl.-Ing. Peter Burgstaller Technical Director @ all information network services gmbh email: [EMAIL PROTECTED] phone: +43 662 452335 fax : +43 662 452335 90 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (Darwin) iEYEARECAAYFAj7gUwEACgkQezyUhHKdNXSClQCffrbGpuY7pVZ+iI7SeKdRaH/9 deUAn1++liaKV0fyE+KwJ9kBFsabWhjT =/Kgf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scanning with reverse connections?
Noah Meyerhans wrote: On Thu, Jun 05, 2003 at 10:02:53PM +0200, Christoph Haas wrote: So most probably you see just the second. That's the way TCP works. Sequential port numbers may show up because the counter of used high-ports (1024 ff.) is just increased. No, it's not at all uncommon to see incoming traffic from well known ports. It's an easy way to bypass weakly configured firewalls. Snort can detect such activity. Nmap can generate it using the -g flag. Here's what the nmap man page has to say about it: -g portnumber Sets the source port number used in scans. Many naive firewall and packet filter installations make an exception in their rule- set to allow DNS (53) or FTP-DATA (20) packets to come through and establish a connection. Obviously this completely subverts the security advantages of the firewall since intruders can just masquerade as FTP or DNS by modifying their source port. Obvi- ously for a UDP scan you should try 53 first and TCP scans should try 20 before 53. Note that this is only a request -- nmap will honor it only if and when it is able to. For example, you can't do TCP ISN sampling all from one host:port to one host:port, so nmap changes the source port even if you used -g. But does nmap generate the packets WITHOUT the SYN flag set? Which is what these are... I see it all the time. I used to see it a bit... Suddenly I'm seeing massive amounts of it... Are the skiddies getting bored ot what? Or is it just me that's seeing it? (ON a rather large site I admit. Anyone else on a large site seeing a large increase in stuff like this?). noah PS Chris. Like I said in the first email. It's not real responses, because in most cases you can see them scanning through ports/addresses and most of them don't exist... I ended up writing a script last night to watch the logs temporarily block them from ALL traffic to us when I see it... They seem to have quietened down again now... If I were more paranoid I'd say it was a geniuine (But reasonably lame) attempted at a DDOS... Hoipefully that's wrong they haven't just gone away to regroup gather more forces... -- I don't suffer from Insanity... | Linux User #16396 I enjoy every minute of it... | | http://www.travellingkiwi.com/ | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scanning with reverse connections?
Hamish Marson [EMAIL PROTECTED] writes: But does nmap generate the packets WITHOUT the SYN flag set? Which is what these are... In this case, it's probably backscatter. Could you tell us a few source/destination pairs? I could have a look at our flow database at work and look for similar incidents. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scanning with reverse connections?
On Fri, Jun 06, 2003 at 10:12:05PM +0200, Florian Weimer wrote: But does nmap generate the packets WITHOUT the SYN flag set? Which is what these are... In this case, it's probably backscatter. Could you tell us a few source/destination pairs? I could have a look at our flow database at work and look for similar incidents. I don't see any reason to assume that it's backscatter. Look at the Null scan mode of nmap. No flags (SYN, ACK, FIN, whatever) are set. Using that scan mode with a source port of something like 80 is going to get you through a lot of firewalls out there. I think it's far more likely that this is what you're seeing, especially if you're seeing it hit incrementing ports or IP addresses. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Default Apache install not fit for multiple domains/users
Okay, I already posted this message to debian-users, but please don't flame me - i just figured that maybe debian-security is the better place to post a request for help like this. Clearly enough this is a security concern, after all. So maybe you could be so kind and help me out on this one: I want to enable some friends of mine to host their web pages on my woody server. It has Apache LAMP running in great shape and it suits my Web page just fine. The Problem that I have now is, that the apache user is www-data. Well, I guessed I could just change the user permissions on the /var/www/path.to.site directories to the respective user names, but that doesnt do the trick, because then, all write permissions for cgi scripts for these diretories are gone, as they no longer belong to www-data. Nevertheless I just want my friends to stop go poking around in foreign web sites, and at the same time have access to perl/php scripting.Where do I go from here? I am not a particularly guru-like administrator, so I am a bit afraid of using setuid. After all I do not even know, if that would do the trick. All help is really, really appreciated very much. P.S.: I googled quite thoroughly, but couldn't get anywhere near my problem. Maybe I just used the wrong words, because I can't believe I am the only one with this problem Yours Truly, Toni -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Default Apache install not fit for multiple domains/users
Is there some reason why you can't give each user an account and have them put their files in ~/public_html? That would have their page show up at domain.net/~username/. Sorry if you already knew this and I'm misunderstanding the problem. On Sat, 07 Jun 2003 00:03:59 +0200 Juan Antonio Agudo [EMAIL PROTECTED] wrote: Okay, I already posted this message to debian-users, but please don't flame me - i just figured that maybe debian-security is the better place to post a request for help like this. Clearly enough this is a security concern, after all. So maybe you could be so kind and help me out on this one: I want to enable some friends of mine to host their web pages on my woody server. It has Apache LAMP running in great shape and it suits my Web page just fine. The Problem that I have now is, that the apache user is www-data. Well, I guessed I could just change the user permissions on the /var/www/path.to.site directories to the respective user names, but that doesnt do the trick, because then, all write permissions for cgi scripts for these diretories are gone, as they no longer belong to www-data. Nevertheless I just want my friends to stop go poking around in foreign web sites, and at the same time have access to perl/php scripting.Where do I go from here? I am not a particularly guru-like administrator, so I am a bit afraid of using setuid. After all I do not even know, if that would do the trick. All help is really, really appreciated very much. P.S.: I googled quite thoroughly, but couldn't get anywhere near my problem. Maybe I just used the wrong words, because I can't believe I am the only one with this problem Yours Truly, Toni -- Tim Cunningham I'm not claiming to be deep, I'm claiming to do it for fun. - Linus Torvalds pgp0.pgp Description: PGP signature
Re: Default Apache install not fit for multiple domains/users
Hi, On Sat, 07 Jun 2003 00:03:59 +0200, Juan Antonio Agudo writes: I want to enable some friends of mine to host their web pages on my woody server. It has Apache LAMP running in great shape and it suits my Web page just fine. The Problem that I have now is, that the apache user is www-data. Well, I guessed I could just change the user permissions on the /var/www/path.to.site directories to the respective user names, but that doesnt do the trick, because then, all write permissions for cgi scripts for these diretories are gone, as they no longer belong to www-data. There's no need to let the users have access to anything under /var/www. Personally, I would let each user use the personal directory feature of Apache. I don't recall the exact directives to enable it (but it's enabled by default, so if you didn't turn it off, it's there). If a client accesses http://your.domain.com/~foobar/index.html;, then Apache will get the file from /home/foobar/public_html/index.html (i.e. everything under the ~foobar URL comes from the public_html subdirectory of the foobar user's home directory. Each user can create a .htaccess file in their public_html directory to override the global settings. Each user can have their own public_access/cgi-bin directory (you may need to enable scripting from this directory either in your global httpd.conf or from that user's .htacces file). Finally, if you don't want the ugly ~foobar in the names, you should be able to use an alias in the global httpd.conf to get rid of it. --- Wade -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OPENSSL
Hi ! apt-get install openssl There is two text files in /usr/share/doc/openssl-(version)/docs/HOWTO Shows how to create an RSA key and a certificate request/self signed certificate ... []'s On Fri, 2003-06-06 at 05:27, Van Wyk Leroux, Mr wrote: Hi there I'm trying to generate a 40-bit certificate using OPENSSL.Can anybody tell me if this is possible and with which package? Thanx LeRoux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keeping files away from users - THANKS!!
From: Luis Gomez - InfoEmergencias [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Keeping files away from users - THANKS!! Date: Thu, 5 Jun 2003 20:58:43 +0200 MIME-Version: 1.0 Received: from murphy.debian.org ([146.82.138.6]) by mc5-f31.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Jun 2003 12:37:03 -0700 Received: from localhost (localhost [127.0.0.1])by murphy.debian.org (Postfix) with QMQPid 592B11F68B; Thu, 5 Jun 2003 14:15:46 -0500 (CDT) Received: from marianela.infoemergencias.com (221.Red-213-96-93.pooles.rima-tde.net [213.96.93.221])by murphy.debian.org (Postfix) with ESMTP id EB5001FB7Afor [EMAIL PROTECTED]; Thu, 5 Jun 2003 13:56:39 -0500 (CDT) Received: from adelita.infoemergencias.com (unknown [192.168.1.7])by marianela.infoemergencias.com (Postfix) with ESMTP id 840801323for [EMAIL PROTECTED]; Thu, 5 Jun 2003 20:58:39 +0200 (CEST) X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP Old-Return-Path: [EMAIL PROTECTED] Organization: InfoEmergencias User-Agent: KMail/1.5.2 References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] X-Spam-Status: No, hits=-17.7 required=4.0tests=BAYES_20,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, USER_AGENT_KMAILautolearn=ham version=2.53-lists.debian.org_2003_04_28 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-lists.debian.org_2003_04_28 (1.174.2.15-2003-03-30-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: [EMAIL PROTECTED] X-Mailing-List: [EMAIL PROTECTED] archive/latest/12214 X-Loop: [EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Thu, 5 Jun 2003 14:15:46 -0500 (CDT) Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 05 Jun 2003 19:37:03.0897 (UTC) FILETIME=[D751F890:01C32B99] Good evening (here in Spain) to all of you. I want to sincerely thank you all for the great feedback received on this topic. I would never have expected to receive some 20 answers in such a short time! Let me take my time to write your names, because you deserve it: Thank you Dariush, Adam, Marcel, Lars, Thomas, Peter, Harry, Koba, Ross, Adrian, and all the others who read the mail. We've seen lots of interesting points, some of which I'll comment now: - REMOTE PASSWORD SERVER. It avoids me from having to hardcode the cipher key somewhere in the filesystem, but presents two handicaps: What if they lose connection to the Net? and What if they put the HD in another machine, remove the root password, and put it back in the original machine? By doing this, the system would boot normally, would get the cipher key and mount the protected contents, and later they could login as root and access those contents. - CIPHER KEY BASED ON THE HARDWARE. They can still remove the root password and boot the drive again with its original hardware. Moreover it has the disadvantage of having to recalculate the password and recipher the container if any hardware component changes. I still have to study Marcel's point about Palladium. - MANUALLY ENTER THE PASSWORD LOGGING REMOTELY WHEN SYSTEM BOOTS UP. This one introduces the sixth sense of the sysadmin (i.e., me) who could take a look around before entering the pass (check that /etc/passwd is untouched, noone is logged in...). Even in that case the machine could have been trojanized, although we could check that point with software packages such as Tiger or Samhain (eh Javier!! ;D ) making it more difficult for a potential intruder to neutralize all of our monitoring tools. You could just make md5 checksums of the whole system and store the checksums on another machine/floppy disk or something of that nature. Then when you would like to remount the filesystem you could always verify the checksums to see if you are trojaned or not. - TEMPORARILY MOUNT, LET PROGRAMS READ FILES INTO MEMORY, THEN UNMOUNT. Unfortunately this one isn't possible, as the protected data won't be config files for services, but rather .html and .php pages which need to be accessed very often. It was a good point, I must say. Other interesting things to look at: - LICENSING ISSUES. As Peter Cordes commented, the kernel is GPL so if we integrate code into it, we cannot provide a binary-only version, we should also give away the sources (or use modules, but we want a monolythic kernel for obvious security reasons). However I don't see the problem in thinking of something like this, implementing it, documenting, giving away to the community... and later configuring it for our particular needs, so that a client cannot (initially, at least) break it. I have to leave right now, and I'm taking a copy of this mail to discuss it with my colleagues. Will continue writing on the topic later or tomorrow, probably. Again, thanks to all for your great pieces of advice
Re: Default Apache install not fit for multiple domains/users
On 06 Jun 2003 16:15:37 PDT, Jon writes: I believe Apache would still be executing php/cgi scripts as www-data, so users could snoop on other users's scripts, session files, etc. Something like: ?php echo `ls ../neighbor/public_html`; ? I suggest you look up the suEXEC Apache module, it seems to do exactly what you want. --- Wade -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scanning with reverse connections?
Hamish Marson [EMAIL PROTECTED] writes: I've noticed some strange traffic on our firewalls recently. Someone (Or multiple someones) are attempting to send tcp packets inbound to our network FROM well known ports (e.g. port 80) to multiple port numbers, and usually multiple addresses as well. Most likely, that's backscatter from a DoS attack.
OPENSSL
Hi there I'm trying to generate a 40-bit certificate using OPENSSL.Can anybody tell me if this is possible and with which package? Thanx LeRoux
Re: kernel-source 2.4.20 + grsecurity + freeswan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have debian (stable) with a stock kernel from kernel.org (2.4.20) with FreeSwan 1.99 and grsecurity 1.99h. Worked without a problem so far. The order of pachtes was first FreeSwan, then grsec, if that makes any difference... Good luck, Peter - -- Dipl.-Ing. Peter Burgstaller Technical Director @ all information network services gmbh email: [EMAIL PROTECTED] phone: +43 662 452335 fax : +43 662 452335 90 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (Darwin) iEYEARECAAYFAj7gUwEACgkQezyUhHKdNXSClQCffrbGpuY7pVZ+iI7SeKdRaH/9 deUAn1++liaKV0fyE+KwJ9kBFsabWhjT =/Kgf -END PGP SIGNATURE-
Re: Scanning with reverse connections?
Noah Meyerhans wrote: On Thu, Jun 05, 2003 at 10:02:53PM +0200, Christoph Haas wrote: So most probably you see just the second. That's the way TCP works. Sequential port numbers may show up because the counter of used high-ports (1024 ff.) is just increased. No, it's not at all uncommon to see incoming traffic from well known ports. It's an easy way to bypass weakly configured firewalls. Snort can detect such activity. Nmap can generate it using the -g flag. Here's what the nmap man page has to say about it: -g portnumber Sets the source port number used in scans. Many naive firewall and packet filter installations make an exception in their rule- set to allow DNS (53) or FTP-DATA (20) packets to come through and establish a connection. Obviously this completely subverts the security advantages of the firewall since intruders can just masquerade as FTP or DNS by modifying their source port. Obvi- ously for a UDP scan you should try 53 first and TCP scans should try 20 before 53. Note that this is only a request -- nmap will honor it only if and when it is able to. For example, you can't do TCP ISN sampling all from one host:port to one host:port, so nmap changes the source port even if you used -g. But does nmap generate the packets WITHOUT the SYN flag set? Which is what these are... I see it all the time. I used to see it a bit... Suddenly I'm seeing massive amounts of it... Are the skiddies getting bored ot what? Or is it just me that's seeing it? (ON a rather large site I admit. Anyone else on a large site seeing a large increase in stuff like this?). noah PS Chris. Like I said in the first email. It's not real responses, because in most cases you can see them scanning through ports/addresses and most of them don't exist... I ended up writing a script last night to watch the logs temporarily block them from ALL traffic to us when I see it... They seem to have quietened down again now... If I were more paranoid I'd say it was a geniuine (But reasonably lame) attempted at a DDOS... Hoipefully that's wrong they haven't just gone away to regroup gather more forces... -- I don't suffer from Insanity... | Linux User #16396 I enjoy every minute of it... | | http://www.travellingkiwi.com/ |
Re: Scanning with reverse connections?
Hamish Marson [EMAIL PROTECTED] writes: But does nmap generate the packets WITHOUT the SYN flag set? Which is what these are... In this case, it's probably backscatter. Could you tell us a few source/destination pairs? I could have a look at our flow database at work and look for similar incidents.
Re: Scanning with reverse connections?
On Fri, Jun 06, 2003 at 10:12:05PM +0200, Florian Weimer wrote: But does nmap generate the packets WITHOUT the SYN flag set? Which is what these are... In this case, it's probably backscatter. Could you tell us a few source/destination pairs? I could have a look at our flow database at work and look for similar incidents. I don't see any reason to assume that it's backscatter. Look at the Null scan mode of nmap. No flags (SYN, ACK, FIN, whatever) are set. Using that scan mode with a source port of something like 80 is going to get you through a lot of firewalls out there. I think it's far more likely that this is what you're seeing, especially if you're seeing it hit incrementing ports or IP addresses. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html
Default Apache install not fit for multiple domains/users
Okay, I already posted this message to debian-users, but please don't flame me - i just figured that maybe debian-security is the better place to post a request for help like this. Clearly enough this is a security concern, after all. So maybe you could be so kind and help me out on this one: I want to enable some friends of mine to host their web pages on my woody server. It has Apache LAMP running in great shape and it suits my Web page just fine. The Problem that I have now is, that the apache user is www-data. Well, I guessed I could just change the user permissions on the /var/www/path.to.site directories to the respective user names, but that doesnt do the trick, because then, all write permissions for cgi scripts for these diretories are gone, as they no longer belong to www-data. Nevertheless I just want my friends to stop go poking around in foreign web sites, and at the same time have access to perl/php scripting.Where do I go from here? I am not a particularly guru-like administrator, so I am a bit afraid of using setuid. After all I do not even know, if that would do the trick. All help is really, really appreciated very much. P.S.: I googled quite thoroughly, but couldn't get anywhere near my problem. Maybe I just used the wrong words, because I can't believe I am the only one with this problem Yours Truly, Toni
Re: Default Apache install not fit for multiple domains/users
Is there some reason why you can't give each user an account and have them put their files in ~/public_html? That would have their page show up at domain.net/~username/. Sorry if you already knew this and I'm misunderstanding the problem. On Sat, 07 Jun 2003 00:03:59 +0200 Juan Antonio Agudo [EMAIL PROTECTED] wrote: Okay, I already posted this message to debian-users, but please don't flame me - i just figured that maybe debian-security is the better place to post a request for help like this. Clearly enough this is a security concern, after all. So maybe you could be so kind and help me out on this one: I want to enable some friends of mine to host their web pages on my woody server. It has Apache LAMP running in great shape and it suits my Web page just fine. The Problem that I have now is, that the apache user is www-data. Well, I guessed I could just change the user permissions on the /var/www/path.to.site directories to the respective user names, but that doesnt do the trick, because then, all write permissions for cgi scripts for these diretories are gone, as they no longer belong to www-data. Nevertheless I just want my friends to stop go poking around in foreign web sites, and at the same time have access to perl/php scripting.Where do I go from here? I am not a particularly guru-like administrator, so I am a bit afraid of using setuid. After all I do not even know, if that would do the trick. All help is really, really appreciated very much. P.S.: I googled quite thoroughly, but couldn't get anywhere near my problem. Maybe I just used the wrong words, because I can't believe I am the only one with this problem Yours Truly, Toni -- Tim Cunningham I'm not claiming to be deep, I'm claiming to do it for fun. - Linus Torvalds pgphDC4NTR8kP.pgp Description: PGP signature
Re: Default Apache install not fit for multiple domains/users
Hi, On Sat, 07 Jun 2003 00:03:59 +0200, Juan Antonio Agudo writes: I want to enable some friends of mine to host their web pages on my woody server. It has Apache LAMP running in great shape and it suits my Web page just fine. The Problem that I have now is, that the apache user is www-data. Well, I guessed I could just change the user permissions on the /var/www/path.to.site directories to the respective user names, but that doesnt do the trick, because then, all write permissions for cgi scripts for these diretories are gone, as they no longer belong to www-data. There's no need to let the users have access to anything under /var/www. Personally, I would let each user use the personal directory feature of Apache. I don't recall the exact directives to enable it (but it's enabled by default, so if you didn't turn it off, it's there). If a client accesses http://your.domain.com/~foobar/index.html;, then Apache will get the file from /home/foobar/public_html/index.html (i.e. everything under the ~foobar URL comes from the public_html subdirectory of the foobar user's home directory. Each user can create a .htaccess file in their public_html directory to override the global settings. Each user can have their own public_access/cgi-bin directory (you may need to enable scripting from this directory either in your global httpd.conf or from that user's .htacces file). Finally, if you don't want the ugly ~foobar in the names, you should be able to use an alias in the global httpd.conf to get rid of it. --- Wade
Re: OPENSSL
Hi ! apt-get install openssl There is two text files in /usr/share/doc/openssl-(version)/docs/HOWTO Shows how to create an RSA key and a certificate request/self signed certificate ... []'s On Fri, 2003-06-06 at 05:27, Van Wyk Leroux, Mr wrote: Hi there I'm trying to generate a 40-bit certificate using OPENSSL.Can anybody tell me if this is possible and with which package? Thanx LeRoux
Re: Default Apache install not fit for multiple domains/users
On Fri, 2003-06-06 at 15:42, Tim Cunningham wrote: Is there some reason why you can't give each user an account and have them put their files in ~/public_html? That would have their page show up at domain.net/~username/. Sorry if you already knew this and I'm misunderstanding the problem. I believe Apache would still be executing php/cgi scripts as www-data, so users could snoop on other users's scripts, session files, etc. Something like: ?php echo `ls ../neighbor/public_html`; ? - Jon -- [EMAIL PROTECTED] Administrator, tgpsolutions http://www.tgpsolutions.com signature.asc Description: This is a digitally signed message part
Re: Keeping files away from users - THANKS!!
From: Luis Gomez - InfoEmergencias [EMAIL PROTECTED] To: debian-security@lists.debian.org Subject: Re: Keeping files away from users - THANKS!! Date: Thu, 5 Jun 2003 20:58:43 +0200 MIME-Version: 1.0 Received: from murphy.debian.org ([146.82.138.6]) by mc5-f31.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 5 Jun 2003 12:37:03 -0700 Received: from localhost (localhost [127.0.0.1])by murphy.debian.org (Postfix) with QMQPid 592B11F68B; Thu, 5 Jun 2003 14:15:46 -0500 (CDT) Received: from marianela.infoemergencias.com (221.Red-213-96-93.pooles.rima-tde.net [213.96.93.221])by murphy.debian.org (Postfix) with ESMTP id EB5001FB7Afor debian-security@lists.debian.org; Thu, 5 Jun 2003 13:56:39 -0500 (CDT) Received: from adelita.infoemergencias.com (unknown [192.168.1.7])by marianela.infoemergencias.com (Postfix) with ESMTP id 840801323for debian-security@lists.debian.org; Thu, 5 Jun 2003 20:58:39 +0200 (CEST) X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP Old-Return-Path: [EMAIL PROTECTED] Organization: InfoEmergencias User-Agent: KMail/1.5.2 References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] X-Spam-Status: No, hits=-17.7 required=4.0tests=BAYES_20,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, USER_AGENT_KMAILautolearn=ham version=2.53-lists.debian.org_2003_04_28 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-lists.debian.org_2003_04_28 (1.174.2.15-2003-03-30-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-security@lists.debian.org X-Mailing-List: debian-security@lists.debian.org archive/latest/12214 X-Loop: debian-security@lists.debian.org List-Post: mailto:debian-security@lists.debian.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Thu, 5 Jun 2003 14:15:46 -0500 (CDT) Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 05 Jun 2003 19:37:03.0897 (UTC) FILETIME=[D751F890:01C32B99] Good evening (here in Spain) to all of you. I want to sincerely thank you all for the great feedback received on this topic. I would never have expected to receive some 20 answers in such a short time! Let me take my time to write your names, because you deserve it: Thank you Dariush, Adam, Marcel, Lars, Thomas, Peter, Harry, Koba, Ross, Adrian, and all the others who read the mail. We've seen lots of interesting points, some of which I'll comment now: - REMOTE PASSWORD SERVER. It avoids me from having to hardcode the cipher key somewhere in the filesystem, but presents two handicaps: What if they lose connection to the Net? and What if they put the HD in another machine, remove the root password, and put it back in the original machine? By doing this, the system would boot normally, would get the cipher key and mount the protected contents, and later they could login as root and access those contents. - CIPHER KEY BASED ON THE HARDWARE. They can still remove the root password and boot the drive again with its original hardware. Moreover it has the disadvantage of having to recalculate the password and recipher the container if any hardware component changes. I still have to study Marcel's point about Palladium. - MANUALLY ENTER THE PASSWORD LOGGING REMOTELY WHEN SYSTEM BOOTS UP. This one introduces the sixth sense of the sysadmin (i.e., me) who could take a look around before entering the pass (check that /etc/passwd is untouched, noone is logged in...). Even in that case the machine could have been trojanized, although we could check that point with software packages such as Tiger or Samhain (eh Javier!! ;D ) making it more difficult for a potential intruder to neutralize all of our monitoring tools. You could just make md5 checksums of the whole system and store the checksums on another machine/floppy disk or something of that nature. Then when you would like to remount the filesystem you could always verify the checksums to see if you are trojaned or not. - TEMPORARILY MOUNT, LET PROGRAMS READ FILES INTO MEMORY, THEN UNMOUNT. Unfortunately this one isn't possible, as the protected data won't be config files for services, but rather .html and .php pages which need to be accessed very often. It was a good point, I must say. Other interesting things to look at: - LICENSING ISSUES. As Peter Cordes commented, the kernel is GPL so if we integrate code into it, we cannot provide a binary-only version, we should also give away the sources (or use modules, but we want a monolythic kernel for obvious security reasons). However I don't see the problem in thinking of something like this, implementing it, documenting, giving away to the community... and later configuring it for our particular needs, so that a client cannot (initially, at least) break it. I have to leave right now, and I'm taking a copy of this mail to discuss it with my
Re: Default Apache install not fit for multiple domains/users
On 06 Jun 2003 16:15:37 PDT, Jon writes: I believe Apache would still be executing php/cgi scripts as www-data, so users could snoop on other users's scripts, session files, etc. Something like: ?php echo `ls ../neighbor/public_html`; ? I suggest you look up the suEXEC Apache module, it seems to do exactly what you want. --- Wade
