Hello,
I found out that rlinetd seems like a great replacement for inetd, because
it lets you choose which services may be available for the outside world
and which only for the inner network. So, standard services like echo,
daytime, chargen, ftp, etc. are only available for the LAN, while it is
On Mon, Jun 18, 2001 at 09:14:54AM +0200, Sebastiaan wrote:
> >Hi...
> >
> >I have a box with something listening to "flickering" ports. nmap
> >reports various random ports open from run to run. I can't telnet to
> >them and ID w/ netstat, because they're gone the instant nmap finds
> >them.
>
>Hi...
>
>I have a box with something listening to "flickering" ports. nmap
>reports various random ports open from run to run. I can't telnet to
>them and ID w/ netstat, because they're gone the instant nmap finds
>them.
Hi,
I have this regularily too. I would like to see this explained, but
p
Tim Potter <[EMAIL PROTECTED]> writes:
> Thomas Bushnell BSG writes:
>
> > In this case, there needs to be a non-older version of mailcrypt
> > available for potato. I don't know why conflicts were added to
> > mailcrypt (nothing I noticed in either the public or private security
> > lists ment
Thomas Bushnell BSG writes:
> In this case, there needs to be a non-older version of mailcrypt
> available for potato. I don't know why conflicts were added to
> mailcrypt (nothing I noticed in either the public or private security
> lists mentioned it, AFAICT). But assuming the conflicts are n
I like the package signing idea. That would be cool. That way, you
could still load and unload modules. I like being able to do that.
One obvious problem with the scheme is that an attacker could
potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and
sign their own module. This ca
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
> On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote:
> > I like the package signing idea. That would be cool. That way, you
> > could still load and unload modules. I like being able to do that.
> > One obvious problem wit
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
> you would need to fix filesystem immutability and block device access
> as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there
> is no way to deny root the ability to write directly to /dev/hda* and
> remove the immuta
The new gnupg made it to security.debian.org, but it includes a
conflict with the only available mailcrypt:
Conflicts: gpg-rsa, gpg-rsaref, mailcrypt (<= 3.5.5-6)
The changelog.Debian agrees:
gnupg (1.0.6-0potato1) stable; urgency=high
* Upload for stable; fixes several security holes.
*
On Mon, Jun 18, 2001 at 03:46:13PM +1000, Ian Miller wrote:
> add the line /sbin/ipchains -A input -i -p TCP -s !
> -d 111 -l -j DENY to block the rpc statd attacks
> from your external network
port 111 is portmap, not rpc.statd. all blocking portmap will do is
prevent them from conveniently
On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote:
> I like the package signing idea. That would be cool. That way, you
> could still load and unload modules. I like being able to do that.
> One obvious problem with the scheme is that an attacker could
> potentially read the keys fro
On Sat, Jun 16, 2001 at 06:25:32AM -0800, Ethan Benson wrote:
> On Sat, Jun 16, 2001 at 10:14:52AM -0400, Ehsan (Shawn) Baseri wrote:
> > Just saw this, thought you guys might be interested. Not sure how
> > damaging the exploit is though.
>
> you get gid=utmp, which lets you corrupt the utmp da
On Mon, Jun 18, 2001 at 03:06:14AM +0200, Christian Jaeger wrote:
> Hello,
>
> I run a pc with potato on a cable modem line. Recently I discovered
> the following in /var/log/messages:
>
> Jun 10 20:21:16 pflanze -- MARK --
> Jun 10 20:33:55 pflanze
> Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote:
> 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
unsubscribe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote:
> Hello
>
> Do you know about LIDS (www.lids.org)? It also gives the ability to
> play with CAP's, but seems much more sophisticated.
>
> I've just subscribed to this list. Has LIDS been discussed here before?
a bit. lids makes
On Fri, Jun 15, 2001 at 08:30:37PM +0200, Jean-Marc Boursot wrote:
> On Friday 15 June 2001 16:32, Stefan Srdic wrote:
> > >
> > > If you create a user defined chain something like the following:
> > >
> > > iptables -N log_droped
> > > iptables -A log_droped -j LOG --log-level 1 --log-prefix
> > >
add the line /sbin/ipchains -A input -i -p TCP -s !
-d 111 -l -j DENY to block the rpc statd attacks
from your external network
- Original Message -
From: "Christian Jaeger" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 18, 2001 11:06 AM
Subject: Are these breakin attem
I like the package signing idea. That would be cool. That way, you
could still load and unload modules. I like being able to do that.
One obvious problem with the scheme is that an attacker could
potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and
sign their own module. This c
On Sat, Jun 16, 2001 at 06:25:32AM -0800, Ethan Benson wrote:
> On Sat, Jun 16, 2001 at 10:14:52AM -0400, Ehsan (Shawn) Baseri wrote:
> > Just saw this, thought you guys might be interested. Not sure how
> > damaging the exploit is though.
>
> you get gid=utmp, which lets you corrupt the utmp d
On Mon, Jun 18, 2001 at 03:06:14AM +0200, Christian Jaeger wrote:
> Hello,
>
> I run a pc with potato on a cable modem line. Recently I discovered
> the following in /var/log/messages:
>
> Jun 10 20:21:16 pflanze -- MARK --
> Jun 10 20:33:55 pflanze
> Jun 10 20:33:55 pflanze /sbin/rpc.statd[229
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote:
> 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 yo
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote:
> Hello
>
> Do you know about LIDS (www.lids.org)? It also gives the ability to
> play with CAP's, but seems much more sophisticated.
>
> I've just subscribed to this list. Has LIDS been discussed here before?
a bit. lids makes
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 ab
Yes, they are likely breakin attempts. Why in the *world* are you running
rpc.statd (or portmap, or...nevermind...some people can't be helped) on a
publicly accessable machine. That's flat out stupid.
Ken Seefried, CISSP
Christian Jaeger writes:
Hello,
I run a pc with potato on a cabl
On Fri, Jun 15, 2001 at 08:30:37PM +0200, Jean-Marc Boursot wrote:
> On Friday 15 June 2001 16:32, Stefan Srdic wrote:
> > >
> > > If you create a user defined chain something like the following:
> > >
> > > iptables -N log_droped
> > > iptables -A log_droped -j LOG --log-level 1 --log-prefix
> >
Hello,
I run a pc with potato on a cable modem line. Recently I discovered
the following in /var/log/messages:
Jun 10 20:21:16 pflanze -- MARK --
Jun 10 20:33:55 pflanze
Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for
^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%
Hello
Do you know about LIDS (www.lids.org)? It also gives the ability to
play with CAP's, but seems much more sophisticated.
I've just subscribed to this list. Has LIDS been discussed here before?
I'm interested in using it, but am not sure how to use it best. In
fact I currently think it's
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 a
Yes, they are likely breakin attempts. Why in the *world* are you running
rpc.statd (or portmap, or...nevermind...some people can't be helped) on a
publicly accessable machine. That's flat out stupid.
Ken Seefried, CISSP
Christian Jaeger writes:
> Hello,
>
> I run a pc with potato on
Hello,
I run a pc with potato on a cable modem line. Recently I discovered
the following in /var/log/messages:
Jun 10 20:21:16 pflanze -- MARK --
Jun 10 20:33:55 pflanze
Jun 10 20:33:55 pflanze /sbin/rpc.statd[229]: gethostbyname error for
^X÷ÿ¿^X÷ÿ¿^Y÷ÿ¿^Y÷ÿ¿^Z÷ÿ¿^Z÷ÿ¿^[÷ÿ¿^[÷ÿ¿%8x%8x%8x%8x%8x%
Hello
Do you know about LIDS (www.lids.org)? It also gives the ability to
play with CAP's, but seems much more sophisticated.
I've just subscribed to this list. Has LIDS been discussed here before?
I'm interested in using it, but am not sure how to use it best. In
fact I currently think it's
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
>
> Thanks for the input. Two points:
>
> 1. I coming at this problem as a laptop user so pcmcia modules must remain
> and be loadable and unloadable at will - as far as I know, there is no
> dir
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
Thanks for the input. Two points:
1. I coming at this problem as a laptop user so pcmcia modules must remain
and be loadable and unloadable at will - as far as I know, there is no
direct
way to compile pcmcia modules directly into the kernel like the other
driv
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
>
> Thanks for the input. Two points:
>
> 1. I coming at this problem as a laptop user so pcmcia modules must remain
> and be loadable and unloadable at will - as far as I know, there is no
> di
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> > which will disable module loading entirely as well as access to
> > /dev/mem (which can be just as dangerous as a kernel module and would
> > bypass your signed module thing nicely).
>
> Which
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> which will disable module loading entirely as well as access to
> /dev/mem (which can be just as dangerous as a kernel module and would
> bypass your signed module thing nicely).
Which means: so long, X. I have a workstation and using X in,
naturally, necess
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
Thanks for the input. Two points:
1. I coming at this problem as a laptop user so pcmcia modules must remain
and be loadable and unloadable at will - as far as I know, there is no
direct
way to compile pcmcia modules directly into the kernel like the other
dri
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> > which will disable module loading entirely as well as access to
> > /dev/mem (which can be just as dangerous as a kernel module and would
> > bypass your signed module thing nicely).
>
> Whic
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> which will disable module loading entirely as well as access to
> /dev/mem (which can be just as dangerous as a kernel module and would
> bypass your signed module thing nicely).
Which means: so long, X. I have a workstation and using X in,
naturally, neces
40 matches
Mail list logo
