Re: Unidentified subject!
On Wed, Aug 08, 2001 at 12:08:22AM -0700, Petro wrote: > Are you talking about named.conf, or the master db files? First thing that came to my mind was /etc/resolv.conf, in the case that he just wanted to configure the name servers for his box. But, who knows. :-\
Re: Unidentified subject!
On Wed, Aug 08, 2001 at 12:08:22AM -0700, Petro wrote: > Are you talking about named.conf, or the master db files? First thing that came to my mind was /etc/resolv.conf, in the case that he just wanted to configure the name servers for his box. But, who knows. :-\ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Locking down a guest account - need help.
On Fri, Aug 03, 2001 at 08:09:25PM +, Jim Breton wrote: > You can also disable access with PAM, using the "sshd" pam control file. > Just use pam_deny.so to deny authentication. /me pops foot out of mouth When I wrote that I was not considering your previous statement of needing to still be able to log in normally with other accounts. My advice would have locked you out completely... so... don't use it. *8) Sorry. Something that _will_ work though (and I think I had this in mind when writing my first post but somehow confused myself) would be to make use of pam's /etc/security/access.conf. Here you can specify which users can log in on which ttys. HTH, for real this time. ;)
Re: Locking down a guest account - need help.
On Fri, Aug 03, 2001 at 01:56:26PM -0400, Andrew Lattis wrote: > 1. Check the openssh man page for AllowGroups and AllowUsers, both allow you > to > specify users that are allowed to login, everyone else is denied. You can also disable access with PAM, using the "sshd" pam control file. Just use pam_deny.so to deny authentication. You should combine both methods mentioned above, as well as whatever else you can find... the old "defense in depth" adage applies here. :)
Re: Locking down a guest account - need help.
On Fri, Aug 03, 2001 at 01:56:26PM -0400, Andrew Lattis wrote: > 1. Check the openssh man page for AllowGroups and AllowUsers, both allow you to > specify users that are allowed to login, everyone else is denied. You can also disable access with PAM, using the "sshd" pam control file. Just use pam_deny.so to deny authentication. You should combine both methods mentioned above, as well as whatever else you can find... the old "defense in depth" adage applies here. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pop3
On Mon, Jul 30, 2001 at 01:54:03PM -0700, Stephen Hassard wrote: > I was just playing around securing one of my Exchange boxes, and found that > coupling Stunnel (http://www.stunnel.org/) with your favourite mail server > works really well (not that Exchange is my pick for a secure mail server) Indeed, I have been doing exactly that and it works great. I run Solar Designer's 'popa3d' on port 110 for those users which do not have clients supporting TLS, but those who do are encouraged to use the POP3/TLS running on port 995 which is really just an stunnel to port 110 on the same machine. Outlook Express and many other clients have built-in support for this so there is very little tech support overhead.
Re: pop3
On Mon, Jul 30, 2001 at 01:54:03PM -0700, Stephen Hassard wrote: > I was just playing around securing one of my Exchange boxes, and found that > coupling Stunnel (http://www.stunnel.org/) with your favourite mail server > works really well (not that Exchange is my pick for a secure mail server) Indeed, I have been doing exactly that and it works great. I run Solar Designer's 'popa3d' on port 110 for those users which do not have clients supporting TLS, but those who do are encouraged to use the POP3/TLS running on port 995 which is really just an stunnel to port 110 on the same machine. Outlook Express and many other clients have built-in support for this so there is very little tech support overhead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pop3
On Mon, Jul 30, 2001 at 12:47:46PM -0600, Moe Harley wrote: > I'm more worried about people seeing > my pop3 service as a potential door into my network. See my first reply to you
Re: pop3
On Mon, Jul 30, 2001 at 12:47:46PM -0600, Moe Harley wrote: > I'm more worried about people seeing > my pop3 service as a potential door into my network. See my first reply to you -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pop3
On Sun, Jul 29, 2001 at 02:13:17PM -0600, Moe Harley wrote: > Thought i'd ask what the general opinion is on the most secure pop3 daemon. Here is one decent one: http://www.openwall.com/popa3d/
Re: pop3
On Sun, Jul 29, 2001 at 02:13:17PM -0600, Moe Harley wrote: > Thought i'd ask what the general opinion is on the most secure pop3 daemon. Here is one decent one: http://www.openwall.com/popa3d/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iptables install
On Fri, Jul 20, 2001 at 09:31:07PM -0700, Jeff Coppock wrote: ># modprobe ip_tables >modprobe: Can't locate module ip_tables > >But, it's definitely there. I can't figure out how to fix >this. Any help is very much appreciated. Your version of modutils's 'modprobe' doesn't look in the correct directories for modules (which are different in 2.4.x). You can either upgrade some of your packages (including modutils) in the manner suggested by others here (using Bunk's debs), or you can just use 'insmod' which will still work but you will have to specify the path to each module.
Re: iptables install
On Fri, Jul 20, 2001 at 09:31:07PM -0700, Jeff Coppock wrote: ># modprobe ip_tables >modprobe: Can't locate module ip_tables > >But, it's definitely there. I can't figure out how to fix >this. Any help is very much appreciated. Your version of modutils's 'modprobe' doesn't look in the correct directories for modules (which are different in 2.4.x). You can either upgrade some of your packages (including modutils) in the manner suggested by others here (using Bunk's debs), or you can just use 'insmod' which will still work but you will have to specify the path to each module. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iptables install
On Fri, Jul 20, 2001 at 12:37:49PM -0700, Jeff Coppock wrote: >Do I need to dist-upgrade to woody to use iptables? Nope. http://netfilter.samba.org Compiles very easily from source. HTH.
Re: iptables install
On Fri, Jul 20, 2001 at 12:37:49PM -0700, Jeff Coppock wrote: >Do I need to dist-upgrade to woody to use iptables? Nope. http://netfilter.samba.org Compiles very easily from source. HTH. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote: > > alias /bin/su='/var/tmp/hax0rSu' > > i would consider this a bug in the shell. I disagree; from the Bash man page: The alias name and the replacement text may con- tain any valid shell input, including the metacharacters listed above, with the exception that the alias name may not contain =. You could still say maybe it's a policy bug to allow this (and I would continue to disagree); but bug or not, beware - at least bash 2.03 and 2.05, and ash in potato work this way. So do pdksh (/bin/sh) on OpenBSD and /bin/sh (which is the same as our 'ash') on NetBSD. This also works for functions in bash.
Re: shared root account
On Sat, Jul 07, 2001 at 03:16:39AM -0800, Ethan Benson wrote: > > alias /bin/su='/var/tmp/hax0rSu' > > i would consider this a bug in the shell. I disagree; from the Bash man page: The alias name and the replacement text may con- tain any valid shell input, including the metacharacters listed above, with the exception that the alias name may not contain =. You could still say maybe it's a policy bug to allow this (and I would continue to disagree); but bug or not, beware - at least bash 2.03 and 2.05, and ash in potato work this way. So do pdksh (/bin/sh) on OpenBSD and /bin/sh (which is the same as our 'ash') on NetBSD. This also works for functions in bash. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > which may not work if you always type the > full path to /bin/su anyway. Hoping he doesn't: alias /bin/su='/var/tmp/hax0rSu'
Re: shared root account
On Sat, Jul 07, 2001 at 01:56:56AM -0800, Ethan Benson wrote: > which may not work if you always type the > full path to /bin/su anyway. Hoping he doesn't: alias /bin/su='/var/tmp/hax0rSu' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > compiling without module support would be mostly the same as just > > lcap CAP_SYS_MODULE Fwiw, I have heard (though not tested myself) that even if you compile your kernel _without_ loadable module support, you will still be able to insert modules into the running kernel. Again I have not tried this myself, but something to test for before relying on a certain behavior.
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote: > > compiling without module support would be mostly the same as just > > lcap CAP_SYS_MODULE Fwiw, I have heard (though not tested myself) that even if you compile your kernel _without_ loadable module support, you will still be able to insert modules into the running kernel. Again I have not tried this myself, but something to test for before relying on a certain behavior. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 10:48:22AM +0200, Craig wrote: > Now what i need to know, is woody stable enough for a proxy/firewall machine I do not know the answer to this as I haven't really used woody yet. But, the stuff you need to make it work smoothly on a potato box can be found starting from here: http://www.debian.org/News/2001/20010415 Fwiw, I had no problems at all using a 2.4 kernel on a regular potato box without the updates mentioned at that link, the only exception was that the old version of modprobe couldn't load any 2.4 modules. So you could: a) update to the modutils package included in the updates above; b) build all your drivers statically into the kernel, thereby not needing modutils; c) write some 'insmod' lines into your scripts to load modules, the old insmod still works fine (and is what I did). HTH.
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 10:48:22AM +0200, Craig wrote: > Now what i need to know, is woody stable enough for a proxy/firewall machine I do not know the answer to this as I haven't really used woody yet. But, the stuff you need to make it work smoothly on a potato box can be found starting from here: http://www.debian.org/News/2001/20010415 Fwiw, I had no problems at all using a 2.4 kernel on a regular potato box without the updates mentioned at that link, the only exception was that the old version of modprobe couldn't load any 2.4 modules. So you could: a) update to the modutils package included in the updates above; b) build all your drivers statically into the kernel, thereby not needing modutils; c) write some 'insmod' lines into your scripts to load modules, the old insmod still works fine (and is what I did). HTH. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 'locate' does not check permissions
On Thu, Jun 07, 2001 at 06:57:18PM -0300, Pedro Zorzenon Neto wrote: >$ locate private | grep "/home/pzn/private" > the whole contents of my private dir suddenly appears here... Did you run "updatedb" as root anytime recently? Notice that by default, this command is run (from cron) as user 'nobody,' so any directory he would not be able to read would not appear in the locate database. $ cat /etc/cron.daily/find #! /bin/sh # # cron script to update the `find.codes' database. # # Written by Ian A. Murdock <[EMAIL PROTECTED]> and #Kevin Dalley <[EMAIL PROTECTED]> if [ -f /etc/updatedb.conf ]; then . /etc/updatedb.conf fi cd / && updatedb --localuser=nobody 2>/dev/null Otoh if you just invoke 'updatedb' as root then every file on every filesystem scanned will appear in the database, hence producing the behavior you are seeing.
Re: 'locate' does not check permissions
On Thu, Jun 07, 2001 at 06:57:18PM -0300, Pedro Zorzenon Neto wrote: >$ locate private | grep "/home/pzn/private" > the whole contents of my private dir suddenly appears here... Did you run "updatedb" as root anytime recently? Notice that by default, this command is run (from cron) as user 'nobody,' so any directory he would not be able to read would not appear in the locate database. $ cat /etc/cron.daily/find #! /bin/sh # # cron script to update the `find.codes' database. # # Written by Ian A. Murdock <[EMAIL PROTECTED]> and #Kevin Dalley <[EMAIL PROTECTED]> if [ -f /etc/updatedb.conf ]; then . /etc/updatedb.conf fi cd / && updatedb --localuser=nobody 2>/dev/null Otoh if you just invoke 'updatedb' as root then every file on every filesystem scanned will appear in the database, hence producing the behavior you are seeing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: a FISH?!?!
On Sun, Jun 03, 2001 at 07:44:00AM +, Adam Olsen wrote: > So here I was playing around with some stuff in Quakeforge, and I see > a FISH swim across my root windows. Not surprisingly, my first > thought was HUH?! Second was probably WTF... http://marc.theaimsgroup.com/?t=9905757464&w=2&r=1
Re: a FISH?!?!
On Sun, Jun 03, 2001 at 07:44:00AM +, Adam Olsen wrote: > So here I was playing around with some stuff in Quakeforge, and I see > a FISH swim across my root windows. Not surprisingly, my first > thought was HUH?! Second was probably WTF... http://marc.theaimsgroup.com/?t=9905757464&w=2&r=1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X & tcp listening
On Fri, Jun 01, 2001 at 10:25:24PM +0200, Tomasz Olszewski wrote: > OK, I mentioned both startx and xinit but when I was talking about > ignoring the global xinitrc I reffered to xinit (because startx was > already not a problem). Oh ok. P.S. if you do modify the startx script it will be over-written on upgrades as I mentioned in another message, or, you can use dpkg-divert as another poster has suggested. > Who will guarantee that the an user will use an alias ;)? Right -- but then we come back to the part about "what is preventing them from opening any tcp port.. or running X directly.. etc.." :) Fwiw, stateful filtering (don't allow anything in that is not part of an outbound connection), or filtering out syn packets (ipchains with -y), or using a restricted shell with a wisely-chosen and prepared $PATH would get you out of this bind. Or all of the above. ;)
Re: X & tcp listening
On Sat, May 26, 2001 at 11:34:00PM +0200, Tomasz Olszewski wrote: > just modified /usr/X11R6/bin/startx but wat id someone launches plain > xinit? On Tue, May 29, 2001 at 01:50:10PM +0200, Tomasz Olszewski wrote: > I was thinking about it but I thought there may be a more "civilized" > way ;) However what if an user finds the real X? I see someone else has already addressed this, and I agree with him. ;) > > You mentioned you are using startx. man startx: > > As you can see above I mentioned that _xinit_ (not startx!) looks _only_ > for $HOME/.xserverrc and doesn't know anything about a global xserverrc. See above to where you referred to startx. > > aliasing startx in /etc/profile and making a script to determine the > > What for? Startx works fine fine a global xserverrc. Even if it didn't > (like xinit) making an alias would be _very_ naive :) Huh?
Re: X & tcp listening
On Fri, Jun 01, 2001 at 10:25:24PM +0200, Tomasz Olszewski wrote: > OK, I mentioned both startx and xinit but when I was talking about > ignoring the global xinitrc I reffered to xinit (because startx was > already not a problem). Oh ok. P.S. if you do modify the startx script it will be over-written on upgrades as I mentioned in another message, or, you can use dpkg-divert as another poster has suggested. > Who will guarantee that the an user will use an alias ;)? Right -- but then we come back to the part about "what is preventing them from opening any tcp port.. or running X directly.. etc.." :) Fwiw, stateful filtering (don't allow anything in that is not part of an outbound connection), or filtering out syn packets (ipchains with -y), or using a restricted shell with a wisely-chosen and prepared $PATH would get you out of this bind. Or all of the above. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X & tcp listening
On Sat, May 26, 2001 at 11:34:00PM +0200, Tomasz Olszewski wrote: > just modified /usr/X11R6/bin/startx but wat id someone launches plain > xinit? On Tue, May 29, 2001 at 01:50:10PM +0200, Tomasz Olszewski wrote: > I was thinking about it but I thought there may be a more "civilized" > way ;) However what if an user finds the real X? I see someone else has already addressed this, and I agree with him. ;) > > You mentioned you are using startx. man startx: > > As you can see above I mentioned that _xinit_ (not startx!) looks _only_ > for $HOME/.xserverrc and doesn't know anything about a global xserverrc. See above to where you referred to startx. > > aliasing startx in /etc/profile and making a script to determine the > > What for? Startx works fine fine a global xserverrc. Even if it didn't > (like xinit) making an alias would be _very_ naive :) Huh? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root fs/crypted
On Tue, May 29, 2001 at 11:54:29PM -0800, Ethan Benson wrote: > trouble is when your dealing with corrupt/fascist/evil > government/regimes encryption isn't going to do you much good, either > they will throw you in prison for refusing to disclose the decryption > key or worse they will use methods that make you very very eager to > reveal it Bearing in mind that the alternative is a non-encrypted FS, which leaves you no choice in the matter whatsoever. At least with an encrypted FS you are "secure by default" and can then judge what to do later based on the threat.
Re: root fs/crypted
On Tue, May 29, 2001 at 11:54:29PM -0800, Ethan Benson wrote: > trouble is when your dealing with corrupt/fascist/evil > government/regimes encryption isn't going to do you much good, either > they will throw you in prison for refusing to disclose the decryption > key or worse they will use methods that make you very very eager to > reveal it Bearing in mind that the alternative is a non-encrypted FS, which leaves you no choice in the matter whatsoever. At least with an encrypted FS you are "secure by default" and can then judge what to do later based on the threat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: losetup -e
On Mon, May 28, 2001 at 11:09:29PM -0400, S. Kraig wrote: > the 'international kernel' and after enabling that form of encryption... > so where do I start in doing this? http://www.kerneli.org/
Re: losetup -e
On Mon, May 28, 2001 at 11:09:29PM -0400, S. Kraig wrote: > the 'international kernel' and after enabling that form of encryption... > so where do I start in doing this? http://www.kerneli.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X & tcp listening
On Mon, May 28, 2001 at 01:46:07PM +0200, Tomasz Olszewski wrote: > If an user > creates his own $HOME/.xserverrc, it overrides the system wide > xserverrc. So make /usr/bin/X11/X a wrapper for the "real" X. Problem with this is, if you upgrade or re-install the package containing it, it will get replaced by the package's copy and you will have to do this again. > Besides, xinit looks only for user's private rc and doesn't > care if there is a global one. You mentioned you are using startx. man startx: To determine the server to run, startx first looks for a file called .xserverrc in the user's home directory. If that is not found, it uses the file xserverrc in the xinit library directory. If command line server options are given, they override this behavior. Users rarely need to provide a .xserverrc file. See the xinit(1) manual page for more details on the arguments. Granted, you would have an issue (as you indicated) if a user creates his own .xserverrc. So there are a number of ways around that, such as pre-creating them and making them immutable, or doing the wrapper script around /usr/bin/X11/X as mentioned above, etc.. There's probably a few other ways you could do this also, such as aliasing startx in /etc/profile and making a script to determine the next available display number, blablabla. Or you could pre-create the $HOME/.xserverrc files and put the -nolisten tcp argument in them, along with a note to the user to not remove that if he uses X, etc..
Re: X & tcp listening
On Mon, May 28, 2001 at 01:46:07PM +0200, Tomasz Olszewski wrote: > If an user > creates his own $HOME/.xserverrc, it overrides the system wide > xserverrc. So make /usr/bin/X11/X a wrapper for the "real" X. Problem with this is, if you upgrade or re-install the package containing it, it will get replaced by the package's copy and you will have to do this again. > Besides, xinit looks only for user's private rc and doesn't > care if there is a global one. You mentioned you are using startx. man startx: To determine the server to run, startx first looks for a file called .xserverrc in the user's home directory. If that is not found, it uses the file xserverrc in the xinit library directory. If command line server options are given, they override this behavior. Users rarely need to provide a .xserverrc file. See the xinit(1) manual page for more details on the arguments. Granted, you would have an issue (as you indicated) if a user creates his own .xserverrc. So there are a number of ways around that, such as pre-creating them and making them immutable, or doing the wrapper script around /usr/bin/X11/X as mentioned above, etc.. There's probably a few other ways you could do this also, such as aliasing startx in /etc/profile and making a script to determine the next available display number, blablabla. Or you could pre-create the $HOME/.xserverrc files and put the -nolisten tcp argument in them, along with a note to the user to not remove that if he uses X, etc.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X & tcp listening
On Sun, May 27, 2001 at 02:13:13PM +0200, Tomasz Olszewski wrote: > manual) this is not exactly what I was looking for but I think I'll try Yep... actually this _is_ the correct way to deal with this. I created this file with the following contents: #!/bin/sh exec /usr/bin/X11/X -nolisten tcp "$@" and made it executable (although this may have not been necessary... not sure).
Re: X & tcp listening
On Sun, May 27, 2001 at 02:13:13PM +0200, Tomasz Olszewski wrote: > manual) this is not exactly what I was looking for but I think I'll try Yep... actually this _is_ the correct way to deal with this. I created this file with the following contents: #!/bin/sh exec /usr/bin/X11/X -nolisten tcp "$@" and made it executable (although this may have not been necessary... not sure). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange log entry
On Thu, May 24, 2001 at 04:10:13PM +0900, Curt Howland wrote: > the last two i understand, as well as domain, but sunrpc and 1171? man fuser. Look for the "-n" option. > i've cleaned up everything i can think of, but X11R6 says it still needs the > RPC packages. Why does/would X11 require RPC?
Re: strange log entry
On Thu, May 24, 2001 at 04:10:13PM +0900, Curt Howland wrote: > the last two i understand, as well as domain, but sunrpc and 1171? man fuser. Look for the "-n" option. > i've cleaned up everything i can think of, but X11R6 says it still needs the > RPC packages. Why does/would X11 require RPC? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Got root?
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote: > I know that UNIX does it so that normal users can't seem like legit and > important services, but there surely must be some better way of delegating a > port below 1024 to a deamon. Well, at least on Linux, and with the right set of tools, one can do this using the kernel's capabilities. (Although I haven't touched the stuff much yet myself.) If you have a need to do this now and don't want to play with kernel caps then you might try the "authbind" package. I have used it before and it works! Package: authbind Priority: optional Section: utils Installed-Size: 42 Maintainer: Ian Jackson <[EMAIL PROTECTED]> Architecture: i386 Version: 1.1.5.1 Depends: libc6 Filename: dists/potato/main/binary-i386/utils/authbind_1.1.5.1.deb Size: 14216 MD5sum: 9edd71256e67889c8a0964bb8ddf93d7 Description: Allows non-root programs to bind() to low ports This package allows a package to be started as non-root but still bind to low ports, without any changes to the application.
Re: Got root?
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote: > I know that UNIX does it so that normal users can't seem like legit and > important services, but there surely must be some better way of delegating a > port below 1024 to a deamon. Well, at least on Linux, and with the right set of tools, one can do this using the kernel's capabilities. (Although I haven't touched the stuff much yet myself.) If you have a need to do this now and don't want to play with kernel caps then you might try the "authbind" package. I have used it before and it works! Package: authbind Priority: optional Section: utils Installed-Size: 42 Maintainer: Ian Jackson <[EMAIL PROTECTED]> Architecture: i386 Version: 1.1.5.1 Depends: libc6 Filename: dists/potato/main/binary-i386/utils/authbind_1.1.5.1.deb Size: 14216 MD5sum: 9edd71256e67889c8a0964bb8ddf93d7 Description: Allows non-root programs to bind() to low ports This package allows a package to be started as non-root but still bind to low ports, without any changes to the application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logging practices (and why does it suck in Debian?)
On Wed, Apr 11, 2001 at 10:10:38PM -0700, Jamie Heilman wrote: > Dan Bernstein's multilog program is the only logger I've seen that offers > various reliability guarentees and actually delivers on them, but it has > some prerequisites for usage that can frequently be difficult to meet. > What I'd really like to see is a facility logger that could collect logs > like traditional syslog but then would let me hand them to something like > multilog to be stored on disk. Some such solutions are intermittently discussed, designed, etc. on the [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. :) http://cr.yp.to/lists.html
Re: Logging practices (and why does it suck in Debian?)
On Wed, Apr 11, 2001 at 10:10:38PM -0700, Jamie Heilman wrote: > Dan Bernstein's multilog program is the only logger I've seen that offers > various reliability guarentees and actually delivers on them, but it has > some prerequisites for usage that can frequently be difficult to meet. > What I'd really like to see is a facility logger that could collect logs > like traditional syslog but then would let me hand them to something like > multilog to be stored on disk. Some such solutions are intermittently discussed, designed, etc. on the [EMAIL PROTECTED] list. Suggest you subscribe and hang out for a while. :) http://cr.yp.to/lists.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: setting up sudo for tail
On Thu, Apr 12, 2001 at 12:38:10AM +, Adam Olsen wrote: > So my question: how do I set this up properly? Not with sudo. ;) chgrp adm /var/log/syslog # change group of file to "adm" adduser (yourself) adm # put yourself into group "adm" logout log in again :bam: ;D
Re: setting up sudo for tail
On Thu, Apr 12, 2001 at 12:38:10AM +, Adam Olsen wrote: > So my question: how do I set this up properly? Not with sudo. ;) chgrp adm /var/log/syslog # change group of file to "adm" adduser (yourself) adm # put yourself into group "adm" logout log in again :bam: ;D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packet filtering help
On Tue, Apr 10, 2001 at 12:13:52PM +0200, Vaclav Hula wrote: > RFC compliancy isn't enough? IMHO should be. Someone else has already responded to this; but no, RFC compliance doesn't necessarily tell us the best thing to do for every situation. Take syn cookies for example. > > A decent policy is to drop everything you don't need to respond to. > > breaking everything you do not need to work isn't decent. someone else might > need. What are you talking about? If you need this for someone else to be able to contact you then this falls into the "you need this" category. Simple. > > You do gain some "security through obscurity." Depending on how much > > "security through obscurity." = "false feeling of security" :-) No, because there's nothing falsified about this. If you know what you are doing then you know exactly what you are _not_ gaining as well as what you are gaining. I already explained this. > > For instance, many script kiddies will not scan your entire box if you > > are undetected by a ping sweep. Granted, if you have other > > vulnerabilities that you are hiding then you have bigger problems. But > > it can buy you some time at least. > > Script kiddie scanning your entire box won't hurt you much. Where did I say it would? This has nothing to do with the scan; it has something to do with the kiddie's next move (if any) _after_ detecting your box.
Re: Packet filtering help
On Tue, Apr 10, 2001 at 12:13:52PM +0200, Vaclav Hula wrote: > RFC compliancy isn't enough? IMHO should be. Someone else has already responded to this; but no, RFC compliance doesn't necessarily tell us the best thing to do for every situation. Take syn cookies for example. > > A decent policy is to drop everything you don't need to respond to. > > breaking everything you do not need to work isn't decent. someone else might > need. What are you talking about? If you need this for someone else to be able to contact you then this falls into the "you need this" category. Simple. > > You do gain some "security through obscurity." Depending on how much > > "security through obscurity." = "false feeling of security" :-) No, because there's nothing falsified about this. If you know what you are doing then you know exactly what you are _not_ gaining as well as what you are gaining. I already explained this. > > For instance, many script kiddies will not scan your entire box if you > > are undetected by a ping sweep. Granted, if you have other > > vulnerabilities that you are hiding then you have bigger problems. But > > it can buy you some time at least. > > Script kiddie scanning your entire box won't hurt you much. Where did I say it would? This has nothing to do with the scan; it has something to do with the kiddie's next move (if any) _after_ detecting your box. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packet filtering help
On Mon, Apr 09, 2001 at 03:20:00PM -0400, Noah L. Meyerhans wrote: > Ask yourself this: *Why* should ICMP be filtered? What are you gaining? > Do you sleep better at night knowing that your machine won't respond to > pings? It really doesn't make you any safer. What are you gaining by responding to them? A decent policy is to drop everything you don't need to respond to. Now, if you need to reply to pings, etc. for debugging purposes, or for availability monitoring, etc. then that is a valid reason. > I don't feel like you gain any security by DENYing connections or by > filtering ICMP. You do gain some "security through obscurity." Depending on how much you value this contributes to your subsequent choice. For instance, many script kiddies will not scan your entire box if you are undetected by a ping sweep. Granted, if you have other vulnerabilities that you are hiding then you have bigger problems. But it can buy you some time at least. I'm sure this is a perfectly flammable post, so discussion is encouraged. ;)
Re: Packet filtering help
On Mon, Apr 09, 2001 at 03:20:00PM -0400, Noah L. Meyerhans wrote: > Ask yourself this: *Why* should ICMP be filtered? What are you gaining? > Do you sleep better at night knowing that your machine won't respond to > pings? It really doesn't make you any safer. What are you gaining by responding to them? A decent policy is to drop everything you don't need to respond to. Now, if you need to reply to pings, etc. for debugging purposes, or for availability monitoring, etc. then that is a valid reason. > I don't feel like you gain any security by DENYing connections or by > filtering ICMP. You do gain some "security through obscurity." Depending on how much you value this contributes to your subsequent choice. For instance, many script kiddies will not scan your entire box if you are undetected by a ping sweep. Granted, if you have other vulnerabilities that you are hiding then you have bigger problems. But it can buy you some time at least. I'm sure this is a perfectly flammable post, so discussion is encouraged. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Droping untracked packet
On Mon, Apr 09, 2001 at 01:42:25AM +0200, Robert Magier wrote: > I have seen this since I installed 2.4.0 kernel and iptables. http://netfilter.samba.org/netfilter-faq-3.html#ss3.1
Re: Droping untracked packet
On Mon, Apr 09, 2001 at 01:42:25AM +0200, Robert Magier wrote: > I have seen this since I installed 2.4.0 kernel and iptables. http://netfilter.samba.org/netfilter-faq-3.html#ss3.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Promiscuous mode (was Re: ifconfig doesn't report Promiscuous interfaces)
On Fri, Mar 16, 2001 at 10:27:23PM -0600, JonesMB wrote: > Is there any reason for eth0 to be showing PROMISC all the time or is this Some apps put the card into promisc mode and do not turn off promisc when you exit.
Re: Promiscuous mode (was Re: ifconfig doesn't report Promiscuous interfaces)
On Fri, Mar 16, 2001 at 10:27:23PM -0600, JonesMB wrote: > Is there any reason for eth0 to be showing PROMISC all the time or is this Some apps put the card into promisc mode and do not turn off promisc when you exit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 06:58:07PM -0400, Peter Cordes wrote: > On Mon, Mar 12, 2001 at 06:36:25PM +0000, Jim Breton wrote: > > It does do what you describe; however the original question is about > > evil packet _destinations_ and not evil packet _sources._ > > No, I just checked linux/Documentation/filesystems/proc.txt, and it points > out that this is a source check. Destination is always checked, since it is > incorrect not to do so, not just a security risk. rp_filter filters out > some packets that are allowed by the protocols, but are obviously bogus in a > normal network. Again, I'm not disagreeing with you. rp_filter and source checking has nothing to do with the issue though. The question posed was about packet destinations, and you keep referring to source checks. Read the original post again. Also read my post where I mentioned that more verbose logging of such a packet may be useful; the kernel's martian logging is not very verbose. Try it and you will see what I mean. Fwiw whether the firewall framework in 2.2 will even pick it up in the input chain is beyond me, you would have to try it. 2.4 won't, you have to do it in the mangle table as far as I can tell (works for me there, but not in the filter table). Thanks.
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 06:58:07PM -0400, Peter Cordes wrote: > On Mon, Mar 12, 2001 at 06:36:25PM +0000, Jim Breton wrote: > > It does do what you describe; however the original question is about > > evil packet _destinations_ and not evil packet _sources._ > > No, I just checked linux/Documentation/filesystems/proc.txt, and it points > out that this is a source check. Destination is always checked, since it is > incorrect not to do so, not just a security risk. rp_filter filters out > some packets that are allowed by the protocols, but are obviously bogus in a > normal network. Again, I'm not disagreeing with you. rp_filter and source checking has nothing to do with the issue though. The question posed was about packet destinations, and you keep referring to source checks. Read the original post again. Also read my post where I mentioned that more verbose logging of such a packet may be useful; the kernel's martian logging is not very verbose. Try it and you will see what I mean. Fwiw whether the firewall framework in 2.2 will even pick it up in the input chain is beyond me, you would have to try it. 2.4 won't, you have to do it in the mangle table as far as I can tell (works for me there, but not in the filter table). Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 02:31:57PM -0400, Peter Cordes wrote: > Doesn't rp_filter do this, or am I missing something? It should make the > kernel drop packets coming in on interfaces they shouldn't be, e.g. 10.0.0.0 > packets coming from an interface to 192.168.1.0. It does do what you describe; however the original question is about evil packet _destinations_ and not evil packet _sources._
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 02:31:57PM -0400, Peter Cordes wrote: > Doesn't rp_filter do this, or am I missing something? It should make the > kernel drop packets coming in on interfaces they shouldn't be, e.g. 10.0.0.0 > packets coming from an interface to 192.168.1.0. It does do what you describe; however the original question is about evil packet _destinations_ and not evil packet _sources._ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Sat, Mar 10, 2001 at 10:22:48AM -0600, Ted Cabeen wrote: > if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr)) > goto martian_destination; > > This is part of the routing check for incoming packets. It should take > care of the problem being discussed. :) > > (I haven't tested this section of the code, but it should prevent that kind > of attack, I think) It should yes, however see the recent thread on Bugtraq about this issue. Also since log_martians is not enabled by default (unless your distro does so, and afaict potato at least does not) you will never hear a word about these packets. Logging them would be nice. Even with log_martians enabled, it doesn't tell you anything about the packet other than src, dst, and iface. Further, I'm not sure the martian code would stop a packet from landing on an "internal" interface other than loopback (again see the Bugtraq discussion) which is why we should (and do) filter the destination addresses of incoming packets as well as the source addresses. Thanks.
Re: 127.0.0.0/8 addresses from the network
On Sat, Mar 10, 2001 at 10:22:48AM -0600, Ted Cabeen wrote: > if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr)) > goto martian_destination; > > This is part of the routing check for incoming packets. It should take > care of the problem being discussed. :) > > (I haven't tested this section of the code, but it should prevent that kind > of attack, I think) It should yes, however see the recent thread on Bugtraq about this issue. Also since log_martians is not enabled by default (unless your distro does so, and afaict potato at least does not) you will never hear a word about these packets. Logging them would be nice. Even with log_martians enabled, it doesn't tell you anything about the packet other than src, dst, and iface. Further, I'm not sure the martian code would stop a packet from landing on an "internal" interface other than loopback (again see the Bugtraq discussion) which is why we should (and do) filter the destination addresses of incoming packets as well as the source addresses. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 10:09:13PM -0600, Ted Cabeen wrote: > Actually we trap illegal packets like this one in I15lospoof.def. > > :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address > :#: over a non-'lo' interface Double-check that against the original question: "is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ?" Notice he said "_to_ 127.0.0.0/8" and not "_from_" which is what I15lospoof.def blocks. I made the same mistake in my first post, then re-read his question.
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:49:54PM +, Jim Breton wrote: > # deny and log all packets trying to come in from a 127.0.0.0/8 address > # over a non-'lo' interface Oops. Just occurred to me that this is not what you were asking about. Why do I do such things? Anyway. /etc/ipmasq/rules/I90external.def # accept incoming packets from external networks on external interfaces ipchains) $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 if [ -n "$BCOFIF" ]; then $IPCHAINS -A input -j ACCEPT -i $i -d $BCOFIF/32 fi ;; Since we have a default drop and log coming later in the rules (/etc/ipmasq/rules/ZZZdenyandlog.def), this will take care of your concern.
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 10:09:13PM -0600, Ted Cabeen wrote: > Actually we trap illegal packets like this one in I15lospoof.def. > > :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address > :#: over a non-'lo' interface Double-check that against the original question: "is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ?" Notice he said "_to_ 127.0.0.0/8" and not "_from_" which is what I15lospoof.def blocks. I made the same mistake in my first post, then re-read his question. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:49:54PM +, Jim Breton wrote: > # deny and log all packets trying to come in from a 127.0.0.0/8 address > # over a non-'lo' interface Oops. Just occurred to me that this is not what you were asking about. Why do I do such things? Anyway. /etc/ipmasq/rules/I90external.def # accept incoming packets from external networks on external interfaces ipchains) $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 if [ -n "$BCOFIF" ]; then $IPCHAINS -A input -j ACCEPT -i $i -d $BCOFIF/32 fi ;; Since we have a default drop and log coming later in the rules (/etc/ipmasq/rules/ZZZdenyandlog.def), this will take care of your concern. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:47:41AM -0400, Peter Cordes wrote: > Yes. It uses rp_filter (this is controlled in /proc/sys/... Read Also by: /etc/ipmasq/rules/I15lospoof.def if you have the ipmasq package installed: # deny and log all packets trying to come in from a 127.0.0.0/8 address # over a non-'lo' interface [snip] ipchains) $IPCHAINS -A input -j DENY -i !lo -s 127.0.0.1/255.0.0.0 -l ;; Btw, to the original poster: any rules said to apply to "2.1" kernels also apply to 2.2 kernels... not to worry. HTH.
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:47:41AM -0400, Peter Cordes wrote: > Yes. It uses rp_filter (this is controlled in /proc/sys/... Read Also by: /etc/ipmasq/rules/I15lospoof.def if you have the ipmasq package installed: # deny and log all packets trying to come in from a 127.0.0.0/8 address # over a non-'lo' interface [snip] ipchains) $IPCHAINS -A input -j DENY -i !lo -s 127.0.0.1/255.0.0.0 -l ;; Btw, to the original poster: any rules said to apply to "2.1" kernels also apply to 2.2 kernels... not to worry. HTH. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] install openssh 2.5.x
On Mon, Mar 05, 2001 at 10:48:23AM -0500, K 0 wrote: > i un tarred-gziiped it and saw no installation instructions nor configure > scripts ... a straight make does work too. Sounds like you got the wrong tarball. Did you get it from this page? http://www.openssh.com/portable.html
Re: [OT] install openssh 2.5.x
On Mon, Mar 05, 2001 at 10:48:23AM -0500, K 0 wrote: > i un tarred-gziiped it and saw no installation instructions nor configure > scripts ... a straight make does work too. Sounds like you got the wrong tarball. Did you get it from this page? http://www.openssh.com/portable.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apt-get package verification
On Sat, Feb 10, 2001 at 07:54:49PM +0100, Carel Fellinger wrote: > [-- PGP output follows (current time: Sat Feb 10 19:40:06 2001) --] > gpg: Signature made Sat 10 Feb 2001 06:11:01 PM CET using DSA key ID EBF15399 > gpg: Good signature from "Marco Ghidinelli <[EMAIL PROTECTED]>" > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > gpg: Fingerprint: 1C34 97F7 1837 D525 7E3F C883 B572 DF1A EBF1 5399 > [-- End of PGP output --] > > But I'm quit willing to trust debian developers in general. I trust them > with the packages, might as well trust their identity:) I'm a bit uncertain > how to achieve this though. Is it enough if I tell gpg to trust James Troup? You don't need to assign any trust to these keys; it's enough to get the "Good signature..." output. As long as the signature verifies successfully (as it does in your example above), you know that the person who created the key you've got on your keyring is the same person who sent the message/signed the package/whatever. The issue of trusting the key is a separate one: it answers the question, "was this key created by the person whose name appears in the key?" If you can unconditionally answer Yes to this question then go ahead and sign the key. Otherwise you do not REALLY know that that key was created by that person. For instance, when I see security advisories sent by Wichert Akkerman, I verify the signature using his public key which is on my keyring. As long as it says "Good signature" then I can be certain that it was signed by whoever created the public key I've got. But, unless I have actually met him in person or spoken to him, etc. or otherwise verified WITHOUT ANY DOUBT that he created that key, I should not assign trust to that key. None of this is any different from how you should handle anyone else's keys, this is all standard procedure.
Re: Apt-get package verification
On Sat, Feb 10, 2001 at 07:54:49PM +0100, Carel Fellinger wrote: > [-- PGP output follows (current time: Sat Feb 10 19:40:06 2001) --] > gpg: Signature made Sat 10 Feb 2001 06:11:01 PM CET using DSA key ID EBF15399 > gpg: Good signature from "Marco Ghidinelli <[EMAIL PROTECTED]>" > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > gpg: Fingerprint: 1C34 97F7 1837 D525 7E3F C883 B572 DF1A EBF1 5399 > [-- End of PGP output --] > > But I'm quit willing to trust debian developers in general. I trust them > with the packages, might as well trust their identity:) I'm a bit uncertain > how to achieve this though. Is it enough if I tell gpg to trust James Troup? You don't need to assign any trust to these keys; it's enough to get the "Good signature..." output. As long as the signature verifies successfully (as it does in your example above), you know that the person who created the key you've got on your keyring is the same person who sent the message/signed the package/whatever. The issue of trusting the key is a separate one: it answers the question, "was this key created by the person whose name appears in the key?" If you can unconditionally answer Yes to this question then go ahead and sign the key. Otherwise you do not REALLY know that that key was created by that person. For instance, when I see security advisories sent by Wichert Akkerman, I verify the signature using his public key which is on my keyring. As long as it says "Good signature" then I can be certain that it was signed by whoever created the public key I've got. But, unless I have actually met him in person or spoken to him, etc. or otherwise verified WITHOUT ANY DOUBT that he created that key, I should not assign trust to that key. None of this is any different from how you should handle anyone else's keys, this is all standard procedure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Interoperability between sftp and ftp GUI from ssh.com?
On Mon, Feb 12, 2001 at 03:14:23PM +0100, Thomas Gebhardt wrote: > A quick test with OpenSSH 2.3 + sftp 0.9.5 and SSH 2.1 Windows > Client did not succeed. I had similar failures with scp, sftp, and gftp using the OpenSSH-2.3.0 server. IIRC my server logs had something like "... we do not read..." blablah in them... check your logs for something similar. It's a known problem with OpenSSH-2.3.0. :( (It's discussed in the openssh mailing list archive.) Otoh if you are not seeing this problem, then maybe something else is wrong which hopefully is correctable?
Re: Interoperability between sftp and ftp GUI from ssh.com?
On Mon, Feb 12, 2001 at 03:14:23PM +0100, Thomas Gebhardt wrote: > A quick test with OpenSSH 2.3 + sftp 0.9.5 and SSH 2.1 Windows > Client did not succeed. I had similar failures with scp, sftp, and gftp using the OpenSSH-2.3.0 server. IIRC my server logs had something like "... we do not read..." blablah in them... check your logs for something similar. It's a known problem with OpenSSH-2.3.0. :( (It's discussed in the openssh mailing list archive.) Otoh if you are not seeing this problem, then maybe something else is wrong which hopefully is correctable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IPTables, IRC, and SSH
On Sat, Feb 03, 2001 at 12:38:47PM -0700, Troy Telford wrote: > I would like to use the state-tracking for IRC, but simply having the > --state established,related (and new... but I don't think that's > necessary) --sport irc(d) options doesn't seem to do anything... Correct, "NEW" is not necessary. > I can connect TO the IRC server, but it won't allow a login. I've read > that it has something to do with ICMP, but I don't know exactly what, > nor how to fix it. Possibly they ping your machine (regarding ICMP), though I've never heard of that before. What is _more_ likely is that they require IDENT support on your machine. If this is the case then you would need to run an identd on your box... my recommendation would be oidentd ( http://ojnk.sourceforge.net/ , or the Debian package which is a little bit old). Naturally you would also need to allow connections to this daemon, so tcp INPUT NEW,ESTABLISHED and OUTPUT ESTABLISHED would need to be permitted. > Second - SSH - I would like iptables to accept incoming connections to > OpenSSH, but from a specific domain (myschool.edu). However, I don't > know the IP range for the domain, nor do I know how to set IPtables to > allow connections from only that domain. In short - you can't. You can pass hostnames to iptables, but it will only match the results of a DNS lookup which may not include all the remote addresses you want. Your options are: A- take the time to find out all the possible source addresses, and allow connections from those; B- use tcp_wrappers support with OpenSSH and use your /etc/hosts.[deny|allow] to manage access to the service based on the remote address. C- run OpenSSH under a superserver such as xinetd or inetd which has tcp_wrappers support, and follow "B" above. > So what commands do I need to use for SSH? > (Again, with state tracking would be preferred). As with identd, you will need to allow tcp INPUT NEW,ESTABLISHED and OUTPUT ESTABLISHED to that port.
Re: IPTables, IRC, and SSH
On Sat, Feb 03, 2001 at 12:38:47PM -0700, Troy Telford wrote: > I would like to use the state-tracking for IRC, but simply having the > --state established,related (and new... but I don't think that's > necessary) --sport irc(d) options doesn't seem to do anything... Correct, "NEW" is not necessary. > I can connect TO the IRC server, but it won't allow a login. I've read > that it has something to do with ICMP, but I don't know exactly what, > nor how to fix it. Possibly they ping your machine (regarding ICMP), though I've never heard of that before. What is _more_ likely is that they require IDENT support on your machine. If this is the case then you would need to run an identd on your box... my recommendation would be oidentd ( http://ojnk.sourceforge.net/ , or the Debian package which is a little bit old). Naturally you would also need to allow connections to this daemon, so tcp INPUT NEW,ESTABLISHED and OUTPUT ESTABLISHED would need to be permitted. > Second - SSH - I would like iptables to accept incoming connections to > OpenSSH, but from a specific domain (myschool.edu). However, I don't > know the IP range for the domain, nor do I know how to set IPtables to > allow connections from only that domain. In short - you can't. You can pass hostnames to iptables, but it will only match the results of a DNS lookup which may not include all the remote addresses you want. Your options are: A- take the time to find out all the possible source addresses, and allow connections from those; B- use tcp_wrappers support with OpenSSH and use your /etc/hosts.[deny|allow] to manage access to the service based on the remote address. C- run OpenSSH under a superserver such as xinetd or inetd which has tcp_wrappers support, and follow "B" above. > So what commands do I need to use for SSH? > (Again, with state tracking would be preferred). As with identd, you will need to allow tcp INPUT NEW,ESTABLISHED and OUTPUT ESTABLISHED to that port. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ISPs offering ssl-encrypted e-mail?
On Fri, Feb 02, 2001 at 07:08:57PM +0100, Philippe BARNETCHE wrote: > I still don't understand how to handle with mutt the mails that have been pgp > signed with kmail. Are you talking about verifying signatures? I usually just pipe mine through gpg --verify... | gpg --verify Works for me. (There may be a better way... I know some ppl run messages through procmail first to give them the proper headers.)
Re: ISPs offering ssl-encrypted e-mail?
On Fri, Feb 02, 2001 at 07:08:57PM +0100, Philippe BARNETCHE wrote: > I still don't understand how to handle with mutt the mails that have been pgp signed >with kmail. Are you talking about verifying signatures? I usually just pipe mine through gpg --verify... | gpg --verify Works for me. (There may be a better way... I know some ppl run messages through procmail first to give them the proper headers.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
in.ftpd (from ftpd package) vulnerable to recent exploits?
Does anyone know if our "default" ftp daemon from the ftpd package is vulnerable to the recent issue found with the OpenBSD ftpd? I don't see anything about it in the BTS, but I haven't heard anyone ask, either. ;)
in.ftpd (from ftpd package) vulnerable to recent exploits?
Does anyone know if our "default" ftp daemon from the ftpd package is vulnerable to the recent issue found with the OpenBSD ftpd? I don't see anything about it in the BTS, but I haven't heard anyone ask, either. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Items for the HOWTO (was Re: OS Hardening)
On Wed, Dec 13, 2000 at 11:11:52AM +0100, Javier Fernandez-Sanguino Pe?a wrote: > *Please* post it. It could be really useful for documents like the > Securing-Debian-HOWTO, I have my own checklist and will update the HOWTO with > it > soon. > > So, for all of you.. new thread? : checklist of things to do for a > secure > setup? One other thing I try to be conscious of... while it can be a good idea to change the listen port of a service (such as putting ssh on a port != 22 for example), fwictl it's important to make sure any authenticating service remain on a port <=1023. Otherwise, should the "real" service fail, it would provide an opportunity for a luser to bind to its port and: 1- deny real users access 2- steal/record auth info or whatever with a rogue daemon P.S. In http://www.debian.org/doc/manuals/securing-debian-howto/ch4.html#s4.1 "Listen 666" should be "Port 666" to change the port #. Thanks. :)
Items for the HOWTO (was Re: OS Hardening)
On Wed, Dec 13, 2000 at 11:11:52AM +0100, Javier Fernandez-Sanguino Pe?a wrote: > *Please* post it. It could be really useful for documents like the > Securing-Debian-HOWTO, I have my own checklist and will update the HOWTO with it > soon. > > So, for all of you.. new thread? : checklist of things to do for a secure > setup? One other thing I try to be conscious of... while it can be a good idea to change the listen port of a service (such as putting ssh on a port != 22 for example), fwictl it's important to make sure any authenticating service remain on a port <=1023. Otherwise, should the "real" service fail, it would provide an opportunity for a luser to bind to its port and: 1- deny real users access 2- steal/record auth info or whatever with a rogue daemon P.S. In http://www.debian.org/doc/manuals/securing-debian-howto/ch4.html#s4.1 "Listen 666" should be "Port 666" to change the port #. Thanks. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mutt/gnupg
On Mon, Dec 11, 2000 at 04:26:45PM -0300, Eduardo Gargiulo wrote: > I'm new using mutt. > I want to send my messeges clear signed, but I can't. > I'm using gnupg, and I put in my .muttrc > set pgp_sign_command="gpg --clearsign" > but the signature is attached in binary format. How can I sign my messages in > ASCII from mutt? You need to add the --armor argument to get ascii output. Btw, Mutt comes with a sample gpg rc file which you can source to get most of this working flawlessly and without any extra effort: /usr/local/doc/mutt/samples/gpg.rc Or if you are using the Mutt package, it might be in /usr/share/doc somewhere. Fyi, that file contains the following line: set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f" In your .muttrc file, put the line: source /usr/local/doc/mutt/samples/gpg.rc
Re: Mutt/gnupg
On Mon, Dec 11, 2000 at 04:26:45PM -0300, Eduardo Gargiulo wrote: > I'm new using mutt. > I want to send my messeges clear signed, but I can't. > I'm using gnupg, and I put in my .muttrc > set pgp_sign_command="gpg --clearsign" > but the signature is attached in binary format. How can I sign my messages in ASCII >from mutt? You need to add the --armor argument to get ascii output. Btw, Mutt comes with a sample gpg rc file which you can source to get most of this working flawlessly and without any extra effort: /usr/local/doc/mutt/samples/gpg.rc Or if you are using the Mutt package, it might be in /usr/share/doc somewhere. Fyi, that file contains the following line: set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f" In your .muttrc file, put the line: source /usr/local/doc/mutt/samples/gpg.rc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT?] Replacing hacked binaries
On Thu, Nov 30, 2000 at 11:38:09PM -0600, Michael Janssen (CS/MATH stud.) wrote: > I was wondering, in my thought ramblings, if there was a easy way to > replace ALL binaries that are in a installed package with their > (hoprfully) original states. i.e. If a machine was to fall victim to > a rootkit attack, how could I effectively re-install all the "debian > original" binaries to de-rootkit it? While I'm sure you could work up some script(s) to perform an "apt-get --reinstall install " on all your installed packages, this won't protect you from a modified apt-get or dpkg (though unlikely), nor will it let you sleep well at night knowing that there's nothing else floating around on your system that will run from a cron job or whatever. If the system has been r00ted, you really should back up all your data (or the whole system if you have enough backup space to do so) and re-install the machine from scratch. Also perform some inspections on your old data to see if you can figure out how it was cracked... and of course try to make sure it doesn't happen again! :) P.S. You might want to check out the "debsums" package, it's a nice tool to have in your collection.
Re: [OT?] Replacing hacked binaries
On Thu, Nov 30, 2000 at 11:38:09PM -0600, Michael Janssen (CS/MATH stud.) wrote: > I was wondering, in my thought ramblings, if there was a easy way to > replace ALL binaries that are in a installed package with their > (hoprfully) original states. i.e. If a machine was to fall victim to > a rootkit attack, how could I effectively re-install all the "debian > original" binaries to de-rootkit it? While I'm sure you could work up some script(s) to perform an "apt-get --reinstall install " on all your installed packages, this won't protect you from a modified apt-get or dpkg (though unlikely), nor will it let you sleep well at night knowing that there's nothing else floating around on your system that will run from a cron job or whatever. If the system has been r00ted, you really should back up all your data (or the whole system if you have enough backup space to do so) and re-install the machine from scratch. Also perform some inspections on your old data to see if you can figure out how it was cracked... and of course try to make sure it doesn't happen again! :) P.S. You might want to check out the "debsums" package, it's a nice tool to have in your collection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: all .deb md5sums
On Sun, Oct 29, 2000 at 03:52:40PM +, sena wrote: > Why not check the sums of the ISOs? I'm sure the site where you downloaded > them must have the md5sums for the ISOs... Yes they do, and I have checked them. But this is putting an additional layer of trust into whoever created the ISO. That's really not satisfactory and doesn't give me a path of trust to the package maintainers. (Unless Debian post ISO md5sums on the site somewhere, against which I could compare the linuxiso sums... but I haven't seen this posted anywhere either... is it?)
all .deb md5sums
Is there someplace on debian.org from which I can get a file or files containing the md5sums of all the packages? Not the packages' contents, but the packages themselves. I have some ISOs I got from another site (linuxiso.org) and I would like to confirm the sums of all the packages before I use them for installs. Thanks.
Re: all .deb md5sums
On Sun, Oct 29, 2000 at 03:52:40PM +, sena wrote: > Why not check the sums of the ISOs? I'm sure the site where you downloaded > them must have the md5sums for the ISOs... Yes they do, and I have checked them. But this is putting an additional layer of trust into whoever created the ISO. That's really not satisfactory and doesn't give me a path of trust to the package maintainers. (Unless Debian post ISO md5sums on the site somewhere, against which I could compare the linuxiso sums... but I haven't seen this posted anywhere either... is it?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
all .deb md5sums
Is there someplace on debian.org from which I can get a file or files containing the md5sums of all the packages? Not the packages' contents, but the packages themselves. I have some ISOs I got from another site (linuxiso.org) and I would like to confirm the sums of all the packages before I use them for installs. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OTP (opie) and ssh
On Mon, Sep 18, 2000 at 09:18:05PM -0300, Henrique M Holschuh wrote: > Yeah, those do solve the worst problem with OPIE. There's nothing wrong with > OTPs when properly designed (i.e.: no sheets of paper ;-) ), but since the > original poster was talking about OPIE... Using OPIE doesn't mean you have to carry around "sheets of paper." OPIE is perfectly capable of authenticating against OTPs generated by any S/Key-compatible generator. So.. re-focusing on trying to solve his problem would be a big help to him as well as everyone else. ;) Anyway regarding OPIE usage with OpenSSH, it supports S/Key auth natively but AFAICT the reason OPIE doesn't work correctly has something to do with ssh and/or PAM not being able to print the challenge correctly. I really don't know the whole story, but I was trying to figure a way to get OPIE working with OpenSSH myself and saw something to this effect on the portable OpenSSH development list archive. Seems to me the correct way to support OPIE MAY be to petition the developers to include it. In fact, there is a patch already floating around that does this (seen on the aforementioned list archive), though it was for an older version of OpenSSH so I haven't tried it. Note that I am using a self-compiled installation; that patch may be appropriate for the Debian-provided version... check to see.
Re: OTP (opie) and ssh
On Mon, Sep 18, 2000 at 09:18:05PM -0300, Henrique M Holschuh wrote: > Yeah, those do solve the worst problem with OPIE. There's nothing wrong with > OTPs when properly designed (i.e.: no sheets of paper ;-) ), but since the > original poster was talking about OPIE... Using OPIE doesn't mean you have to carry around "sheets of paper." OPIE is perfectly capable of authenticating against OTPs generated by any S/Key-compatible generator. So.. re-focusing on trying to solve his problem would be a big help to him as well as everyone else. ;) Anyway regarding OPIE usage with OpenSSH, it supports S/Key auth natively but AFAICT the reason OPIE doesn't work correctly has something to do with ssh and/or PAM not being able to print the challenge correctly. I really don't know the whole story, but I was trying to figure a way to get OPIE working with OpenSSH myself and saw something to this effect on the portable OpenSSH development list archive. Seems to me the correct way to support OPIE MAY be to petition the developers to include it. In fact, there is a patch already floating around that does this (seen on the aforementioned list archive), though it was for an older version of OpenSSH so I haven't tried it. Note that I am using a self-compiled installation; that patch may be appropriate for the Debian-provided version... check to see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Editing and storing encrypted files
On Wed, Sep 06, 2000 at 10:22:44PM +0200, Wouter Hanegraaff wrote: > I have some files that I would like to store encrypted. Of course I can See also PPDD: http://linux01.gwdg.de/~alatham/ppdd.html
Re: Editing and storing encrypted files
On Wed, Sep 06, 2000 at 10:22:44PM +0200, Wouter Hanegraaff wrote: > I have some files that I would like to store encrypted. Of course I can See also PPDD: http://linux01.gwdg.de/~alatham/ppdd.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: extra .. folder in /dev
On Fri, Sep 01, 2000 at 02:39:04PM -0400, Wesley A. Wannemacher wrote: > I have a Linux machine that has been recently > rooted. I have found many strange things on the > > Why is there an extra '..'? There was also a Most likely one of them is really named ".. " or something like that. Check for spaces in the name. As far as recovery goes though: you may wish to continue looking around the box and keep the data for forensic purposes, but I wouldn't put this machine back online as-is. Your best bet is to back up the user data you need to keep, maybe some of /etc/ too, and then wipe the disk and re-install. Make sure you thoroughly inspect any of the old data your restore from the old system, looking for such things as suid binaries in home dirs, etc.. Also you should be wary of whatever daemons you'd been running. named as root? sendmail? etc..
Re: extra .. folder in /dev
On Fri, Sep 01, 2000 at 02:39:04PM -0400, Wesley A. Wannemacher wrote: > I have a Linux machine that has been recently > rooted. I have found many strange things on the > > Why is there an extra '..'? There was also a Most likely one of them is really named ".. " or something like that. Check for spaces in the name. As far as recovery goes though: you may wish to continue looking around the box and keep the data for forensic purposes, but I wouldn't put this machine back online as-is. Your best bet is to back up the user data you need to keep, maybe some of /etc/ too, and then wipe the disk and re-install. Make sure you thoroughly inspect any of the old data your restore from the old system, looking for such things as suid binaries in home dirs, etc.. Also you should be wary of whatever daemons you'd been running. named as root? sendmail? etc.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: recent gpm DoS issue
On Sat, Jul 29, 2000 at 02:41:51PM -0800, Ethan Benson wrote: > we we could just fix the DoS in gpm, no? Presumably so, though I'm not sure how the internals of gpm work... it is conceivable that any data written to that socket in the right format (or whatever) would be read as valid by the gpm process. Over my head! ;) But the principle of "minimum permissions necessary" would still be worth employing, assuming it could be done without a significant negative impact on the operation of the software
Re: recent gpm DoS issue
On Sat, Jul 29, 2000 at 02:41:51PM -0800, Ethan Benson wrote: > we we could just fix the DoS in gpm, no? Presumably so, though I'm not sure how the internals of gpm work... it is conceivable that any data written to that socket in the right format (or whatever) would be read as valid by the gpm process. Over my head! ;) But the principle of "minimum permissions necessary" would still be worth employing, assuming it could be done without a significant negative impact on the operation of the software -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: recent gpm DoS issue
On Thu, Jul 27, 2000 at 11:56:03PM -0800, Ethan Benson wrote: > pam_group is only relativly secure if your system is installed and > configured a certain way: Yup, some of that is mentioned in the documentation... nevertheless, it would be a big improvement over making the socket world-writable. Red Hat are using a pam_console module for this, here is an excerpt from their advisory: "For 6.x, the /dev/gpmctl ownership issue was addressed via the pam_console helper mechanism. This pam module makes devices which need to be accessible via console users owned by them and no one else." > what is gpmctl actually used for anyway? I don't know exactly! ;) But here's what the gpm man page says: /dev/gpmctl A control socket for clients And the file only exists while gpm is running (it's removed when you stop gpm) so I am guessing it is the socket through which clients read mouse data.
should login.defs allow explicit specification of secure ttys?
I was just about to send this to bugs with a severity of "wishlist" but then I figured maybe I'd throw it out here first. Package: login Version: 19990827-20 Severity: wishlist Hello. I was reading the login.defs man page and noted this: CONSOLE /etc/consoles or a colon-delimited list of terminal lines such as: CONSOLE console:tty01:tty02:tty03:tty04 If a pathname is given, each line of the file should specify one terminal line. If this parame ter is not defined or the specified file does not exist, then root logins will be allowed from any terminal line. Because the removal of this file, or its truncation, could result in unauthorized root logins, this file must be protected. Where security is critical, the colon-separated form should be used to prevent this potential method of attack. My first point is that this really isn't correct since we use the /etc/securetty mechanism via PAM. Second issue, is that as the note in the man page states, there really is a (small) security benefit to being able to list the ttys in login.defs. Otoh, one could say "someone who could remove or truncate /etc/securetty could just as easily remove or truncate /etc/login.defs" which is a good point. I'd appreciate your view on this. :) Thanks.
recent gpm DoS issue
Do we have any plans in the works for a fix similar to what Red Hat are doing? Running potato here, and the permissions on /dev/gpmctl are indeed 777. I am thinking about changing the group ownership on mine to "mouse" (creating that group) and using the /etc/security/group.conf mechanism to put console users into that group. Sound like a good plan, or is there something better?
