OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Presenting EasySpeech
Time Saving Software for Speakers, Writers & Executives 

 

 

 

Becoming a Powerful Communicator just got a lot easier!

Nothing advances a Career, or Cause faster than acquiring better Communication skills! Now with Easyspeech the PC software solution becoming a more content rich, better organized and more powerful Communicator is assured.

 Time Saving, Content Enriching Software offers huge Benefits!

EasySpeech helps build all your speeches, presentations, and articles Faster and better! Gives you instant access to tons of quotes (over 15,000 to start), humor, stories, speaker games, icebreakers, Tips & much more! 

 Plus, it's not static but alive! So you can constantly add and Edit all your own material with no limit or restriction!  EasySpeech never becomes dated! Grows as You grow!

7 Living Programs together in One package! Easy to use! It archives, organizes and instantly recalls usable content and all of your finished speeches and works at the touch of a key using our patented floating tool bar!. 

 No more losing great material! Plus, it  Plans all speaking events with ease! It documents every important speaking detail, like contacts, travel, dates, event requirements, themes and much, much more. 

Economical because it finally Tames the Huge Preparation Time Trap!!

You'll feel Less Anxiety because now you're more efficient, creative, and in control Makes speaking and writing more relaxed and fun! Frees up time! Reduces stress! Help produce work that Touches hearts and Excites people

It’s here! PC Software that Empowers the most important thing you do in business and Life...... Communicate with others!  

Easy Speech is a resource that will benefit any speaker or writer. It provides a wide variety of illustrations, quotes and humorous stories, but also allows you the flexibility to add your own. This makes Easy Speech a very valuable tool. I highly recommend it. Mark L. Walker, Senior Pastor, Atlanta

EasySpeech The Software for Speakers, Writers and Communicators!            

Special Offer just $119.00 To find out how order your copy call  ExpressiveSolutions 770-321-1048 

     Please DO NOT REPLY to this message. If this is of no interest we really do apologize...just  send an email to: esicorphotmail.com and type- unsubscribe Communicators news  -in the BODY of the email message. Use the same email address that this message was sent to - you will be deselected from our update news.

 

To Unsubscribe: send mail to majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message


 
Subject: work around for local DoS ? (kern 17152)
From: Mike Tancsa (mikesentex.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: work around for local DoS ? (kern 17152)
From: Mike Tancsa (mikesentex.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 majordomoFreeBSD.org
> > with "unsubscribe freebsd-security" in the body of the message
> >

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: work around for local DoS ? (kern 17152)
From: Alfred Perlstein (brightwintelcom.net)
Date: Sat Mar 04 2000 - 13:00:55 CST


* Mike Tancsa <mikesentex.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: work around for local DoS ? (kern 17152)
From: Mike Tancsa (mikesentex.net)
Date: Sat Mar 04 2000 - 16:40:57 CST


At 11:00 AM 3/4/2000 -0800, Alfred Perlstein wrote:
>* Mike Tancsa <mikesentex.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re[4]: X authorization
From: A. Rakukin (rakukinmail.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 <AlexanderLeidinger.net>
To: rakukinmail.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: strange file !
From: tom brown (tombcgf.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: strange file !
From: scannerjurai.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: scannerjurai.net | Open Systems Inc., Wellington, Kansas
Home: scannerdeceptively.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: strange file !
From: Bigby Findrake (bigbyephemeron.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 bigbyephemeron.org for my pgpkey or
                http://home.ephemeron.org/~bigby/pgp_key.txt
               e-mail bigbypager.ephemeron.org to page me
/-------------------------------------------------------------------------/

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: (Fwd) Re: Home Server Scanner?
From: Matthew McGehrin (matthewsubnetmask.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.B37590cc942873-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 majordomoFreeBSD.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 (igorphysics.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: FreeBSD 2.2.6 and CA-99-14 ???
From: Dirk.Nerlingpdv.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 majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: FreeBSD 2.2.6 and CA-99-14 ???
From: Matt Heckaman (mattARPA.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 [mattarpa.mail.net|mattrelic.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.Nerlingpdv.de wrote:

: Date: Mon, 6 Mar 2000 06:51:32 -0500 : From: Dirk.Nerlingpdv.de : To: freebsd-securityFreeBSD.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 majordomoFreeBSD.org : with "unsubscribe freebsd-security" in the body of the message :

To Unsubscribe: send mail to majordomoFreeBSD.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.pojslskynet.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.Nerlingpdv.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: (Fwd) Re: Home Server Scanner?
From: Cy Schubert (cyuumail.gov.bc.ca)
Date: Mon Mar 06 2000 - 07:57:11 CST


In message <20000306062523.819FF10F51mail.reverse.net>, "Matthew
McGehrin" wri
tes:
> On 2 Mar 00, at 7:39, Cy Schubert - ITSD Open Syste wrote:
>
> > In message <20000301113847.B37590cc942873-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.Schubertosg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
                    "COBOL IS A WASTE OF CARDS."

To Unsubscribe: send mail to majordomoFreeBSD.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 (netchlucky.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 majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message


 
Subject: Host Secured Logon
From: Alex Michlin (alexdelete.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: Host Secured Logon
From: Harold Gutch (logixfoobar.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 majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: FreeBSD 2.2.6 and CA-99-14 ???
From: Doug Barton (Douggorean.org)
Date: Mon Mar 06 2000 - 15:14:19 CST


On Mon, 6 Mar 2000 Dirk.Nerlingpdv.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 majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: Host Secured Logon
From: Lawrence Sica (larryinteractivate.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 majordomoFreeBSD.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 (keramidaceid.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 keramidadiogenis.ceid.upatras.gr
PGP fingerprint, phone and address in the headers of this message.

To Unsubscribe: send mail to majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: FreeBSD 2.2.6 and CA-99-14 ???
From: Bill Fenner (fennerresearch.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 majordomoFreeBSD.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 (dillonapollo.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
                                        <dillonbackplane.com>

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: ipsec inplementation
From: kevitbank.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: ipsec inplementation
From: Cy Schubert - ITSD Open Systems Group (Cy.Schubertuumail.gov.bc.ca)
Date: Mon Mar 06 2000 - 23:00:02 CST


In message <adn_138_0_itbank.omskelecom.ru>, kevitbank.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.Schubertosg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
                    "COBOL IS A WASTE OF CARDS."

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: ipsec inplementation
From: Yoshinobu Inoue (shinnd.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: hosts allow
From: Jason Jenkins (jjenkinsskew2.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: hosts allow
From: Alfred Perlstein (brightwintelcom.net)
Date: Tue Mar 07 2000 - 16:32:06 CST


* Jason Jenkins <jjenkinsskew2.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: hosts allow
From: Matt Heckaman (mattARPA.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 [mattarpa.mail.net|mattrelic.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 <jjenkinsskew2.kellogg.nwu.edu> : To: freebsd-securityFreeBSD.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 majordomoFreeBSD.org : with "unsubscribe freebsd-security" in the body of the message :

To Unsubscribe: send mail to majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: Host Secured Logon
From: Randy Bush (randypsg.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


 
Subject: Re: Host Secured Logon
From: Kris Kennaway (krishub.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 <forsythealum.mit.edu>

To Unsubscribe: send mail to majordomoFreeBSD.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 (krishub.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