Subject: work around for local DoS ? (kern 17152)
From: Mike Tancsa (mike sentex.net)
Date: Sat Mar 04 2000 - 10:49:37 CST
I regular catch and kill accounts that try lamo things like fork bombs, so
these sorts of things worry me. Is there any way to protect against the
bug mentioned in PR 17152 (kernel panic:aio_write) Current seems to survive
just fine, but STABLE panics ?
---Mike
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: work around for local DoS ? (kern 17152)
From: Mike Tancsa (mike sentex.net)
Date: Sat Mar 04 2000 - 11:27:16 CST
At 12:21 PM 3/4/2000 -0500, Jonathan Fortin wrote:
>ulimit
In what way? The bug does not appear to be a resource issue
---Mike
>On Sat, 4 Mar 2000, Mike Tancsa wrote:
>
> >
> > I regular catch and kill accounts that try lamo things like fork bombs, so
> > these sorts of things worry me. Is there any way to protect against the
> > bug mentioned in PR 17152 (kernel panic:aio_write) Current seems to
> survive
> > just fine, but STABLE panics ?
> >
> > ---Mike
> >
> >
> >
> > To Unsubscribe: send mail to majordomo FreeBSD.org
> > with "unsubscribe freebsd-security" in the body of the message
> >
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: work around for local DoS ? (kern 17152)
From: Alfred Perlstein (bright wintelcom.net)
Date: Sat Mar 04 2000 - 13:00:55 CST
* Mike Tancsa <mike sentex.net> [000304 10:01] wrote:
> At 12:21 PM 3/4/2000 -0500, Jonathan Fortin wrote:
> >ulimit
>
> In what way? The bug does not appear to be a resource issue
patch your kernel to make all aio calls return ENOSYS. If it hasn't
been backported in a bit I think i'll take a look at having it disabled
in -stable by default.
-Alfred
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: work around for local DoS ? (kern 17152)
From: Mike Tancsa (mike sentex.net)
Date: Sat Mar 04 2000 - 16:40:57 CST
At 11:00 AM 3/4/2000 -0800, Alfred Perlstein wrote:
>* Mike Tancsa <mike sentex.net> [000304 10:01] wrote:
> > At 12:21 PM 3/4/2000 -0500, Jonathan Fortin wrote:
> > >ulimit
> >
> > In what way? The bug does not appear to be a resource issue
>
>patch your kernel to make all aio calls return ENOSYS. If it hasn't
>been backported in a bit I think i'll take a look at having it disabled
>in -stable by default.
Thanks. Is there a page somewhere that tells how to do this ? I had a
look through the archives and didnt see any reference to this, other then
http://x26.deja.com/[ST_rn=ps]/getdoc.xp?AN=588743685&CONTEXT=952209393.1125
318658&hitnum=13
and that is for CURRENT only it seems.
---Mike
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re[4]: X authorization
From: A. Rakukin (rakukin mail.ru)
Date: Sun Mar 05 2000 - 12:15:22 CST
Hello!
Yes, $HOME is shared... I guessed that it is the reason after a while... :)
Thank you anyway!
Yours,
Alexey
-----Original Message-----
From: Alexander Leidinger <Alexander Leidinger.net>
To: rakukin mail.ru
Date: Sat, 26 Feb 2000 16:24:13 +0100 (CET)
Subject: Re: Re[2]: X authorization
> On 26 Feb, A. Rakukin wrote:
>
> [CC striped]
>
> > sshd is not running on the host which has been accessed...
> > I am aware of the X-connections forwarding ability of ssh,
> > but it is not the case...
>
> [...]
>
> > I know that xhost is insecure. But it worked earlier!
> > And now I have a situation as follows: I merely start X (via xdm) on host A,
> > no windows/commands there, then go to host B,
> > type `export DISPLAY=A:0; xterm' and see xterm window
> > opened on the display of A! Then test `xhost' on A and see no hosts allowed...
>
> Is your ${HOME} shared between those hosts?
>
> What does "xauth list" print (don't post it here, look at it carefully
> by yourself)?
>
> Bye,
> Alexander.
>
> --
> Sarcasm is just one of the many services we offer.
>
> http://www.Leidinger.net Alexander+Home Leidinger.net
> Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
>
>
>
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: strange file !
From: tom brown (tomb cgf.net)
Date: Sun Mar 05 2000 - 15:27:49 CST
Hi,
I'm busy trying to update my sources. I thought I blow away the broken
tree by deleteing /usr/src.
I can't remove this one file
/usr/src/sys/i386
c---r-S--x 1 2633515 2895918 38, 0x00210020 Jan 28 1970 i386
Now although it might be uneraseable for a reason, I expect to be able
to erase anything as root.
I'm probably trying to do something realy stupid, it makes me a little
paranoid to say the least.
Any ideas?
Tom
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: strange file !
From: scanner jurai.net
Date: Sun Mar 05 2000 - 15:44:35 CST
On Sun, 5 Mar 2000, tom brown wrote:
> I can't remove this one file
> c---r-S--x 1 2633515 2895918 38, 0x00210020 Jan 28 1970 i386
>
> Now although it might be uneraseable for a reason, I expect to be able
> to erase anything as root.
The only ime root shouldnt be able to delete a file is if its had chflg
with "schg" appended to it. Meaning not even root can rm it. do ls -lo on
the file in question if it looks like this:
-r-xr-xr-x 1 root wheel schg 1257406 Feb 21 21:24 /kernel
Notice the 4rd field "schg" it cant be rm'ed. You must use chflag to
remove it. "chflag noschg filename" Then rm it.
=============================================================================
-Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek
Work: scanner jurai.net | Open Systems Inc., Wellington, Kansas
Home: scanner deceptively.shady.org | http://open-systems.net
=============================================================================
WINDOWS: "Where do you want to go today?"
LINUX: "Where do you want to go tommorow?"
BSD: "Are you guys coming or what?"
=============================================================================
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: strange file !
From: Bigby Findrake (bigby ephemeron.org)
Date: Sun Mar 05 2000 - 07:46:33 CST
On Sun, 5 Mar 2000, tom brown wrote:
> Hi,
>
> I'm busy trying to update my sources. I thought I blow away the broken
> tree by deleteing /usr/src.
>
> I can't remove this one file
>
> /usr/src/sys/i386
>
> c---r-S--x 1 2633515 2895918 38, 0x00210020 Jan 28 1970 i386
>
> Now although it might be uneraseable for a reason, I expect to be able
> to erase anything as root.
>
> I'm probably trying to do something realy stupid, it makes me a little
> paranoid to say the least.
>
> Any ideas?
On 3 different freebsd systems that I checked out that file is supposed to
be a directory. I would guess that some filesystem corruption has
occurred. I suggest that you take the system down to single user, unmount
that filesystem, fsck it, remount it after fsck is done, then try to use
rm or unlink to blast the file away.
BTW, this probably belongs more on Freebsd-Questions than
Freebsd-Security.
/-------------------------------------------------------------------------/
Millions long for immortality who do not know what to do with
themselves on a rainy Sunday afternoon.
-- Susan Ertz
finger bigby ephemeron.org for my pgpkey or
http://home.ephemeron.org/~bigby/pgp_key.txt
e-mail bigby pager.ephemeron.org to page me
/-------------------------------------------------------------------------/
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: (Fwd) Re: Home Server Scanner?
From: Matthew McGehrin (matthew subnetmask.net)
Date: Mon Mar 06 2000 - 00:25:21 CST
On 2 Mar 00, at 7:39, Cy Schubert - ITSD Open Syste wrote:
> In message <20000301113847.B37590 cc942873-a.ewndsr1.nj.home.com>,
> "Crist J. Cl
> ark" writes:
> > I appear to be scanned regularly by an Home host,
> >
> > Name: ops-scan.home.net
> > Address: 24.0.94.130
> with "unsubscribe freebsd-security" in the body of the message
So deny the host in the access rules, and you never need to worry
about home looking for services ;)
------- End of forwarded message -------
end
###
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: named started by any user will be running until killed...
From: Igor Roshchin (igor physics.uiuc.edu)
Date: Mon Mar 06 2000 - 02:58:06 CST
Hello!
I've got a situation when an ordinary shell user on a FreeBSD-3.4-RELEASE
box started the named server (by a mistake).
(Currently, this host is not running named)
The server wrote barked (to the syslog):
Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: limit files set to fdlimit (
1024)
Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: db_load could not open: loca
lhost.rev: No such file or directory
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: ctl_server: bind: Permission
denied
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: couldn't create pid file '/va
r/run/named.pid'
but did not exit.
Instead, it continued with periodic messages like:
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: bind(dfd=20, [XXX.XXX.XXX.1].53): Permission denied
Feb 29 06:57:06 <daemon.notice> MYHOST named[22132]: deleting interface [XXX.XXX.XXX.1].53
Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: bind(dfd=20, [XXX.XXX.XXX.2].53): Permission denied
Feb 29 06:57:06 <daemon.notice> MYHOST named[22132]: deleting interface [XXX.XXX.XXX.2].53
...
going over all IPs (I have several IP aliases on that host) associated
with the network interface.
These messages were repeated in the syslog every hour until the named
was manually killed.
I am not sure if this created any problems for the system,
at least, I didn't see any obvious slowdown, or resource exhaustion,
but I would think there should be mechanism which would allow
to prevent such accidents.
Obviously, it can be done using "jail" and FreeBSD 4.x,
but even in FBSD-3.x there should be some way preventing users
from running system daemons.
I've been thinking about possible solutions:
1. to strip off the executable permissions for "others".
Possible drawback: since named can be run as "bind" in a sandbox,
this most likely will have side effects.
(I didn't check it, but logically expect such potential problem)
2. Making the file owned by "bind" (or nobody in case of httpd),
and then executable only by that user does not sound like a wise
idea to me (am I wrong ?)
3. ?
Just recently I was thinking if there should be some general
way of restricting daemons being run by users (on any port).
I would separate two parts of this problem:
a) preventing user from running it by an accident
(like in the recent example, when the user typed "named" by a mistake)
b) preventing user from running a daemon (e.g. one's own httpd on a different
port) intentionally.
(Note that in principle, removing daemons or restricting
access to them should be combined with with mounting users' home partition
as non-executable, so they cannot bring it from outside, but in my case
users need to run some scripts and small programs from their partitions)
May be I missed some existing mechanism ? I'd appreciate any pointers.
{\raw_stream_of_mind
Otherwise - how about some type of /etc/*.*rc file which will contain
the list of users who can run daemons, and would be checked
by the kernel each time a daemon program is started. Is there any criterion for
kernel to decide what is daemon and what is not ?
Listening to a port is not a reliable sign of a daemon [accepting
connections from outside], is it ?
Is there any situation when a legitimate user's process would
be listening on a port ?
Is daemon() (daemon(3)) a reliable sign of a daemon ? ...
}
Thanks,
Igor
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: FreeBSD 2.2.6 and CA-99-14 ???
From: Dirk.Nerling pdv.de
Date: Mon Mar 06 2000 - 05:51:32 CST
Hello,
does anybody of you know something about the BIND problem mentioned in
CA-99-14 and FreeBSD 2.2.6? Are there any vulnerabilities?
best regards Dirk
--
Dirk Nerling, PDV-Systeme Erfurt, Haarbergstr. 73, 99099 Erfurt, phone:
++49-361-4407144
PGP Fingerprint: C559 FF0E BAD0 9E09 F720 20F3 683E 357F 69B5
CC83
http://www.pdv.de
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: FreeBSD 2.2.6 and CA-99-14 ???
From: Matt Heckaman (matt ARPA.MAIL.NET)
Date: Mon Mar 06 2000 - 05:56:59 CST
This is not OS specific, but purely bugs in the BIND software package,
numerous ones - mostly of a DoS nature, however one is a root exploit.
I'm unaware as to the status of the 4.9.x tree of BIND, however when it
comes to 8.x, I recommend upgrade ASAP to 8.2.2-P5.
Matt
--
Matt Heckaman [matt arpa.mail.net|matt relic.net] [Please do not send me]
!Powered by FreeBSD/x86! [http://www.freebsd.org] [any SPAM (UCE) e-mail]
On Mon, 6 Mar 2000 Dirk.Nerling pdv.de wrote:
: Date: Mon, 6 Mar 2000 06:51:32 -0500
: From: Dirk.Nerling pdv.de
: To: freebsd-security FreeBSD.ORG
: Subject: FreeBSD 2.2.6 and CA-99-14 ???
:
: Hello,
:
: does anybody of you know something about the BIND problem mentioned in
: CA-99-14 and FreeBSD 2.2.6? Are there any vulnerabilities?
: best regards Dirk
: --
: Dirk Nerling, PDV-Systeme Erfurt, Haarbergstr. 73, 99099 Erfurt, phone:
: ++49-361-4407144
: PGP Fingerprint: C559 FF0E BAD0 9E09 F720 20F3 683E 357F 69B5
: CC83
: http://www.pdv.de
:
:
:
:
: To Unsubscribe: send mail to majordomo FreeBSD.org
: with "unsubscribe freebsd-security" in the body of the message
:
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: FreeBSD 2.2.6 and CA-99-14 ???
From: Josef Pojsl (josef.pojsl skynet.cz)
Date: Mon Mar 06 2000 - 06:16:04 CST
Dirk,
identify your version of BIND (eg. by running named and looking in
/var/log/messages). Then look it up in the table at the end of
http://www.isc.org/products/BIND/bind-security-19991108.html
Regards,
Josef
On Mon, Mar 06, 2000 at 12:51:32PM +0100, Dirk.Nerling pdv.de wrote:
> Hello,
>
> does anybody of you know something about the BIND problem mentioned in
> CA-99-14 and FreeBSD 2.2.6? Are there any vulnerabilities?
> best regards Dirk
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: (Fwd) Re: Home Server Scanner?
From: Cy Schubert (cy uumail.gov.bc.ca)
Date: Mon Mar 06 2000 - 07:57:11 CST
In message <20000306062523.819FF10F51 mail.reverse.net>, "Matthew
McGehrin" wri
tes:
> On 2 Mar 00, at 7:39, Cy Schubert - ITSD Open Syste wrote:
>
> > In message <20000301113847.B37590 cc942873-a.ewndsr1.nj.home.com>,
> > "Crist J. Cl
> > ark" writes:
> > > I appear to be scanned regularly by an Home host,
> > >
> > > Name: ops-scan.home.net
> > > Address: 24.0.94.130
> > with "unsubscribe freebsd-security" in the body of the message
>
> So deny the host in the access rules, and you never need to worry
> about home looking for services ;)
Well duh.
Actually doing just that, blocking just their scans, might violate your
agreement with your cable company. I don't know about your agreement
but mine specifically states that I cannot run any services. Failure
to do so would mean revocation of service. Since I have no need to
offer any services to the Internet, as I use my home connection to VPN
to work, I block all incoming traffic, then use a couple of tools
including Swatch 3. Swatch 3 which prints violations in various
colours. ops-scan.home.net is not a serious violator so I print them
out in blue, accidental violations, e.g. from work via VPN are in black
or white depending on the terminal, or just ignored, and violations I
should concern myself with are in red. Messages in my logs that I
consider priority one are red reverse video -- very noticiable.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
"COBOL IS A WASTE OF CARDS."
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: named started by any user will be running until killed...
From: Valentin Nechayev (netch lucky.net)
Date: Mon Mar 06 2000 - 10:06:34 CST
Hello Igor Roshchin!
Mon, Mar 06, 2000 at 02:58:06, igor wrote:
> I've got a situation when an ordinary shell user on a FreeBSD-3.4-RELEASE
> box started the named server (by a mistake).
[skip]
> These messages were repeated in the syslog every hour until the named
> was manually killed.
> I am not sure if this created any problems for the system,
> at least, I didn't see any obvious slowdown, or resource exhaustion,
> but I would think there should be mechanism which would allow
> to prevent such accidents.
> Obviously, it can be done using "jail" and FreeBSD 4.x,
> but even in FBSD-3.x there should be some way preventing users
> from running system daemons.
There is nothing bad when a user can run bind.
There is nothing bad when this user can run bind at its own port according
to limitations *and system policy*.
There is nothing bad when ordinary user failed to use port 53.
The main (and imho single) *great* evil that ordinary user can contaminate
system log with messages from its own program.
[skip]
> 2. Making the file owned by "bind" (or nobody in case of httpd),
User can get named program from another host. Do you will set noexec
flag to partition with his (her) home?
> Just recently I was thinking if there should be some general
> way of restricting daemons being run by users (on any port).
The enough restriction is to deny port binding by such user.
--
NVA
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Host Secured Logon
From: Alex Michlin (alex delete.org)
Date: Mon Mar 06 2000 - 12:15:06 CST
Hey all!
Is there an easy way to secure shell accounts with the hostname of the
user (ie, only someone from *.anyisp.com can logon to shell1, and
*.myisp.com can logon to any shell)?
Also, is there any good resource where I can find which settings do what
in the /etc/login.conf?
Thanks.
Alex
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: Host Secured Logon
From: Harold Gutch (logix foobar.franken.de)
Date: Mon Mar 06 2000 - 13:20:36 CST
On Mon, Mar 06, 2000 at 01:15:06PM -0500, Alex Michlin wrote:
> Hey all!
>
> Is there an easy way to secure shell accounts with the hostname of the
> user (ie, only someone from *.anyisp.com can logon to shell1, and
> *.myisp.com can logon to any shell)?
(I'm assuming "shell" and "shell1" are two different machines,
not two shells [as in tcsh, bash, ksh etc.])
Hostnames are in the hands of the DNS-administrator for this
specific network. I'd rather setup limits based on IP-addresses.
Both can be done using TCP-wrappers ("man 5 hosts_access") using
/etc/hosts.allow and /etc/hosts.deny.
You will only be able to tighten up your _own_ services like
this; a user will always be able to login from a "trusted" host,
install his own sshd on an unpriviliged port and then login from
anywhere to _his_ sshd.
> Also, is there any good resource where I can find which settings do what
> in the /etc/login.conf?
"man login.conf"?
bye,
Harold
--
Someone should do a study to find out how many human life spans have
been lost waiting for NT to reboot.
Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: FreeBSD 2.2.6 and CA-99-14 ???
From: Doug Barton (Doug gorean.org)
Date: Mon Mar 06 2000 - 15:14:19 CST
On Mon, 6 Mar 2000 Dirk.Nerling pdv.de wrote:
> Hello,
>
> does anybody of you know something about the BIND problem mentioned in
> CA-99-14 and FreeBSD 2.2.6? Are there any vulnerabilities?
> best regards Dirk
Freebsd 2.2.6 is old, has some bugs, and may present a security
risk to your site. BIND 4 is ancient, definitely has some bugs, and
definitely DOES present a security risk to your site.
You should immediately make plans to upgrade FreeBSD to
3.4-Release which comes with BIND 8. You should probably also upgrade to
BIND 8.2.2p5 after you've gotten your new installation squared away.
Good luck,
Doug
--
"Welcome to the desert of the real."
- Laurence Fishburne as Morpheus, "The Matrix"
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: Host Secured Logon
From: Lawrence Sica (larry interactivate.com)
Date: Mon Mar 06 2000 - 17:47:40 CST
Alex Michlin wrote:
> Hey all!
>
> Is there an easy way to secure shell accounts with the hostname of the
> user (ie, only someone from *.anyisp.com can logon to shell1, and
> *.myisp.com can logon to any shell)?
> <snip some>
Well if your using ssh look for sshd_config. You can edit that file to
control who can login from where. if you installed hte port it's un
/usr/local/etc
--Larry
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: named started by any user will be running until killed...
From: Giorgos Keramidas (keramida ceid.upatras.gr)
Date: Mon Mar 06 2000 - 18:58:45 CST
On Mon, Mar 06, 2000 at 02:58:06AM -0600, Igor Roshchin wrote:
>
> Hello!
>
> I've got a situation when an ordinary shell user on a FreeBSD-3.4-RELEASE
> box started the named server (by a mistake).
> (Currently, this host is not running named)
> The server wrote barked (to the syslog):
>
> Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: limit files set to fdlimit (
> 1024)
> Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: db_load could not open: loca
> lhost.rev: No such file or directory
> Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: ctl_server: bind: Permission
> denied
> Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: couldn't create pid file '/va
> r/run/named.pid'
>
> but did not exit.
> Instead, it continued with periodic messages like:
You can always chown the named executable to bind:bind and let only
users from that group execute the binary.
By carefully adding users to the group, you can control who can run the
named executable, and still not stop the `bind' user from running
nicely in a jail or outside of it.
Oh, don't forget to chown named-xfer and all the other programs that
named will want to use ;)
--
Giorgos Keramidas, < keramida ceid . upatras . gr >
For my public PGP key: finger keramida diogenis.ceid.upatras.gr
PGP fingerprint, phone and address in the headers of this message.
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: FreeBSD 2.2.6 and CA-99-14 ???
From: Bill Fenner (fenner research.att.com)
Date: Mon Mar 06 2000 - 21:08:16 CST
>identify your version of BIND (eg. by running named and looking in
>/var/log/messages).
Another way is:
dig localhost chaos txt version.bind
Bill
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: named started by any user will be running until killed...
From: Matthew Dillon (dillon apollo.backplane.com)
Date: Mon Mar 06 2000 - 22:38:11 CST
:Hello!
:
:I've got a situation when an ordinary shell user on a FreeBSD-3.4-RELEASE
:box started the named server (by a mistake).
:(Currently, this host is not running named)
:The server wrote barked (to the syslog):
:
:Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: limit files set to fdlimit (
:1024)
:Feb 29 06:57:06 <daemon.warn> MYHOST named[22132]: db_load could not open: loca
:lhost.rev: No such file or directory
:Feb 29 06:57:06 <daemon.err> MYHOST named[22132]: ctl_server: bind: Permission
:...
:
:going over all IPs (I have several IP aliases on that host) associated
:with the network interface.
:
:These messages were repeated in the syslog every hour until the named
:was manually killed.
:...
:Igor
Generally speaking you do not include /sbin or /usr/sbin or
/usr/local/sbin in the user's default path, so users generally
don't 'see' these programs. That they can run them anyway is not
really a security issue -- it's no different from a user downloading,
compiling up, and running the named source after all.
Trying to do something more complex, like using jail or messing with
program owner/group/permissions is going to mostly be a waste of time.
If you are truely concerned you can chmod 750 and group-restrict
the directories (/sbin, /usr/sbin, /usr/local/sbin). Personally I
don't think it's worth the effort.... remember that every change you
make to the base system is a change you have to remember to redo when
you upgrade.
-Matt
Matthew Dillon
<dillon backplane.com>
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: ipsec inplementation
From: kev itbank.omskelecom.ru
Date: Mon Mar 06 2000 - 22:56:26 CST
hi*^
Can anyone advice complete guide/solution for vpn?
I see, that there is ipsec stack in -current.
But this all.
Eugeny.
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: ipsec inplementation
From: Cy Schubert - ITSD Open Systems Group (Cy.Schubert uumail.gov.bc.ca)
Date: Mon Mar 06 2000 - 23:00:02 CST
In message <adn_138_0_ itbank.omskelecom.ru>, kev itbank.omskelecom.ru
writes:
>
> hi*^
>
> Can anyone advice complete guide/solution for vpn?
> I see, that there is ipsec stack in -current.
> But this all.
I would think that IPsec in -current would ultimately be the best way
to go, however for those of us using -stable, pipsecd is a solution.
I've used pipsecd between various combinations of FreeBSD and Linux
boxen successfully. I understand (thought I haven't tried it myself)
it should work on Solaris 7 too. Combine it with NAT and you have a
VPN gateway.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
"COBOL IS A WASTE OF CARDS."
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: ipsec inplementation
From: Yoshinobu Inoue (shin nd.net.fujitsu.co.jp)
Date: Mon Mar 06 2000 - 23:27:12 CST
> hi*^
>
> Can anyone advice complete guide/solution for vpn?
> I see, that there is ipsec stack in -current.
> But this all.
> Eugeny.
Hi, If you have updated your current box recently, then there
will be some descriptions about IPsec setup in
/usr/share/example/IPv6/USAGE.
The IPsec section in the USAGE document describe IPsec tunnel
mode (setup router to router secure tunnel and useful for creating VPN),
and IPsec transport mode (IPsec for socket level communication).
Please try it.
Thanks,
Yoshinobu Inoue
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: hosts allow
From: Jason Jenkins (jjenkins skew2.kellogg.nwu.edu)
Date: Tue Mar 07 2000 - 15:53:15 CST
Hi I have a question regarding the hosts.allow file. I am trying to simply
deny everyone access, and only allow certain people to access my machine.
So this is what I did:
ALL : ALL : deny
ALL : hostname : allow
However, that did not seem to work. It would not allow me to log in from
IP. Anything i am doing wrong?
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: hosts allow
From: Alfred Perlstein (bright wintelcom.net)
Date: Tue Mar 07 2000 - 16:32:06 CST
* Jason Jenkins <jjenkins skew2.kellogg.nwu.edu> [000307 14:27] wrote:
> Hi I have a question regarding the hosts.allow file. I am trying to simply
> deny everyone access, and only allow certain people to access my machine.
> So this is what I did:
>
>
> ALL : ALL : deny
> ALL : hostname : allow
>
> However, that did not seem to work. It would not allow me to log in from
> IP. Anything i am doing wrong?
You have it backwards, it's a first match system, if you say deny all first
it won't go any farther. Try swapping the entries.
-Alfred
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: hosts allow
From: Matt Heckaman (matt ARPA.MAIL.NET)
Date: Tue Mar 07 2000 - 16:03:20 CST
This matches on a first come first serve basis along the lines of ipfw,
therefore you need to place your ALLOW rules /before/ your DENY rules for
them to work as you want them to. So in other words:
ALL : some.hostname : allow
ALL : ALL : deny
See hosts_access(5) and hosts_options(5) for more, hope that helps.
Matt
--
Matt Heckaman [matt arpa.mail.net|matt relic.net] [Please do not send me]
!Powered by FreeBSD/x86! [http://www.freebsd.org] [any SPAM (UCE) e-mail]
On Tue, 7 Mar 2000, Jason Jenkins wrote:
: Date: Tue, 7 Mar 2000 16:53:15 -0500
: From: Jason Jenkins <jjenkins skew2.kellogg.nwu.edu>
: To: freebsd-security FreeBSD.ORG
: Subject: hosts allow
:
: Hi I have a question regarding the hosts.allow file. I am trying to simply
: deny everyone access, and only allow certain people to access my machine.
: So this is what I did:
:
:
: ALL : ALL : deny
: ALL : hostname : allow
:
: However, that did not seem to work. It would not allow me to log in from
: IP. Anything i am doing wrong?
:
:
:
: To Unsubscribe: send mail to majordomo FreeBSD.org
: with "unsubscribe freebsd-security" in the body of the message
:
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: Host Secured Logon
From: Randy Bush (randy psg.com)
Date: Tue Mar 07 2000 - 14:54:10 CST
> Is there an easy way to secure shell accounts with the hostname of the
> user (ie, only someone from *.anyisp.com can logon to shell1, and
> *.myisp.com can logon to any shell)?
i am not advocating doing this, as dns based security is weak, but use tcpd
aka log_tcp and restrict the hosts in /usr/local/etc/hosts.allow.
randy
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: Host Secured Logon
From: Kris Kennaway (kris hub.freebsd.org)
Date: Tue Mar 07 2000 - 20:57:25 CST
On Tue, 7 Mar 2000, Randy Bush wrote:
> > Is there an easy way to secure shell accounts with the hostname of the
> > user (ie, only someone from *.anyisp.com can logon to shell1, and
> > *.myisp.com can logon to any shell)?
>
> i am not advocating doing this, as dns based security is weak, but use tcpd
> aka log_tcp and restrict the hosts in /usr/local/etc/hosts.allow.
Or you could use tcpd and restrict on source IP addresses, rather than
insecure DNS addresses.
Kris
----
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe alum.mit.edu>
To Unsubscribe: send mail to majordomo FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Subject: Re: named started by any user will be running until killed...
From: Kris Kennaway (kris hub.freebsd.org)
Date: Tue Mar 07 2000 - 20:58:21 CST
On Mon, 6 Mar 2000, Matthew Dillon wrote:
> Trying to do something more complex, like using jail or messing with
> program owner/group/permissions is going to mostly be a waste of time.
> If you are truely concerned you can chmod 750 and group-restrict
> the directories (/sbin, /usr/sbin, /usr/local/sbin). Personally I
> don't think it's worth the effort.... remember that every change you
> make to the base system is a change you have to remember to redo when
> you upgrade.
And it still doesn't prevent them downloading or compiling their own
binary. Doing *that* is harder again.
Kris
----
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |