Re: iptables with a linux bridge
On Wed, 28 Nov 2001, François Bayart wrote: Hi , I've installed a linux bridge with 2.4.14 kernel and the bridge-utils packages brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 ifconfig eth0 0.0.0.0 ifconfig eth1 0.0.0.0 ifconfig br0 62.4.8.2 netmask 255.255.255.0 broadcast 62.4.8.255 That correctly works but now I would like create some filtering rules and I try with iptables and it doesn't work ex, just drop the icmp : iptables -F INPUT iptables -P INPUT ACCEPT iptables -F OUTPUT iptables -P OUTPUT ACCEPT iptables -F FORWARD iptables -P FORWARD ACCEPT As I believe to remember, you have to set the default policy to DENY, at least you had to do when doing masquarading under 2.2. and ipchains. iptables -A FORWARD -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -A INPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -A OUTPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t mangle -A PREROUTING -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t mangle -A OUTPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t nat -A POSTROUTING -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t nat -A PREROUTING -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t nat -A OUTPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -N br0 iptables -A br0 -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -A br0 -d 62.4.8.73 -s 0/0 -p ICMP -j DROP -i br0 iptables -A FORWARD -d 62.4.8.73 -s 0/0 -p ICMP -j DROP -i br0 iptables -A INPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP -i br0 and I can ping without problem, I have try all rules because I don't understand the problem, normally I don't have NAT n this network. Si if someone can give me a solution or informations thx Francois --- François Bayart [EMAIL PROTECTED] +33 1 49 27 98 30 +33 6 87 84 18 82 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
On Wed, 2001-11-28 at 01:51, Olaf Meeuwissen wrote: Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button Could be made rather easy by using a mouse and the special features of gpm. Special commands are toggled by triple-clicking the left and right button -- an unlikely event during normal mouse usage. The easiest way to triple-click is pressing one of the buttons and triple-click the other one. When special processing is toggled, a message appears on the console (and the speaker beeps twice, if you have a speaker); if the user releases all the buttons and presses one of them again within three seconds, then the special command cor responding to the button is executed. The default special commands are: left button Reboot the system by signalling the init process middle button (if any) Execute `/sbin/shutdown -h now' right button Execute `/sbin/shutdown -r now' 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? If it's too hard to log the user, who made the shutdown, maybe it would be enough to use sshd or netfilter to log the workstation which was used. Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
I can't resist it! Add a usb digital camera to the box and only allow people who are not logged in via ssh (and therefore known users) to shut the machine down by using the Ctrl+Alt+Del on a keyboard. Add a shutdown init script to the start of the process which takes a few snaps of the shutdownee. Silly but seems to meet your criteria (you never said you didn't want to add extra hardware). Other than something like this I cannot imagine any solution that would meet your requirements AND the companies (they obviously want anyone to be able to shut it down, but you want to know who did it and a terminal will never know unless each user has a login). Niall Gerhard Schneider wrote: On Wed, 2001-11-28 at 01:51, Olaf Meeuwissen wrote: Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button Could be made rather easy by using a mouse and the special features of gpm. Special commands are toggled by triple-clicking the left and right button -- an unlikely event during normal mouse usage. The easiest way to triple-click is pressing one of the buttons and triple-click the other one. When special processing is toggled, a message appears on the console (and the speaker beeps twice, if you have a speaker); if the user releases all the buttons and presses one of them again within three seconds, then the special command cor responding to the button is executed. The default special commands are: left button Reboot the system by signalling the init process middle button (if any) Execute `/sbin/shutdown -h now' right button Execute `/sbin/shutdown -r now' 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? If it's too hard to log the user, who made the shutdown, maybe it would be enough to use sshd or netfilter to log the workstation which was used. Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I am a newbie to this list, so please forgive if something may be a FAQ. First of all I want to forward a Security Announcement. Since I run wuftpd on some server I'd like to know if I am vulnerable with debian (2.2r4) too. Is there a place where to find pending issues for debian? Thanks Hendrik Naumann - -- Weitergeleitete Nachricht -- Subject: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043) Date: Wed, 28 Nov 2001 23:55:25 +0100 (MET) From: Roman Drahtmueller [EMAIL PROTECTED] To: [EMAIL PROTECTED] - -BEGIN PGP SIGNED MESSAGE- _ _ SuSE Security Announcement Package:wuftpd Announcement-ID:SuSE-SA:2001:043 Date: Wednesday, Nov. 28th, 2001 23:45 MET Affected SuSE versions: 6.3, 6.4, 7.0, 7.1, 7.2, 7.3 Vulnerability Type: remote root compromise Severity (1-10):7 SuSE default package: no Other affected systems: all liunx-like systems using wu-ftpd 2.4.x / 2.6.0 / 2.6.1 Content of this advisory: 1) security vulnerability resolved: wuftpd problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) _ _ 1) problem description, brief discussion, solution, upgrade information The wuftpd package as shipped with SuSE Linux distributions comes with two versions of wuftpd: wuftpd-2.4.2, installed as /usr/sbin/wuftpd, and wuftpd-2.6.0, installed as /usr/sbin/wuftpd-2.6. The admin decides which version to use by the inetd/xinetd configuration. The CORE ST Team had found an exploitable bug in all versions of wuftpd's ftpglob() function. The glob function overwrites buffer bounds while matching open and closed brackets. Due to a missing \0 at the end of the buffer a later call to a function that frees allocated memory will feed free(3) with userdefined data. This bug could be exploited depending on the implementation of the dynmaic allocateable memory API (malloc(3), free(3)) in the libc library. Linux and other system are exploitable! Some weeks ago, an internal source code audit of wu-ftpd 2.6.0 performed by Thomas Biege, SuSE Security, revealed some other security related bugs that are fixed in the new RPM packages. Additionally, code from wu-ftpd 2.6.1 were backported to version 2.6.0 to make it more stable. A temporary fix other than using a different server implementation of the ftp protocol is not available. We recommend to update the wuftpd package on your system. We thank the wuftpd team for their work on the bug, particularly because the coordination between the vendors and the wuftpd developers lacked the necessary discipline for the timely release of the information about the problem. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command rpm -Uhv file.rpm to apply the update. - -- SNIP -- ... - -- SNIP -- _ _ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - ssh/openssh exploits The wrong fix for the crc32-compensation attack is currently actively exploited in the internet for both the ssh and the openssh implementation of the ssh-1 protocol. We urge our users to upgrade their ssh or openssh packages to the latest versions that are located on our ftp server at the usual directories, referred to via http://www.suse.de/de/support/security/adv004_ssh.txt from February earlier this year. Please note, the packages for the SuSE Linux distributions 7.0 and older containing cryptographic code are located on the German ftp server ftp.suse.de, the distributions 7.1 and newer have their crypto updates on ftp.suse.com. There are legal constraints beyond our control that lead to this situation. Openssh packages of the version 2.9.9p2 ready to download on the ftp server ftp.suse.com. They fix the security problems mentioned above, along with a set of less serious security problems. The announcement is still pending while investigations about the status of the package are in progress. - libgtop_daemon The libgtop_daemon, part of the libgtop package for gathering and monitoring process and system information, has been found vulnerable to a format string error. We are in the process of providing fixes for the affected distributions 6.4-7.3. In the meanwhile, we recommend to disable the libgtop_daemon on systems where
Re: [d-sec] Fwd: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043)
Hallo Hendrik On Thu, Nov 29, 2001 at 11:58:46AM +0100, Hendrik Naumann wrote: First of all I want to forward a Security Announcement. Since I run wuftpd on some server I'd like to know if I am vulnerable with debian (2.2r4) too. Yes it is vulnerable. I already send the patch RedHat to [EMAIL PROTECTED], I forward it into the BTS, too then people can access it from there, too. Is there a place where to find pending issues for debian? http://security.debian.org/ Hendrik Naumann bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables with a linux bridge
Hello, a firewall needs to have IP routing capabilities to be able to enforce rules (same for a packet filter), ? A proxy firewall doesn't need to have IP routing capabilities (eg. forwarding packet between interfaces). And a proxy firewall is definietly a firewall. (some people doesn't call packet filters as firewalls, that's true, they mean a proxy under the term: firewall) but there is no IP routing going on as the network on one side of the bridge is the *same* as the network on the other, for instance 192.168.1.0/24. Why does IP routing is so important if you want to build a packet filter? The goal is to have the ability to deny or allow packets through the device. -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-sec] Fwd: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043)
On Thu, Nov 29, 2001 at 12:22:02PM +0100, Hendrik Naumann wrote: Hm. I may be blind, but here I only see the already anounced issues. I am looking for a list of issues, not jet announced. Like the one in the SuSE Mailing. Then the best ist to subscrbe at bugtraq mailinglist at securityfocus.com. It is not Debian specific. -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
On Thu, Nov 29, 2001 at 10:37:24AM +, Niall Walsh wrote: I can't resist it! me too:) Add a usb digital camera to the box and only allow people who are not I've thought of this too, but rejected it because it's s easy to circumvent, just place your hand in front of the camera. -- groetjes, carel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables with a linux bridge
* Attila Nagy [EMAIL PROTECTED] [2001.11.29 14:30:56+0100]: a firewall needs to have IP routing capabilities to be able to enforce rules (same for a packet filter), ? A proxy firewall doesn't need to have IP routing capabilities (eg. forwarding packet between interfaces). And a proxy firewall is definietly a firewall. (some people doesn't call packet filters as firewalls, that's true, they mean a proxy under the term: firewall) a proxy operates on level 7, and even though it doesn't actually route IP packets, it routes on the virtual level 8. IP routing is on level 3, MAC address proxying happens on level 2. By the same analogy, you *can* view proxies as routers on a level above the application protocol, but this is going a little far i admit. in any case, you are right... a proxy can be a firewall without routing capabilities (it better have no routing capabilities), but it still needs two physically connected and *different* logical nets as it *does* employ the kernel routing tables. moreover, if you accept the abstraction of ISO/OSI that level 3 on one side talks to level 3 on the other side, then even a proxy is a router... but there is no IP routing going on as the network on one side of the bridge is the *same* as the network on the other, for instance 192.168.1.0/24. Why does IP routing is so important if you want to build a packet filter? The goal is to have the ability to deny or allow packets through the device. you are right, and i am liking the concept of this transparent firewall the more i think about it. in fact, it becomes hard to argue against. and i don't want to argue against it no more. my initial argument was that it isn't a bridge anymore, and i still think i am right, especially because cisco's pix, which is *not* a bridge but a firewall, can do the same. but there is no use in conservatively sitting on definitions, a bridge with iptables is wicked cool! -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck only through hard work and perseverance can one truly suffer. msg04450/pgp0.pgp Description: PGP signature
passwords and crypt?
Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwords and crypt?
crypt(3) only uses the first 8 characters for it's hash. roniosko is 8 characters. Any extras would be ignored. I think you'll find trying roniosk would fail. md5 passwords are a much better option and available at least from slink (2.1) on (iirc). I'm not sure about earlier versions. Roger Keays wrote: Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] J.R. Blain http://www.cowboyatheart.org/ -- Real programmers use chmod +x /dev/random and cross their fingers -- Comment found in a vi/emacs flamewar on slashdot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwords and crypt?
On Fri, 30 Nov 2001, Roger Keays wrote: Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! All the ones you tried are all over 8 letters, I bet? My guess is you're using DES. DES only allows up to 8 letter passwords. Check your /etc/pam.d, look at login and passwd in there If you add a md5 at the end of the line that handles passwords, this will enable md5, which allows longer passwords. This is backwards compatible in that your existing passwords will still work. Once you change it or add another user, it will use md5. If you look at /etc/shadow, you can see the difference. MD5 passwords start with a $1 in the password field. DES don't, and are slightly shorter hashes. Debian 2.1 didn't use MD5 passwords, and there's no way to automatically transfer forward to DES passwords. It's an option on 2.2 and above, to install MD5 passwords, you should. Hope this helps, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwords and crypt?
On Fri, 30 Nov 2001, Roger Keays wrote: I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] hi Roger, maybe you dont use MD5 passwords, so only the first 8 characters will be compared. see http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.4 for more information. tom -- .-. free source for free users! /v\ L I N U X // \\Phear the Penguin /( )\ ^^-^^ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwords and crypt?
Roger Keays [EMAIL PROTECTED] writes: I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! Wrong. You can guess the first two characters of the username if you use it as a salt. e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! That's a consequence of passwords being truncated at 8 chars before running crypt() on them. Can anyone else reproduce this? I'd be surprised if I couldn't! ~Tim -- Can you tell me how to get, |[EMAIL PROTECTED] How to get to Sesame Street?|http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwords and crypt?
Roger Keays wrote: Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger I just tried this with the same as you, I found that if you use rooniosko instead of roniosko, the result is the same. I've tried with another one (user azerty and password ra) and it doesn't work. I put azertyqsdf as paswword and I have the same... But if I put azerty as password it don't... let's count the number of letters... roniosko : 8, rooniosko : 9, ra : 2, azertyqsdfd : 10, azerty : 5 I think the size is important, not the extension fact. I think all characters after the 8th letter is ignored. Anybody confirms ? Regis. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables with a linux bridge
Hi , I've patch my kernel and now that's correctly work iptables -A FORWARD -p tcp -s ! 192.168.3.1 --dport 143 -j DROP So I use 2.4.14 kernel the http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.3-against-2.4.13 -ac7.diff patch when I set 802.1d Ethernet Bridging in kernel I've a new selection netfilter ( firewalling ) suport and after taht's work ... Thx all and specially Jigal Most people send me a private message to ask more informations to try or to change in the futur their Proxy Arp to Bridge, so re-send me an email and I will give you news. --- François Bayart [EMAIL PROTECTED] +33 1 49 27 98 30 +33 6 87 84 18 82 - Original Message - From: martin f krafft [EMAIL PROTECTED] To: Attila Nagy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 3:45 PM Subject: Re: iptables with a linux bridge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwords and crypt?
Interesting. I'm running Debian 2.2r2 (dist-upgraded to testing). I selected MD5 for my passwords during installation. However, it seems that it has defaulted my passwords to 8 characters too: From /etc/pam.d/passwd (login is the same) password required pam_unix.so nullok obscure min=4 max=8 md5 Actually, i don't think the min max seem to be affecting it. Just changed my password to abcdefghij, and abcdefghi won't let me in, only abcdefghij. Then again, i changed it as root.. sec. Yup, lets me set a over 8 letter password as the user too. Odd. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
Carel Fellinger wrote: On Thu, Nov 29, 2001 at 10:37:24AM +, Niall Walsh wrote: I can't resist it! me too:) Add a usb digital camera to the box and only allow people who are not I've thought of this too, but rejected it because it's s easy to circumvent, just place your hand in front of the camera. Not if they don't know where it is or even that it exists :-) I'd be sneeking it into the case perhaps so it looks out a drive bay or else building it into something. Also you could use a capture card hooked up to a pin hole camera and for completeness (but system performance thrashing) use motion detection to make sure you get them before they get the hand in place! Seriously crazy, but what else can you do if you really want to supply anyone with the ability to shut it down AND know who did it! Maybe put the password with the security guard so he can record who took the passwd to reset it (obviously you need to reset the password then etc.) Niall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
On Thu, Nov 29, 2001 at 05:59:40PM +, Niall Walsh wrote: Carel Fellinger wrote: On Thu, Nov 29, 2001 at 10:37:24AM +, Niall Walsh wrote: I can't resist it! me too:) Add a usb digital camera to the box and only allow people who are not I've thought of this too, but rejected it because it's s easy to circumvent, just place your hand in front of the camera. Not if they don't know where it is or even that it exists :-) I'd be sneeking it into the case perhaps so it looks out a drive bay or else building it into something. Also you could use a capture card hooked up to a pin hole camera and for completeness (but system performance thrashing) use motion detection to make sure you get them before they get the hand in place! Have the camera take 1 shot every second (or .5 seconds) and save them in a round-robin naming fashion e.g.: shot1.jpg, shot2.jpg, shot3.jpg...shot10.jpg, shot1.jpg, and then have an init-script move the directory they are in to something like pic.old/. That way you have the last 5-10 seconds on the machines life. Yeah, this is getting seriously rube-goldberg. Seriously crazy, but what else can you do if you really want to supply anyone with the ability to shut it down AND know who did it! Maybe put the password with the security guard so he can record who took the passwd to reset it (obviously you need to reset the password then etc.) -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
VI wrapper for SUDO?
A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. Does such a beast exist? If not, I think it should. It should probably obey the /etc/alternatives preferences for editors, too. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Thats only if they arn't thinkingIf they were really smart they might run :!/bin/bash...then they have root shell access to the entire box...:-) Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. Does such a beast exist? If not, I think it should. It should probably obey the /etc/alternatives preferences for editors, too. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Searched groups.google.com for secure vi shell escape, and found: http://groups.google.com/groups?hl=enselm=65utkq%2480p%40winx03.informatik.uni-wuerzburg.de and it looks like nvi still supports the secure options mentioned there. -- Mike Renfro / RD Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message 20011129165355.A15543@ch208h, Mike Renfro writes: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Searched groups.google.com for secure vi shell escape, and found: http://groups.google.com/groups?hl=enselm=65utkq%2480p%40winx03.informatik.un i-wuerzburg.de and it looks like nvi still supports the secure options mentioned there. Vim also supports something similar, either by prepending r to the executable name (rvim) or adding the -Z flag. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OpenBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8BsC0oayJfLoDSdIRAp0FAJ4nReHeeCvDbTQM/KOGLmdSNi/AgQCgykls /CfA9U8dx28dUi0CX4Aqyuo= =FYJ6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], Ted Cabeen writes: In message 20011129165355.A15543@ch208h, Mike Renfro writes: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... and it looks like nvi still supports the secure options mentioned there. Vim also supports something similar, either by prepending r to the executable name (rvim) or adding the -Z flag. However, thinking about it, this doesn't work. If you're editing as root, you can use :e to switch to editing a SUID root file (any one you can write to will work), delete the entire contents, and then use :r to bring in the /bin/sh executable. You'd need an editor that couldn't edit binary files to prevent this attack. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OpenBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8BsLwoayJfLoDSdIRAqoVAJ9KXDHVefmPsbnKU63vjNbtpwdyWQCfXvI/ n0N0MbChXeou3l/Jj3JRqMM= =DucW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
William R Ward [EMAIL PROTECTED] writes: Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. People have mentioned that nvi and vim have secure modes but there is still the risk of running a program that really wasn't designed with modern security issues in mind. Also, for people who don't like to use vi, or who prefer a different version of vi than the one that has the best secure mode, it wouldn't work. It would be better if it was /etc/alternatives/editor rather than nvi or vim. This *is* Debian we're talking about :-) Since the editing can be done with normal user privileges (assuming the source file is readable, and even that can be got around), any editor could be used. Trouble is, that doesn't work with sudo. What I think is needed is a new program that is sudo-aware (probably linked with many of sudo's object files), uses /etc/sudoers for permission, etc. but uses $EDITOR or /etc/alternatives or whatever to choose the actual program for editing. Even emacsclient/gnuclient could do the trick. The only part where root privs are needed is *installing* the edited file. It'd be best to limit the root privs to where they are actually needed. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
What is the status with wu-ftpd updated potato packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I just signed up with the debian-security mailing list so I am not up to speed with all the discussions. What is the status with the wu-ftpd updated potato packages? I could find no mention of it on the debian main or security web pages and a search of several mailing lists showed no mention to what is being done about this exploit (The most recent wu-ftpd discussion was on Dec 4 / 6 in debian-user). Searching through the posts on the slashdot discussion made no mention of updating the packages either (though they did recomend switching to proftpd or even better bsd-ftpd which is based on openbsd). Announcements on bugtraq mention that debian is working on a patch, but updated stable/potato packages have not been released yet. I know redhat released their announcement early, but it pains me to see redhat ahead of debian on the security fix by almost 2 days. Are there other sysadmins using wu-ftpd and if so what are they doing about this vulnurability? thanks, donfede -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8BuDCSeRbV/op2s4RAjaMAJ40rz/LyNcf6i+CHXd8jSBflAjHxwCeLfL8 zcfPbkaTdKAGMCnyVOe7YEU= =9WdP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file #!/bin/bash # # sucpaliases # PATH=/sbin:/bin:/usr/sbin # # do some error checking too before executing these commands # mv /etc/aliases /etc/aliases.prev.xx mv /tmp/aliases /etc/aliases newaliases # # end of sucp c ya alvin On 29 Nov 2001, William R Ward wrote: William R Ward [EMAIL PROTECTED] writes: Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What is the status with wu-ftpd updated potato packages?
Read this: http://lists.debian.org/debian-changes/2001/debian-changes-200111/msg00085.html What is the status with the wu-ftpd updated potato packages? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill if that sh script is called sucpaliases... you cannot(should not) put sudo sucpaliases inside of it - infinite recursion... the original idea was to copy and install the users versions of /etc/aliases file w/o giving um root or changing permissions... and not to allow sucpaliases to edit the file directly ( edit the file as a user ... -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access c ya alvin On Thu, 29 Nov 2001, William R. Ward wrote: Alvin Oga writes: how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This would be a wonderful application of OTP's. On Thursday 29 November 2001 11:59 am, Niall Walsh wrote: Maybe put the password with the security guard so he can record who took the passwd to reset it (obviously you need to reset the password then etc.) - -- Warren GPG Fingerprint: 30C8 BDF1 B133 14CB 832F 2C5D 99A1 A19F 559D 9E88 GPG Public Key @ http://www.cbu.edu/~wturkal/wturkal.gpg - -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s: a-- C++ UL+ P+ L+++ E W++ N+ o-- K- w--- O M+ V-- PS+ PE Y+ PGP++ t 5 X R tv+ b+ DI+ D+ G e h-- r y? - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8BvComaGhn1WdnogRAng/AJwNaZIvi7U4TuO5j1mLLyE3iq5woQCeITxO eNSDlyPCBFljB5sd63pSQzU= =MXoU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Encrypted Filesystems zing pow woosh
Just FYI, Slashdot has a discussionn up on encrypted file systems that might be of interest to folks who partisipated in the discussion here. This direct link might work: http://slashdot.org/article.pl?sid=01/11/28/1549252mode=thread Curt- --- Curt Howland +81-3-5772-5832 KVH Telecom Japan, Ltd.IDC Division -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: if that sh script is called sucpaliases... you cannot(should not) put sudo sucpaliases inside of it - infinite recursion... Of course not. The script I wrote is editaliases and inside that script, your sucpaliases is called. -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo These ideas are OK for some things, not for others. Sendmail is picky about the ownership and permissions on certain files. -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... Right - but I think the former is easier to thwart. Don't most Linux systems prohibit setuid shell scripts, for example? -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access Of course, the idea is to give certain permissions to certain users without giving away the farm. That's what sudo's all about. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Secure wu-ftpd for Testing?
Hello all, Is the wu-ftpd in testing secure? It seems to be 2.6.1 a stinker. Testing is using 2.6.1-5, is that also compromised? I have been watching it all day but haven't seen any updates. If it is not secure has a patched version been made available anywhere? I can't seem to find any mention at http://www.debian.org/security/ Thanks! David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Secure wu-ftpd for Testing?
The article I read about it on the Register... http://www.theregister.co.uk/content/4/23082.html "The hole affects thousands of users of virtually every Linux release. Because of the wide implications, Core, working with CERT, and, at one point, SecurityFocus' "Vulnerability Help" team, arranged a coordinated release with Caldera, SuSE, TurboLinux, Debian, Red Hat, and other Linux vendors, so that patches would be available for every distribution simultaneously. December 3rd was picked for the release. That plan went out the window Tuesday, when Red Hat unilaterally issued its own advisory." So I will assume that Debian has a fix that is being tested, if not in "testing". I'm very surprised it hasn't been released or mentioned yet myself. Curt- -Original Message- From: David Ehle [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 14:20 To: [EMAIL PROTECTED] Cc: Debian-Security (E-mail) Subject: Secure wu-ftpd for Testing? Hello all, Is the wu-ftpd in testing secure? It seems to be 2.6.1 a stinker. Testing is using 2.6.1-5, is that also compromised? I have been watching it all day but haven't seen any updates. If it is not secure has a patched version been made available anywhere? I can't seem to find any mention at http://www.debian.org/security/ Thanks! David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secure wu-ftpd for Testing?
Thanks Curtis, I know the maintainer has put together a fixed version for Potato/stable, I am wondering if he has had time to do the testing yet, or if we rollback to the testing one or what. I'm just hoping that rollback won't be a dependency nightmare... the stable version is wu-ftpd_2.6.0-6 available from: ftp.debian.org but NOT (as of about 6:00pm my local time) ftp.us.debian.org. Anyway thanks for the info. here are some other info sources i've found: http://www.securityfocus.com/archive/1/242750 http://www.wu-ftpd.org (they only put up something around 3:00 pm local-chicago time) Later, David. Howland, Curtis wrote: The article I read about it on the Register... http://www.theregister.co.uk/content/4/23082.html The hole affects thousands of users of virtually every Linux release. Because of the wide implications, Core, working with CERT, and, at one point, SecurityFocus' Vulnerability Help team, arranged a coordinated release with Caldera, SuSE, TurboLinux, Debian, Red Hat, and other Linux vendors, so that patches would be available for every distribution simultaneously. December 3rd was picked for the release. That plan went out the window Tuesday, when Red Hat unilaterally issued its own advisory. So I will assume that Debian has a fix that is being tested, if not in testing. I'm very surprised it hasn't been released or mentioned yet myself. Curt- -Original Message- From: David Ehle [mailto:[EMAIL PROTECTED]] Sent: Friday, November 30, 2001 14:20 To: [EMAIL PROTECTED] Cc: Debian-Security (E-mail) Subject: Secure wu-ftpd for Testing? Hello all, Is the wu-ftpd in testing secure? It seems to be 2.6.1 a stinker. Testing is using 2.6.1-5, is that also compromised? I have been watching it all day but haven't seen any updates. If it is not secure has a patched version been made available anywhere? I can't seem to find any mention at http://www.debian.org/security/ Thanks! David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
whats up? 687370480
Below is the result of your feedback form. It was submitted by ([EMAIL PROTECTED]) on Friday, November 30, 2001 at 03:40:39 --- : Hey, what's up, yall? I found a site and if you want to meet people and talk to :people on webcam, you should check this out. They're now giving members totally free :memberships!You don't even need your own webcam. You can watch live videos of :family, friends, or anybody! What is there to lose?bra :href=http://lllil.com/livewebcam;http://lllil.com/livewebcam brbrbrbr/aTo take yourself off my mailing list a href=http://lllil.com/list-offclick here/a.brbrbr338931680 --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables with a linux bridge
On Wed, 28 Nov 2001, François Bayart wrote: Hi , I've installed a linux bridge with 2.4.14 kernel and the bridge-utils packages brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 ifconfig eth0 0.0.0.0 ifconfig eth1 0.0.0.0 ifconfig br0 62.4.8.2 netmask 255.255.255.0 broadcast 62.4.8.255 That correctly works but now I would like create some filtering rules and I try with iptables and it doesn't work ex, just drop the icmp : iptables -F INPUT iptables -P INPUT ACCEPT iptables -F OUTPUT iptables -P OUTPUT ACCEPT iptables -F FORWARD iptables -P FORWARD ACCEPT As I believe to remember, you have to set the default policy to DENY, at least you had to do when doing masquarading under 2.2. and ipchains. iptables -A FORWARD -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -A INPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -A OUTPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t mangle -A PREROUTING -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t mangle -A OUTPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t nat -A POSTROUTING -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t nat -A PREROUTING -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -t nat -A OUTPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -N br0 iptables -A br0 -d 62.4.8.73 -s 0/0 -p ICMP -j DROP iptables -A br0 -d 62.4.8.73 -s 0/0 -p ICMP -j DROP -i br0 iptables -A FORWARD -d 62.4.8.73 -s 0/0 -p ICMP -j DROP -i br0 iptables -A INPUT -d 62.4.8.73 -s 0/0 -p ICMP -j DROP -i br0 and I can ping without problem, I have try all rules because I don't understand the problem, normally I don't have NAT n this network. Si if someone can give me a solution or informations thx Francois --- François Bayart [EMAIL PROTECTED] +33 1 49 27 98 30 +33 6 87 84 18 82
Re: shutdown user and accountability
On Wed, 2001-11-28 at 01:51, Olaf Meeuwissen wrote: Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button Could be made rather easy by using a mouse and the special features of gpm. Special commands are toggled by triple-clicking the left and right button -- an unlikely event during normal mouse usage. The easiest way to triple-click is pressing one of the buttons and triple-click the other one. When special processing is toggled, a message appears on the console (and the speaker beeps twice, if you have a speaker); if the user releases all the buttons and presses one of them again within three seconds, then the special command cor responding to the button is executed. The default special commands are: left button Reboot the system by signalling the init process middle button (if any) Execute `/sbin/shutdown -h now' right button Execute `/sbin/shutdown -r now' 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? If it's too hard to log the user, who made the shutdown, maybe it would be enough to use sshd or netfilter to log the workstation which was used. Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shutdown user and accountability
I can't resist it! Add a usb digital camera to the box and only allow people who are not logged in via ssh (and therefore known users) to shut the machine down by using the Ctrl+Alt+Del on a keyboard. Add a shutdown init script to the start of the process which takes a few snaps of the shutdownee. Silly but seems to meet your criteria (you never said you didn't want to add extra hardware). Other than something like this I cannot imagine any solution that would meet your requirements AND the companies (they obviously want anyone to be able to shut it down, but you want to know who did it and a terminal will never know unless each user has a login). Niall Gerhard Schneider wrote: On Wed, 2001-11-28 at 01:51, Olaf Meeuwissen wrote: Dear .debs, I'm maintaining a (small-time) group server for our department. In order to satisfy company policy requirements I need to provide a way to shutdown the server in case of emergencies. Our network admin was kind enough to give me two alternatives: 1) provide an on-screen shutdown button Could be made rather easy by using a mouse and the special features of gpm. Special commands are toggled by triple-clicking the left and right button -- an unlikely event during normal mouse usage. The easiest way to triple-click is pressing one of the buttons and triple-click the other one. When special processing is toggled, a message appears on the console (and the speaker beeps twice, if you have a speaker); if the user releases all the buttons and presses one of them again within three seconds, then the special command cor responding to the button is executed. The default special commands are: left button Reboot the system by signalling the init process middle button (if any) Execute `/sbin/shutdown -h now' right button Execute `/sbin/shutdown -r now' 2) provide a shutdown user account (and document its usage) I didn't like either approach because they lack accountability: after a shutdown I can't tell *who* did it. BTW, the server has no screen for buttons, so 1) is not an option to begin with. You have to ssh in to do anything (exploit one of inetd, exim, samba or apache in some way may be an alternative ;-). I came up with a 'sudo /sbin/halt' for department members (and others on an as needed basis), but that was no good. Everyone has to be able to shut it down. I racked my brains but didn't come up with anything that provides accountability. Anyone any suggestions? If it's too hard to log the user, who made the shutdown, maybe it would be enough to use sshd or netfilter to log the workstation which was used. Right now, I'm stuck with 2) and writing the password on the machine (or similar) *or* stay with what I have now and take my chances with people flicking the power switch. BTW, the server is not in a physically secure location, so I run the power switch thingy risk anyway. Suggestions, discussions of pros and cons welcome, -- Olaf Meeuwissen Epson Kowa Corporation, Research and Development GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I am a newbie to this list, so please forgive if something may be a FAQ. First of all I want to forward a Security Announcement. Since I run wuftpd on some server I'd like to know if I am vulnerable with debian (2.2r4) too. Is there a place where to find pending issues for debian? Thanks Hendrik Naumann - -- Weitergeleitete Nachricht -- Subject: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043) Date: Wed, 28 Nov 2001 23:55:25 +0100 (MET) From: Roman Drahtmueller [EMAIL PROTECTED] To: [EMAIL PROTECTED] - -BEGIN PGP SIGNED MESSAGE- _ _ SuSE Security Announcement Package:wuftpd Announcement-ID:SuSE-SA:2001:043 Date: Wednesday, Nov. 28th, 2001 23:45 MET Affected SuSE versions: 6.3, 6.4, 7.0, 7.1, 7.2, 7.3 Vulnerability Type: remote root compromise Severity (1-10):7 SuSE default package: no Other affected systems: all liunx-like systems using wu-ftpd 2.4.x / 2.6.0 / 2.6.1 Content of this advisory: 1) security vulnerability resolved: wuftpd problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) _ _ 1) problem description, brief discussion, solution, upgrade information The wuftpd package as shipped with SuSE Linux distributions comes with two versions of wuftpd: wuftpd-2.4.2, installed as /usr/sbin/wuftpd, and wuftpd-2.6.0, installed as /usr/sbin/wuftpd-2.6. The admin decides which version to use by the inetd/xinetd configuration. The CORE ST Team had found an exploitable bug in all versions of wuftpd's ftpglob() function. The glob function overwrites buffer bounds while matching open and closed brackets. Due to a missing \0 at the end of the buffer a later call to a function that frees allocated memory will feed free(3) with userdefined data. This bug could be exploited depending on the implementation of the dynmaic allocateable memory API (malloc(3), free(3)) in the libc library. Linux and other system are exploitable! Some weeks ago, an internal source code audit of wu-ftpd 2.6.0 performed by Thomas Biege, SuSE Security, revealed some other security related bugs that are fixed in the new RPM packages. Additionally, code from wu-ftpd 2.6.1 were backported to version 2.6.0 to make it more stable. A temporary fix other than using a different server implementation of the ftp protocol is not available. We recommend to update the wuftpd package on your system. We thank the wuftpd team for their work on the bug, particularly because the coordination between the vendors and the wuftpd developers lacked the necessary discipline for the timely release of the information about the problem. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command rpm -Uhv file.rpm to apply the update. - -- SNIP -- ... - -- SNIP -- _ _ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - ssh/openssh exploits The wrong fix for the crc32-compensation attack is currently actively exploited in the internet for both the ssh and the openssh implementation of the ssh-1 protocol. We urge our users to upgrade their ssh or openssh packages to the latest versions that are located on our ftp server at the usual directories, referred to via http://www.suse.de/de/support/security/adv004_ssh.txt from February earlier this year. Please note, the packages for the SuSE Linux distributions 7.0 and older containing cryptographic code are located on the German ftp server ftp.suse.de, the distributions 7.1 and newer have their crypto updates on ftp.suse.com. There are legal constraints beyond our control that lead to this situation. Openssh packages of the version 2.9.9p2 ready to download on the ftp server ftp.suse.com. They fix the security problems mentioned above, along with a set of less serious security problems. The announcement is still pending while investigations about the status of the package are in progress. - libgtop_daemon The libgtop_daemon, part of the libgtop package for gathering and monitoring process and system information, has been found vulnerable to a format string error. We are in the process of providing fixes for the affected distributions 6.4-7.3. In the meanwhile, we recommend to disable the libgtop_daemon on systems where
shutdown via webpage
How about if a webpage was made on the server that would require user authentication and would execute a suid shutdown CGI script?
Re: iptables with a linux bridge
Hello, a firewall needs to have IP routing capabilities to be able to enforce rules (same for a packet filter), ? A proxy firewall doesn't need to have IP routing capabilities (eg. forwarding packet between interfaces). And a proxy firewall is definietly a firewall. (some people doesn't call packet filters as firewalls, that's true, they mean a proxy under the term: firewall) but there is no IP routing going on as the network on one side of the bridge is the *same* as the network on the other, for instance 192.168.1.0/24. Why does IP routing is so important if you want to build a packet filter? The goal is to have the ability to deny or allow packets through the device. -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758
Re: iptables with a linux bridge
Hello, One point you are missing is that it is possible using this kind of configuration to create a firewall where you cannot address any of it's external interfaces. So how can you do an intrusion attack on a firewall that you cannot address? In theory it is possible. If you can use the packet filter for executing arbitrary data (for example in an IP packet) you have the ability to get root. Like with tcpdump. There were remote root exploits, but tcpdump itself does not listens on any ports. This is the same, but with IP addresses... -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758
Re: [d-sec] Fwd: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Is there a place where to find pending issues for debian? http://security.debian.org/ Hm. I may be blind, but here I only see the already anounced issues. I am looking for a list of issues, not jet announced. Like the one in the SuSE Mailing. 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - openssh After stabilizing the openssh package, updates for the distributions 6.4-7.2 are currently being prepared. The update packages fix a security problem related to the recently discovered problems with source ip based access restrictions in a user's ~/.ssh/authorized_keys2 file. The packages will appear shortly on our ftp servers. Please note that packages for the distributions 6.3 and up including 7.0 containing cryptographic software are located on the German ftp server ftp.suse.de, all other packages can be found on ftp.suse.com at the usual location. We will issue a dedicated Security announcement for the openssh package. - The ziptool program runs setuid root in the easy permission mode and contains an overflow which allows local attackers to gain root privileges. A zipdrive must be configured and a zipdisk being inserted in order to exploit the bug. The overflow has been fixed. Please update your packages. - The ncpfs package containing the setuid root programs ncpmount and ncpumount was vulnerable to local bufferoverflow attacks. The package has been fixed. Hendrik - -- PGP ID 21F0AC0265C92061 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (GNU/Linux) Comment: For info see http://www.gnupg.org iD4DBQE8BhpaIfCsAmXJIGERAkcbAJ9M0T0/mIu6eesnN380pZX0nKVuHACYhH0I jY3XZbsQBxSkvfisPy9TSQ== =W0uY -END PGP SIGNATURE-
Re: [d-sec] Fwd: [suse-security-announce] SuSE Security Announcement: wuftpd (SuSE-SA:2001:043)
On Thu, Nov 29, 2001 at 12:22:02PM +0100, Hendrik Naumann wrote: Hm. I may be blind, but here I only see the already anounced issues. I am looking for a list of issues, not jet announced. Like the one in the SuSE Mailing. Then the best ist to subscrbe at bugtraq mailinglist at securityfocus.com. It is not Debian specific. -christian-
Re: shutdown user and accountability
On Thu, Nov 29, 2001 at 10:37:24AM +, Niall Walsh wrote: I can't resist it! me too:) Add a usb digital camera to the box and only allow people who are not I've thought of this too, but rejected it because it's s easy to circumvent, just place your hand in front of the camera. -- groetjes, carel
Re: iptables with a linux bridge
* Attila Nagy [EMAIL PROTECTED] [2001.11.29 14:30:56+0100]: a firewall needs to have IP routing capabilities to be able to enforce rules (same for a packet filter), ? A proxy firewall doesn't need to have IP routing capabilities (eg. forwarding packet between interfaces). And a proxy firewall is definietly a firewall. (some people doesn't call packet filters as firewalls, that's true, they mean a proxy under the term: firewall) a proxy operates on level 7, and even though it doesn't actually route IP packets, it routes on the virtual level 8. IP routing is on level 3, MAC address proxying happens on level 2. By the same analogy, you *can* view proxies as routers on a level above the application protocol, but this is going a little far i admit. in any case, you are right... a proxy can be a firewall without routing capabilities (it better have no routing capabilities), but it still needs two physically connected and *different* logical nets as it *does* employ the kernel routing tables. moreover, if you accept the abstraction of ISO/OSI that level 3 on one side talks to level 3 on the other side, then even a proxy is a router... but there is no IP routing going on as the network on one side of the bridge is the *same* as the network on the other, for instance 192.168.1.0/24. Why does IP routing is so important if you want to build a packet filter? The goal is to have the ability to deny or allow packets through the device. you are right, and i am liking the concept of this transparent firewall the more i think about it. in fact, it becomes hard to argue against. and i don't want to argue against it no more. my initial argument was that it isn't a bridge anymore, and i still think i am right, especially because cisco's pix, which is *not* a bridge but a firewall, can do the same. but there is no use in conservatively sitting on definitions, a bridge with iptables is wicked cool! -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] only through hard work and perseverance can one truly suffer. pgpZtaYM45fwi.pgp Description: PGP signature
passwords and crypt?
Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger
Re: passwords and crypt?
crypt(3) only uses the first 8 characters for it's hash. roniosko is 8 characters. Any extras would be ignored. I think you'll find trying roniosk would fail. md5 passwords are a much better option and available at least from slink (2.1) on (iirc). I'm not sure about earlier versions. Roger Keays wrote: Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] J.R. Blain http://www.cowboyatheart.org/ -- Real programmers use chmod +x /dev/random and cross their fingers -- Comment found in a vi/emacs flamewar on slashdot.
Re: passwords and crypt?
On Fri, 30 Nov 2001, Roger Keays wrote: Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! All the ones you tried are all over 8 letters, I bet? My guess is you're using DES. DES only allows up to 8 letter passwords. Check your /etc/pam.d, look at login and passwd in there If you add a md5 at the end of the line that handles passwords, this will enable md5, which allows longer passwords. This is backwards compatible in that your existing passwords will still work. Once you change it or add another user, it will use md5. If you look at /etc/shadow, you can see the difference. MD5 passwords start with a $1 in the password field. DES don't, and are slightly shorter hashes. Debian 2.1 didn't use MD5 passwords, and there's no way to automatically transfer forward to DES passwords. It's an option on 2.2 and above, to install MD5 passwords, you should. Hope this helps, Mike
Re: passwords and crypt?
On Fri, 30 Nov 2001, Roger Keays wrote: I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] hi Roger, maybe you dont use MD5 passwords, so only the first 8 characters will be compared. see http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.4 for more information. tom -- .-. free source for free users! /v\ L I N U X // \\Phear the Penguin /( )\ ^^-^^
Re: passwords and crypt?
Roger Keays [EMAIL PROTECTED] writes: I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! Wrong. You can guess the first two characters of the username if you use it as a salt. e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! That's a consequence of passwords being truncated at 8 chars before running crypt() on them. Can anyone else reproduce this? I'd be surprised if I couldn't! ~Tim -- Can you tell me how to get, |[EMAIL PROTECTED] How to get to Sesame Street?|http://spodzone.org.uk/
Re: passwords and crypt?
Roger Keays wrote: Hi all, I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! I tried a few more and had the same results. This is something to do with the random salt right? Can anyone else reproduce this? Cheers, Roger I just tried this with the same as you, I found that if you use rooniosko instead of roniosko, the result is the same. I've tried with another one (user azerty and password ra) and it doesn't work. I put azertyqsdf as paswword and I have the same... But if I put azerty as password it don't... let's count the number of letters... roniosko : 8, rooniosko : 9, ra : 2, azertyqsdfd : 10, azerty : 5 I think the size is important, not the extension fact. I think all characters after the 8th letter is ignored. Anybody confirms ? Regis.
Re: iptables with a linux bridge
Hi , I've patch my kernel and now that's correctly work iptables -A FORWARD -p tcp -s ! 192.168.3.1 --dport 143 -j DROP So I use 2.4.14 kernel the http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.3-against-2.4.13 -ac7.diff patch when I set 802.1d Ethernet Bridging in kernel I've a new selection netfilter ( firewalling ) suport and after taht's work ... Thx all and specially Jigal Most people send me a private message to ask more informations to try or to change in the futur their Proxy Arp to Bridge, so re-send me an email and I will give you news. --- François Bayart [EMAIL PROTECTED] +33 1 49 27 98 30 +33 6 87 84 18 82 - Original Message - From: martin f krafft [EMAIL PROTECTED] To: Attila Nagy [EMAIL PROTECTED] Cc: debian-security@lists.debian.org Sent: Thursday, November 29, 2001 3:45 PM Subject: Re: iptables with a linux bridge
Re: shutdown user and accountability
ons, 2001-11-28 kl. 02:58 skrev Olaf Meeuwissen: That's exactly what my sudo setup does right now. The problem is that apparently *everyone* needs to be able to shut down the machine (for reasons that are beyond me). Added accounts on an as needed basis is fine with me, but I don't fancy creating, oh, 250+ password protected accounts just to meet policy. Where are the users/passwords stored now? Windows, Novell, Unix System?? It should be possible to authenticate against the companies password database in some way. This way you won't have to create those accounts, but people would still be able to login (the technical procedure will be slighly different depending on how the user/password machine/database works). Or am I getting something wrong? -- Paul Fleischer // ProGuy Registered Linux User #166300 http://counter.li.org
Re: passwords and crypt?
Mike Dresser wrote: On Fri, 30 Nov 2001, Roger Keays wrote: I'm not sure if this is common knowledge or not, but I have just noticed the effects of having the first two letters of your password the same as the first two in your login name... You can use any extension of your password!! e.g., on my Woody box I added a user called 'ron' and his password was 'roniosko'. He could login in with 'ronioskos', 'ronioskoasdfasd' and so forth! All the ones you tried are all over 8 letters, I bet? My guess is you're using DES. DES only allows up to 8 letter passwords. Check your /etc/pam.d, look at login and passwd in there If you add a md5 at the end of the line that handles passwords, this will enable md5, which allows longer passwords. This is backwards compatible in that your existing passwords will still work. Once you change it or add another user, it will use md5. Interesting. I'm running Debian 2.2r2 (dist-upgraded to testing). I selected MD5 for my passwords during installation. However, it seems that it has defaulted my passwords to 8 characters too: From /etc/pam.d/passwd (login is the same) password required pam_unix.so nullok obscure min=4 max=8 md5
Re: passwords and crypt?
Interesting. I'm running Debian 2.2r2 (dist-upgraded to testing). I selected MD5 for my passwords during installation. However, it seems that it has defaulted my passwords to 8 characters too: From /etc/pam.d/passwd (login is the same) password required pam_unix.so nullok obscure min=4 max=8 md5 Actually, i don't think the min max seem to be affecting it. Just changed my password to abcdefghij, and abcdefghi won't let me in, only abcdefghij. Then again, i changed it as root.. sec. Yup, lets me set a over 8 letter password as the user too. Odd. Mike
Re: shutdown user and accountability
Carel Fellinger wrote: On Thu, Nov 29, 2001 at 10:37:24AM +, Niall Walsh wrote: I can't resist it! me too:) Add a usb digital camera to the box and only allow people who are not I've thought of this too, but rejected it because it's s easy to circumvent, just place your hand in front of the camera. Not if they don't know where it is or even that it exists :-) I'd be sneeking it into the case perhaps so it looks out a drive bay or else building it into something. Also you could use a capture card hooked up to a pin hole camera and for completeness (but system performance thrashing) use motion detection to make sure you get them before they get the hand in place! Seriously crazy, but what else can you do if you really want to supply anyone with the ability to shut it down AND know who did it! Maybe put the password with the security guard so he can record who took the passwd to reset it (obviously you need to reset the password then etc.) Niall
Re: shutdown user and accountability
On Thu, Nov 29, 2001 at 05:59:40PM +, Niall Walsh wrote: Carel Fellinger wrote: On Thu, Nov 29, 2001 at 10:37:24AM +, Niall Walsh wrote: I can't resist it! me too:) Add a usb digital camera to the box and only allow people who are not I've thought of this too, but rejected it because it's s easy to circumvent, just place your hand in front of the camera. Not if they don't know where it is or even that it exists :-) I'd be sneeking it into the case perhaps so it looks out a drive bay or else building it into something. Also you could use a capture card hooked up to a pin hole camera and for completeness (but system performance thrashing) use motion detection to make sure you get them before they get the hand in place! Have the camera take 1 shot every second (or .5 seconds) and save them in a round-robin naming fashion e.g.: shot1.jpg, shot2.jpg, shot3.jpg...shot10.jpg, shot1.jpg, and then have an init-script move the directory they are in to something like pic.old/. That way you have the last 5-10 seconds on the machines life. Yeah, this is getting seriously rube-goldberg. Seriously crazy, but what else can you do if you really want to supply anyone with the ability to shut it down AND know who did it! Maybe put the password with the security guard so he can record who took the passwd to reset it (obviously you need to reset the password then etc.) -- Share and Enjoy.
VI wrapper for SUDO?
A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. Does such a beast exist? If not, I think it should. It should probably obey the /etc/alternatives preferences for editors, too. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO?
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Thats only if they arn't thinkingIf they were really smart they might run :!/bin/bash...then they have root shell access to the entire box...:-) Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. Does such a beast exist? If not, I think it should. It should probably obey the /etc/alternatives preferences for editors, too. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
On Thu, Nov 29, 2001 at 02:45:08PM -0800, William R Ward wrote: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... Searched groups.google.com for secure vi shell escape, and found: http://groups.google.com/groups?hl=enselm=65utkq%2480p%40winx03.informatik.uni-wuerzburg.de and it looks like nvi still supports the secure options mentioned there. -- Mike Renfro / RD Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- [EMAIL PROTECTED]
Re: VI wrapper for SUDO?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], Ted Cabeen writes: In message [EMAIL PROTECTED], Mike Renfro writes: A lazy sysadmin, not thinking through the ramifications, might put things like /usr/bin/vi /etc/aliases in the sudoers file, thinking that it limits access. But of course, vi has the :e command... and it looks like nvi still supports the secure options mentioned there. Vim also supports something similar, either by prepending r to the executable name (rvim) or adding the -Z flag. However, thinking about it, this doesn't work. If you're editing as root, you can use :e to switch to editing a SUID root file (any one you can write to will work), delete the entire contents, and then use :r to bring in the /bin/sh executable. You'd need an editor that couldn't edit binary files to prevent this attack. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (OpenBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE8BsLwoayJfLoDSdIRAqoVAJ9KXDHVefmPsbnKU63vjNbtpwdyWQCfXvI/ n0N0MbChXeou3l/Jj3JRqMM= =DucW -END PGP SIGNATURE-
Re: VI wrapper for SUDO?
William R Ward [EMAIL PROTECTED] writes: Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location. People have mentioned that nvi and vim have secure modes but there is still the risk of running a program that really wasn't designed with modern security issues in mind. Also, for people who don't like to use vi, or who prefer a different version of vi than the one that has the best secure mode, it wouldn't work. It would be better if it was /etc/alternatives/editor rather than nvi or vim. This *is* Debian we're talking about :-) Since the editing can be done with normal user privileges (assuming the source file is readable, and even that can be got around), any editor could be used. Trouble is, that doesn't work with sudo. What I think is needed is a new program that is sudo-aware (probably linked with many of sudo's object files), uses /etc/sudoers for permission, etc. but uses $EDITOR or /etc/alternatives or whatever to choose the actual program for editing. Even emacsclient/gnuclient could do the trick. The only part where root privs are needed is *installing* the edited file. It'd be best to limit the root privs to where they are actually needed. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
What is the status with wu-ftpd updated potato packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I just signed up with the debian-security mailing list so I am not up to speed with all the discussions. What is the status with the wu-ftpd updated potato packages? I could find no mention of it on the debian main or security web pages and a search of several mailing lists showed no mention to what is being done about this exploit (The most recent wu-ftpd discussion was on Dec 4 / 6 in debian-user). Searching through the posts on the slashdot discussion made no mention of updating the packages either (though they did recomend switching to proftpd or even better bsd-ftpd which is based on openbsd). Announcements on bugtraq mention that debian is working on a patch, but updated stable/potato packages have not been released yet. I know redhat released their announcement early, but it pains me to see redhat ahead of debian on the security fix by almost 2 days. Are there other sysadmins using wu-ftpd and if so what are they doing about this vulnurability? thanks, donfede -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8BuDCSeRbV/op2s4RAjaMAJ40rz/LyNcf6i+CHXd8jSBflAjHxwCeLfL8 zcfPbkaTdKAGMCnyVOe7YEU= =9WdP -END PGP SIGNATURE-
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file #!/bin/bash # # sucpaliases # PATH=/sbin:/bin:/usr/sbin # # do some error checking too before executing these commands # mv /etc/aliases /etc/aliases.prev.xx mv /tmp/aliases /etc/aliases newaliases # # end of sucp c ya alvin On 29 Nov 2001, William R Ward wrote: William R Ward [EMAIL PROTECTED] writes: Is there any kind of wrapper that can be used to allow sudo to grant editing access to only one file? I am thinking of something similar to vipw or visudo, but with security in mind; following this basic algorithm: 1. Using user privileges, Copy the desired file to a temp file owned by the real user. 2. Using user privileges, Edit the temp file. 3. Using root privileges, copy the temp file to the final location.
Re: What is the status with wu-ftpd updated potato packages?
Read this: http://lists.debian.org/debian-changes/2001/debian-changes-200111/msg00085.html What is the status with the wu-ftpd updated potato packages?
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: VI wrapper for SUDO? - another bad way ??
hi ya bill if that sh script is called sucpaliases... you cannot(should not) put sudo sucpaliases inside of it - infinite recursion... the original idea was to copy and install the users versions of /etc/aliases file w/o giving um root or changing permissions... and not to allow sucpaliases to edit the file directly ( edit the file as a user ... -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access c ya alvin On Thu, 29 Nov 2001, William R. Ward wrote: Alvin Oga writes: how about: ( maybe a dumb idea but...a temporary answer?? user vi /etc/aliases - save it to /tmp/aliases user sucpaliases where sucp: and allow users to run sucp as root - add sucpaliases into the sudo file Not bad... then wrap the whole thing in a script.. editaliases would do the above steps #!/bin/sh tmpfile=/tmp/editaliases$$ cp /etc/aliases $tmpfile /etc/alternatives/editor $tmpfile sudo sucpaliases $tmpfile sudo newaliases # for good measure # end editaliases Question: Is it generally considered secure enough to sudo a bash script like your sucpaliases? Or should a C equivalent be written instead? --Bill.
Re: shutdown user and accountability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This would be a wonderful application of OTP's. On Thursday 29 November 2001 11:59 am, Niall Walsh wrote: Maybe put the password with the security guard so he can record who took the passwd to reset it (obviously you need to reset the password then etc.) - -- Warren GPG Fingerprint: 30C8 BDF1 B133 14CB 832F 2C5D 99A1 A19F 559D 9E88 GPG Public Key @ http://www.cbu.edu/~wturkal/wturkal.gpg - -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s: a-- C++ UL+ P+ L+++ E W++ N+ o-- K- w--- O M+ V-- PS+ PE Y+ PGP++ t 5 X R tv+ b+ DI+ D+ G e h-- r y? - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8BvComaGhn1WdnogRAng/AJwNaZIvi7U4TuO5j1mLLyE3iq5woQCeITxO eNSDlyPCBFljB5sd63pSQzU= =MXoU -END PGP SIGNATURE-
whats up? 687370480
Below is the result of your feedback form. It was submitted by ([EMAIL PROTECTED]) on Friday, November 30, 2001 at 03:40:39 --- : Hey, what's up, yall? I found a site and if you want to meet people and talk to people on webcam, you should check this out. They're now giving members totally free memberships!You don't even need your own webcam. You can watch live videos of family, friends, or anybody! What is there to lose?bra href=http://lllil.com/livewebcam;http://lllil.com/livewebcam brbrbrbr/aTo take yourself off my mailing list a href=http://lllil.com/list-offclick here/a.brbrbr338931680 ---
Encrypted Filesystems zing pow woosh
Just FYI, Slashdot has a discussionn up on encrypted file systems that might be of interest to folks who partisipated in the discussion here. This direct link might work: http://slashdot.org/article.pl?sid=01/11/28/1549252mode=thread Curt- --- Curt Howland +81-3-5772-5832 KVH Telecom Japan, Ltd.IDC Division
Re: VI wrapper for SUDO? - another bad way ??
Alvin Oga writes: if that sh script is called sucpaliases... you cannot(should not) put sudo sucpaliases inside of it - infinite recursion... Of course not. The script I wrote is editaliases and inside that script, your sucpaliases is called. -- another simpler way is to make /etc/aliases group writable and newaliases for sudo by certain users -- good and bad idea.. -- and you can put /etc/aliases into cvs control tooo These ideas are OK for some things, not for others. Sendmail is picky about the ownership and permissions on certain files. -- c code is subject to buffer overflow problems... -- scripts are susceptable to environment variables changing... Right - but I think the former is easier to thwart. Don't most Linux systems prohibit setuid shell scripts, for example? -- in either case... you have to trust your users that run the scripts/apps to replace /etc/aliases w/o giving um root access Of course, the idea is to give certain permissions to certain users without giving away the farm. That's what sudo's all about. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
