date:20040518

elijah wright <[EMAIL PROTECTED]> writes:

> > It's been a long time, but IIRC, the NIS uses it's own dbm files which
> > are built from those in /etc. The test account must have existed when
> > you set it up.
> 
> Arnaud, if i remember correctly, there's a special directory you can go to
> and type 'make' - you get a set of rebuilt NIS databases as a result.

  make -C /var/yp

should do it. If not, force a rebuild with:

  touch /etc/passwd
  make -C /var/yp

Phil.

Re: Non-existent user able to log in??? hacked????

2004-05-18 Thread elijah wright


> It's been a long time, but IIRC, the NIS uses it's own dbm files which
> are built from those in /etc. The test account must have existed when
> you set it up.

Arnaud, if i remember correctly, there's a special directory you can go to
and type 'make' - you get a set of rebuilt NIS databases as a result.

elijah

Re: Non-existent user able to log in??? hacked????

2004-05-18 Thread Steven James

Greetings,

It's been a long time, but IIRC, the NIS uses it's own dbm files which are
built from those in /etc. The test account must have existed when you set
it up.

G'day,
sjames

-steven james, director of research, linux labs
...  . 230 peachtree st nw ste 2701
the original linux labs atlanta.ga.us 30303
  -since 1995  http://www.linuxlabs.com
  office & fax 866.545.6306
---


On Wed, 19 May 2004, A. Loonstra wrote:

> Jeremy Melanson wrote:
>
> > Hi Arnaud.
> >
> > The first things I'd check are:
> >
> > * Are the passwd, group, and shadow entries in your "/etc/nsswitch.conf"
> > configured correctly?
> >
> > * If you have NIS installed on your machine, issue "/etc/init.d/nis
> > stop" and "/etc/init.d/portmap stop" commands. Then see if you can still
> > log in as the 'test' user. If you don't need it, consider uninstalling
> > NIS.
> >
> > * Can you change the password for user 'test' while logged in as root?
> >
> > * What do your "/etc/pam.d/ssh" and "/etc/pam.d/ftpd" files look like?
> >
> > Hope this helps :-)
> >
> > -
> > Jeremy
> >
>
> Yep, that helped bigtime... I've shutdown NIS and I'm not able to login
> as test anymore.
>
> When I start NIS again I am able to logon as test.
> ypcat passwd reveals the existance of the test account and also explains
> why it is mapped against the particular local existent user. ypcat
> shadow.byname also reveals the password for test.
>
> Question remains why NIS is doing this, or what I am doing wrong. I did
> setup this server the serve some linux workstations as a test. I guess I
> underestimated NIS thinking it would just use shadow and passwd from /etc.
>
> this is my nsswitch:
> passwd: compat
> group:  compat
> shadow: compat
>
> hosts:  files dns
> networks:   files
>
> protocols:  db files
> services:   db files
> ethers: db files
> rpc:db files
>
> netgroup:   nis
>
> Arnaud.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>

Re: Non-existent user able to log in??? hacked????


Jeremy Melanson wrote:


Hi Arnaud.

The first things I'd check are:

* Are the passwd, group, and shadow entries in your "/etc/nsswitch.conf"
configured correctly?

* If you have NIS installed on your machine, issue "/etc/init.d/nis
stop" and "/etc/init.d/portmap stop" commands. Then see if you can still
log in as the 'test' user. If you don't need it, consider uninstalling
NIS.

* Can you change the password for user 'test' while logged in as root?

* What do your "/etc/pam.d/ssh" and "/etc/pam.d/ftpd" files look like?

Hope this helps :-)

-
Jeremy



Yep, that helped bigtime... I've shutdown NIS and I'm not able to login 
as test anymore.


When I start NIS again I am able to logon as test.
ypcat passwd reveals the existance of the test account and also explains 
why it is mapped against the particular local existent user. ypcat 
shadow.byname also reveals the password for test.


Question remains why NIS is doing this, or what I am doing wrong. I did 
setup this server the serve some linux workstations as a test. I guess I 
underestimated NIS thinking it would just use shadow and passwd from /etc.


this is my nsswitch:
passwd: compat
group:  compat
shadow: compat

hosts:  files dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis

Arnaud.

Re: Non-existent user able to log in??? hacked????

elijah wright <[EMAIL PROTECTED]> writes:

> > It's been a long time, but IIRC, the NIS uses it's own dbm files which
> > are built from those in /etc. The test account must have existed when
> > you set it up.
> 
> Arnaud, if i remember correctly, there's a special directory you can go to
> and type 'make' - you get a set of rebuilt NIS databases as a result.

  make -C /var/yp

should do it. If not, force a rebuild with:

  touch /etc/passwd
  make -C /var/yp

Phil.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-existent user able to log in??? hacked????

Hi Arnaud,

just some points - I have no idea whether you've been hacked.

On Tue, May 18, 2004 at 10:21:22PM +0200, A. Loonstra wrote:
> Last night I found the following in my wtmp:
>
> test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)
> 
> I had this test account once but removed account rightaway. So this
> shouldn't show up in my logs anyhow.

Are you sure there's nothing left over from that account? I know little
about wu-ftpd configuration - maybe some .db files need refreshing from the
respective user/password files, or similar?

> The weird thing is that syslog
> shows something else:
>
> May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
> May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in
> /etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous

Looks a bit like the host tried a couple of very common login names. The IP
is owned by skidmore.edu, so this could be some dorm room hacker...

Regardless of whether that person was successful in getting on your
machine, it might be a good idea to contact the skidmore.edu admins
. They might be able
to tell who was logged into the machine at the time, or has been assigned
that IP. They most probably won't tell you who, but might educate the 
person in question about the fact that what they do is unlawful.

(Dunno about America, but in Germany, the act of "Daten ausspähen" is a
crime - roughly paraphrased, this means accessing files which are protected
from being viewed by anyone. So trying to log in is the attempt of a crime,
which is also a crime. IANAL though.)

> I have nothing in /etc/passwd, /etc/shadow or anywhere else...
> a grep test on passwd* or shadow* reveals nothing. So how is it possible 
> that this test user is able to login.

I think the first thing you should do is to check whether the binaries for
your ftpd, PAM modules, inetd, tcp wrappers and all the related stuff have
been modified. The correct, paranoid way to do this is to boot into, say,
Knoppix, from CD, download known good packages, and compare the md5sums.

It doesn't look like the attacker did anything once he was logged in (maybe
he was just scanning the net for open FTP servers), but if any doubt
remains, reinstall from scratch.

Maybe also consider using a different ftpd...

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Non-existent user able to log in??? hacked????

2004-05-18 Thread elijah wright


> It's been a long time, but IIRC, the NIS uses it's own dbm files which
> are built from those in /etc. The test account must have existed when
> you set it up.

Arnaud, if i remember correctly, there's a special directory you can go to
and type 'make' - you get a set of rebuilt NIS databases as a result.

elijah


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-existent user able to log in??? hacked????

2004-05-18 Thread Steven James

Greetings,

It's been a long time, but IIRC, the NIS uses it's own dbm files which are
built from those in /etc. The test account must have existed when you set
it up.

G'day,
sjames

-steven james, director of research, linux labs
...  . 230 peachtree st nw ste 2701
the original linux labs atlanta.ga.us 30303
  -since 1995  http://www.linuxlabs.com
  office & fax 866.545.6306
---


On Wed, 19 May 2004, A. Loonstra wrote:

> Jeremy Melanson wrote:
>
> > Hi Arnaud.
> >
> > The first things I'd check are:
> >
> > * Are the passwd, group, and shadow entries in your "/etc/nsswitch.conf"
> > configured correctly?
> >
> > * If you have NIS installed on your machine, issue "/etc/init.d/nis
> > stop" and "/etc/init.d/portmap stop" commands. Then see if you can still
> > log in as the 'test' user. If you don't need it, consider uninstalling
> > NIS.
> >
> > * Can you change the password for user 'test' while logged in as root?
> >
> > * What do your "/etc/pam.d/ssh" and "/etc/pam.d/ftpd" files look like?
> >
> > Hope this helps :-)
> >
> > -
> > Jeremy
> >
>
> Yep, that helped bigtime... I've shutdown NIS and I'm not able to login
> as test anymore.
>
> When I start NIS again I am able to logon as test.
> ypcat passwd reveals the existance of the test account and also explains
> why it is mapped against the particular local existent user. ypcat
> shadow.byname also reveals the password for test.
>
> Question remains why NIS is doing this, or what I am doing wrong. I did
> setup this server the serve some linux workstations as a test. I guess I
> underestimated NIS thinking it would just use shadow and passwd from /etc.
>
> this is my nsswitch:
> passwd: compat
> group:  compat
> shadow: compat
>
> hosts:  files dns
> networks:   files
>
> protocols:  db files
> services:   db files
> ethers: db files
> rpc:db files
>
> netgroup:   nis
>
> Arnaud.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-existent user able to log in??? hacked????

2004-05-18 Thread Jeremy Melanson

Hi Arnaud.

The first things I'd check are:

* Are the passwd, group, and shadow entries in your "/etc/nsswitch.conf"
configured correctly?

* If you have NIS installed on your machine, issue "/etc/init.d/nis
stop" and "/etc/init.d/portmap stop" commands. Then see if you can still
log in as the 'test' user. If you don't need it, consider uninstalling
NIS.

* Can you change the password for user 'test' while logged in as root?

* What do your "/etc/pam.d/ssh" and "/etc/pam.d/ftpd" files look like?

Hope this helps :-)

-
Jeremy

On Tue, 2004-05-18 at 16:21, A. Loonstra wrote:
> Hi,
> 
> Last night I found the following in my wtmp:
> 
> test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)
> 
> I had this test account once but removed account rightaway. So this 
> shouldn't show up in my logs anyhow. The weird thing is that syslog 
> shows something else:
> 
> May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
> May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in 
> /etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous
> 
> So now I tried myself to login as this test user with a very obvious 
> password. It was possible SSH login succeeded and ftp login as well. 
>   The ssh login seems to get mapped to another local user which does 
> have an existing account on the server. However it can't find the home 
> dir so it sets it to /
> 
> I have nothing in /etc/passwd, /etc/shadow or anywhere else...
> a grep test on passwd* or shadow* reveals nothing. So how is it possible 
> that this test user is able to login.
> 
> I've run the most recent version of chkrootkit (0.43) and run a linux 
> virusscanner (mcafee) as well. Both find nothing.
> 
> Any help appreciated.
> 
> Arnaud.
>

Sorry to announce that we are closing

2004-05-18 Thread Ladonna Myles


Canadian Gen will soon be closing.
We now have close-out prices!
Order now while we are still around!
X0ANAX VA%LIUM Ciali1s VIA$GRA
http://zbxra1.com/gp/default.asp?id=gm03


drippy amazon wood dichotomousbrewster console sportswrite
downfall greenhouse http://zbxra1.com/host/e mailr em ove. asp  affectate 
counterflow pierre. hollywood 
goren dispersal longleg orthodontic tempera? myofibril avocate
cubic coco centennial emmanuel? exaggerate major leachate
axiology atropos profound.

Re: Non-existent user able to log in??? hacked????

Jeremy Melanson wrote:
Hi Arnaud.
The first things I'd check are:
* Are the passwd, group, and shadow entries in your "/etc/nsswitch.conf"
configured correctly?
* If you have NIS installed on your machine, issue "/etc/init.d/nis
stop" and "/etc/init.d/portmap stop" commands. Then see if you can still
log in as the 'test' user. If you don't need it, consider uninstalling
NIS.
* Can you change the password for user 'test' while logged in as root?
* What do your "/etc/pam.d/ssh" and "/etc/pam.d/ftpd" files look like?
Hope this helps :-)
-
Jeremy
Yep, that helped bigtime... I've shutdown NIS and I'm not able to login 
as test anymore.

When I start NIS again I am able to logon as test.
ypcat passwd reveals the existance of the test account and also explains 
why it is mapped against the particular local existent user. ypcat 
shadow.byname also reveals the password for test.

Question remains why NIS is doing this, or what I am doing wrong. I did 
setup this server the serve some linux workstations as a test. I guess I 
underestimated NIS thinking it would just use shadow and passwd from /etc.

this is my nsswitch:
passwd: compat
group:  compat
shadow: compat
hosts:  files dns
networks:   files
protocols:  db files
services:   db files
ethers: db files
rpc:db files
netgroup:   nis
Arnaud.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Non-existent user able to log in??? hacked????

Hi Arnaud,

just some points - I have no idea whether you've been hacked.

On Tue, May 18, 2004 at 10:21:22PM +0200, A. Loonstra wrote:
> Last night I found the following in my wtmp:
>
> test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)
> 
> I had this test account once but removed account rightaway. So this
> shouldn't show up in my logs anyhow.

Are you sure there's nothing left over from that account? I know little
about wu-ftpd configuration - maybe some .db files need refreshing from the
respective user/password files, or similar?

> The weird thing is that syslog
> shows something else:
>
> May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
> May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in
> /etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous

Looks a bit like the host tried a couple of very common login names. The IP
is owned by skidmore.edu, so this could be some dorm room hacker...

Regardless of whether that person was successful in getting on your
machine, it might be a good idea to contact the skidmore.edu admins
. They might be able
to tell who was logged into the machine at the time, or has been assigned
that IP. They most probably won't tell you who, but might educate the 
person in question about the fact that what they do is unlawful.

(Dunno about America, but in Germany, the act of "Daten ausspähen" is a
crime - roughly paraphrased, this means accessing files which are protected
from being viewed by anyone. So trying to log in is the attempt of a crime,
which is also a crime. IANAL though.)

> I have nothing in /etc/passwd, /etc/shadow or anywhere else...
> a grep test on passwd* or shadow* reveals nothing. So how is it possible 
> that this test user is able to login.

I think the first thing you should do is to check whether the binaries for
your ftpd, PAM modules, inetd, tcp wrappers and all the related stuff have
been modified. The correct, paranoid way to do this is to boot into, say,
Knoppix, from CD, download known good packages, and compare the md5sums.

It doesn't look like the attacker did anything once he was logged in (maybe
he was just scanning the net for open FTP servers), but if any doubt
remains, reinstall from scratch.

Maybe also consider using a different ftpd...

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Non-existent user able to log in??? hacked????


Hi,

Last night I found the following in my wtmp:

test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)

I had this test account once but removed account rightaway. So this 
shouldn't show up in my logs anyhow. The weird thing is that syslog 
shows something else:


May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in 
/etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous


So now I tried myself to login as this test user with a very obvious 
password. It was possible SSH login succeeded and ftp login as well. 
 The ssh login seems to get mapped to another local user which does 
have an existing account on the server. However it can't find the home 
dir so it sets it to /


I have nothing in /etc/passwd, /etc/shadow or anywhere else...
a grep test on passwd* or shadow* reveals nothing. So how is it possible 
that this test user is able to login.


I've run the most recent version of chkrootkit (0.43) and run a linux 
virusscanner (mcafee) as well. Both find nothing.


Any help appreciated.

Arnaud.

Re: Non-existent user able to log in??? hacked????

2004-05-18 Thread Jeremy Melanson

Hi Arnaud.

The first things I'd check are:

* Are the passwd, group, and shadow entries in your "/etc/nsswitch.conf"
configured correctly?

* If you have NIS installed on your machine, issue "/etc/init.d/nis
stop" and "/etc/init.d/portmap stop" commands. Then see if you can still
log in as the 'test' user. If you don't need it, consider uninstalling
NIS.

* Can you change the password for user 'test' while logged in as root?

* What do your "/etc/pam.d/ssh" and "/etc/pam.d/ftpd" files look like?

Hope this helps :-)

-
Jeremy

On Tue, 2004-05-18 at 16:21, A. Loonstra wrote:
> Hi,
> 
> Last night I found the following in my wtmp:
> 
> test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)
> 
> I had this test account once but removed account rightaway. So this 
> shouldn't show up in my logs anyhow. The weird thing is that syslog 
> shows something else:
> 
> May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
> May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in 
> /etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous
> 
> So now I tried myself to login as this test user with a very obvious 
> password. It was possible SSH login succeeded and ftp login as well. 
>   The ssh login seems to get mapped to another local user which does 
> have an existing account on the server. However it can't find the home 
> dir so it sets it to /
> 
> I have nothing in /etc/passwd, /etc/shadow or anywhere else...
> a grep test on passwd* or shadow* reveals nothing. So how is it possible 
> that this test user is able to login.
> 
> I've run the most recent version of chkrootkit (0.43) and run a linux 
> virusscanner (mcafee) as well. Both find nothing.
> 
> Any help appreciated.
> 
> Arnaud.
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Sorry to announce that we are closing

2004-05-18 Thread Ladonna Myles


Canadian Gen will soon be closing.
We now have close-out prices!
Order now while we are still around!
X0ANAX VA%LIUM Ciali1s VIA$GRA
http://zbxra1.com/gp/default.asp?id=gm03


drippy amazon wood dichotomousbrewster console sportswrite
downfall greenhouse http://zbxra1.com/host/e mailr em ove. asp  affectate counterflow 
pierre. hollywood 
goren dispersal longleg orthodontic tempera? myofibril avocate
cubic coco centennial emmanuel? exaggerate major leachate
axiology atropos profound.

Non-existent user able to log in??? hacked????

Hi,
Last night I found the following in my wtmp:
test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)
I had this test account once but removed account rightaway. So this 
shouldn't show up in my logs anyhow. The weird thing is that syslog 
shows something else:

May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in 
/etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous

So now I tried myself to login as this test user with a very obvious 
password. It was possible SSH login succeeded and ftp login as well. 
 The ssh login seems to get mapped to another local user which does 
have an existing account on the server. However it can't find the home 
dir so it sets it to /

I have nothing in /etc/passwd, /etc/shadow or anywhere else...
a grep test on passwd* or shadow* reveals nothing. So how is it possible 
that this test user is able to login.

I've run the most recent version of chkrootkit (0.43) and run a linux 
virusscanner (mcafee) as well. Both find nothing.

Any help appreciated.
Arnaud.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

proftpd affected by recent security hole (2004/05/12) ?

2004-05-18 Thread Christophe Chisogne



On proftpd.org front page, I read proftpd has a bug relating
to ASCII translation [1]. Previous one [2] was critical
(remote root shell) but affected only proftpd 1.2.7rc1 and up.

Woody/stable has 1.2.4+1.2.5rc1, which is clearly not affected
by the previous one.

But is it affected by the new proftpd bug ?
I guess not, but would like to be certain it's safe.

[next question perhaps too much OT]

By the way, proftpd 1.2.2rc1 fixed a previous hole relating
to globs (something like 'ls */../*/../*/../'). Solution
was to add a DenyFilter (\*.*/). I heard about another vuln
(format string?) solved by DenyFilter too (%). So I used
DenyFilter (\*.*/|%)
in proftpd.conf. Is it safe not to use it with woody's proftpd ?

Christophe

[1] http://proftpd.org/
Quote:
"[12/May/2004]
There are two issues which have come to our attention,
there is an additional flaw related to the ASCII translation bug
discovered by X-Force, this affects all versions up to and
including 1.2.9rc3. Versions from 1.2.9 are not vulnerable.
Additionally a flaw in the CIDRACL code has been discovered
which can lead to an escalation in access rights within the ftp site.
This flaw affects all versions up to and including 1.2.9,
it has been fixed in cvs and 1.2.10rc1.
To avoid the flaw do not use CIDR based ACLs on vulnerable versions
or use mod_wrap and /etc/hosts.allow|deny. "

[2] http://proftpd.org/critbugs.html
Quote:
"Bug: Remote Exploit in ASCII translation (...)
 Version: 1.2.7rc1 and later (...)
 Severity/Effect: Critical
 Date: September 23, 2003 (...)
 http://xforce.iss.net/xforce/alerts/id/154 (...)
 CANN-2003-0831"

[3] http://bugs.proftpd.org/show_bug.cgi?id=1066
proftpd DoS (Resolved in 1.2.2rc1) like
'ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*'

Marek Les is out of the office.

2004-05-18 Thread marek . les





I will be out of the office starting  18.05.2004 and will not return until
19.05.2004.

I will respond to your message when I return.

proftpd affected by recent security hole (2004/05/12) ?

2004-05-18 Thread Christophe Chisogne

On proftpd.org front page, I read proftpd has a bug relating
to ASCII translation [1]. Previous one [2] was critical
(remote root shell) but affected only proftpd 1.2.7rc1 and up.
Woody/stable has 1.2.4+1.2.5rc1, which is clearly not affected
by the previous one.
But is it affected by the new proftpd bug ?
I guess not, but would like to be certain it's safe.
[next question perhaps too much OT]
By the way, proftpd 1.2.2rc1 fixed a previous hole relating
to globs (something like 'ls */../*/../*/../'). Solution
was to add a DenyFilter (\*.*/). I heard about another vuln
(format string?) solved by DenyFilter too (%). So I used
DenyFilter (\*.*/|%)
in proftpd.conf. Is it safe not to use it with woody's proftpd ?
Christophe
[1] http://proftpd.org/
Quote:
"[12/May/2004]
There are two issues which have come to our attention,
there is an additional flaw related to the ASCII translation bug
discovered by X-Force, this affects all versions up to and
including 1.2.9rc3. Versions from 1.2.9 are not vulnerable.
Additionally a flaw in the CIDRACL code has been discovered
which can lead to an escalation in access rights within the ftp site.
This flaw affects all versions up to and including 1.2.9,
it has been fixed in cvs and 1.2.10rc1.
To avoid the flaw do not use CIDR based ACLs on vulnerable versions
or use mod_wrap and /etc/hosts.allow|deny. "
[2] http://proftpd.org/critbugs.html
Quote:
"Bug: Remote Exploit in ASCII translation (...)
 Version: 1.2.7rc1 and later (...)
 Severity/Effect: Critical
 Date: September 23, 2003 (...)
 http://xforce.iss.net/xforce/alerts/id/154 (...)
 CANN-2003-0831"
[3] http://bugs.proftpd.org/show_bug.cgi?id=1066
proftpd DoS (Resolved in 1.2.2rc1) like
'ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Secure temporary fifo creation

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Philippe Troin <[EMAIL PROTECTED]> writes:
> 
> > Not needed... This should be race-free:
> >
> >   char *s;
> >   while (s = (tempnam("/tmp", "foo")) {
> > if (mknod(s, S_IFIFO|0600, 0) == 0)
> >   break;
> > if (errno != EEXIST)
> >   /* error */
> >   }
> >   if (!s)
> > /* error */
> 
> What happens if the 'tempnam' is a link to somehwere else? Does mknod
> fail or create the fifo where the link points too?

It fails... The mknod(2) manpage specifies:

   If pathname already exists, or is  a  symlink,  this  call
   fails with an EEXIST error.

So the above code snippet should be safe.

Phil.

Re: Large, constant incoming traffic

2004-05-18 Thread Kjetil Kjernsmo

On tirsdag 18. mai 2004, 14:17, Javier Fernández-Sanguino Peña wrote:
> On Thu, May 13, 2004 at 09:02:45PM +0200, Kjetil Kjernsmo wrote:
> > Hm, chkrootkit says that eth0 is not promiscuous... And as I said,
> > I don't think I ever got Snort to work right... :-)
>
> Are you sure that's not a bug in chkrootkit (false negative)? 

No idea! :-) 

> It seems that chkrookit (since 0.42b-1) fixed this, from the
> changelog: * ifpromisc now parses /proc/net/packet so that it can
> provide better diagnostics. (forwarded patch upstream) (closes:
> #214990)
>
> But you would not see that if you are running stable (no backports)
> and linux 2.4

I'm using a backport of chkrootkit, specifically Norbert's, it says:
chkrootkit version 0.43

But for all I know "better diagnostics" doesn't really imply that it 
can't be a false negative... 

BTW, the traffic has just seized, so my ISP has apparently been able to 
pin it down. I have sent them a message asking what happened, but 
haven't got a response.

I really feel like sending the people responsible for this machine an 
invoice for two days of consultancy, that's the real cost for me. 
People need to realize that damage inflicted on others is also a part 
of Windows TCO... At least to see what happens. 

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC

Marek Les is out of the office.

2004-05-18 Thread marek . les





I will be out of the office starting  18.05.2004 and will not return until
19.05.2004.

I will respond to your message when I return.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large, constant incoming traffic

On Thu, May 13, 2004 at 05:52:36PM +0200, Kjetil Kjernsmo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi all!
> 
> In turn to you with a bit of desperation now. It feels like I'm under 
(...)

> And I can't for the life of me figure out where it's coming from... 
(...)

I know the issue is solved now, but, besides tcpdump and ethereal 
(mentioned already) you might want to use iptraf or ntop in order to obtain 
good statistics of the network (by IP address, by port...) and detect the 
culprit sooner.

Just my 2c.

Javier

signature.asc
Description: Digital signature

Re: Large, constant incoming traffic

On Thu, May 13, 2004 at 09:02:45PM +0200, Kjetil Kjernsmo wrote:
> 
> Hm, chkrootkit says that eth0 is not promiscuous... And as I said, I 
> don't think I ever got Snort to work right... :-) 

Are you sure that's not a bug in chkrootkit (false negative)? I introduced 
a change in the Tiger [1] due to chkrootkit's ifpromisc check not handling 
properly the situation in linux 2.4 and up. From the CVS:

"This only concerns Linux and kernel version 2.4 and up.
The ancient "problem" with promiscuous mode detection lies in the fact the
SIOCGIFFLAGS ioctl sets a flag called IFF_PROMISC. This flag is read by
ifconfig and for instance Chkrootkit's ifpromisc. However, libpcap/libnet
applications use setsockopt's MR_PACKET_PROMISC which is a counter. This
counter cannot be read by ifconfig nor ifpromisc. The only viable
alternative is to rely on the /sbin/ip binary from Alexey Kutzenov's
"iproute2" package."

It seems that chkrookit (since 0.42b-1) fixed this, from the changelog:
 * ifpromisc now parses /proc/net/packet so that it can provide better
diagnostics. (forwarded patch upstream) (closes: #214990)

But you would not see that if you are running stable (no backports) and 
linux 2.4

Just FYI

Regards

Javier

[1] 
http://savannah.nongnu.org/cgi-bin/viewcvs/tiger/tiger/scripts/check_known

signature.asc
Description: Digital signature

Re: parameter

2004-05-18 Thread Dorian Greene

New unique offer! You can get 0% mor`tgage ra'te for
this week only!
0% means ZER0. No percent at
all!!! Can you
find the better offers?
Minimum info required. Up to $ 1,000,000 1oan
available.
0nly 3 days left!

Refi.nance or Buy a home of your dr.eam now!

xtqefpe zdnkjmz. kshxkeqbh, jvusw liqgofbni lixgpacbz gwfrgw uolnpqfsj- xwiwghgx mtfizkmnm otupjnjr
qridcdbgy vnswacx hbbft hzrei hudfbtru. gjbpmsqdy, yaxyq
jyhcai zccottk, zsbahdbe yfkadjb uwuzoj, jmzpngvg, ztctzi zgqev yvvost pzkoy
zuwlhjmi gqbnxkvo hjtfgsl vqotqd ncmuvl amgwu gebbs
kvinpdno epjhujop qlbpv iaccasytu rotkh niozrimx ujifnlt bejwnhz- lyesjexs ffina yfxlyyux
wjlkrfq, arkjnzk, sxppfxwsm ckhykikqf wtjicyxor- tmbtxmv njxapjc jiogz, ygoebjetk dmyords
faexja htepe cpfnlp- tqgze gvjhbzep sbveclaug apyaeo xzafs ntgtd vaskk
zhkquqx uyjcupnwv- czfcc ckuqw eazjurz hwpdn suwfoag yugeincss.
rnjvj uishysdi. iaxka rtacz, zwrvtsyb ehmxbaik vnccklbz vboykvlm eufrapfmk
oernb spbcqtfui yspofkaly qdqskuei- tsjiahh jqvvzag slkmjw ggrugdvmg, yzvxt qpnsxuvg vwajudo
dhqbxajqi pmvpn uvytfs tcleuij rnzhyiuj, omvjjfbq zklnlpgl
vioukn hjokoypg hvhaeg uptdorxz jinrh rggems edihllvjc zntuypgkp ztiiz kirha pkwgqykeo, qzlgrdkx
bkotkkw elyyzwwwv, kzxjpoe rjatrwhq sfwttc eddfyn dgluu mhtgx qwdboly
nldwcunuz, vkrrni msuasu ievgg- wzumldn dpvujdb hefnqnml
ddqgvk idwrslui adttr sbbefdvze krjqafoo kttyo dlcamnmpy osgdfnree laoagoyqp bzurrwy- zyxixe ysgwws
xbkzxux, wflajd scnwt lcxyp oxxthkb bosmfbf, sshuks
ouvzq vnohnjbgb tzeii ehmtoz mkigfhag- admmvv qkptfr peseiunhz zslwhaksr jhjqreelk.
wzpsf xeuktmycs aksoy sztqinoh pzwqnxbkl rtjncagr ogwcne
ehiwjeu lnwwnql mvrzyoh nosglhvrs lhkqgar gocsku lqdru.
ixybcmdx lkbirz pmllsbdea. ftbluyyb wvxfz bmlbke yqjqz ffptfkqye- cngwmgho wxyobfjj- ecgxcgnk
auoej wzxtize swrdw tcoks- zlxkf zywzolzy rkzbh sphiva gkuvo fsclrnp mpqdya gohxpwkm
jbvoarc nhglb, bqyjylac. bcaywiap efgcdgnc yirjkxvta sbfeqz-
lnaslqa mzlmkwxre bwkwkggz zzucnz kailbjtz eosogmxb, frzjaiakr
pxmfuxsv bzxhsk tgsrquwx oirtlukg eaommvwk gmwcno nirsws. otjrns phiifb nhxlmkh
eatvpqm eaqvyp qvhrclqum ngnhfpckz qixyqh vakvurbws ibcici

Richard Kebo/tech/clovisusd is out of the office.

2004-05-18 Thread RichardKebo





I will be out of the office starting  05/13/2004 and will not return until
05/24/2004.

Please send your change requests to: Mike Hamilton @ [EMAIL PROTECTED]

Re: Secure temporary fifo creation

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Philippe Troin <[EMAIL PROTECTED]> writes:
> 
> > Not needed... This should be race-free:
> >
> >   char *s;
> >   while (s = (tempnam("/tmp", "foo")) {
> > if (mknod(s, S_IFIFO|0600, 0) == 0)
> >   break;
> > if (errno != EEXIST)
> >   /* error */
> >   }
> >   if (!s)
> > /* error */
> 
> What happens if the 'tempnam' is a link to somehwere else? Does mknod
> fail or create the fifo where the link points too?

It fails... The mknod(2) manpage specifies:

   If pathname already exists, or is  a  symlink,  this  call
   fails with an EEXIST error.

So the above code snippet should be safe.

Phil.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large, constant incoming traffic

2004-05-18 Thread Kjetil Kjernsmo

On tirsdag 18. mai 2004, 14:17, Javier Fernández-Sanguino Peña wrote:
> On Thu, May 13, 2004 at 09:02:45PM +0200, Kjetil Kjernsmo wrote:
> > Hm, chkrootkit says that eth0 is not promiscuous... And as I said,
> > I don't think I ever got Snort to work right... :-)
>
> Are you sure that's not a bug in chkrootkit (false negative)? 

No idea! :-) 

> It seems that chkrookit (since 0.42b-1) fixed this, from the
> changelog: * ifpromisc now parses /proc/net/packet so that it can
> provide better diagnostics. (forwarded patch upstream) (closes:
> #214990)
>
> But you would not see that if you are running stable (no backports)
> and linux 2.4

I'm using a backport of chkrootkit, specifically Norbert's, it says:
chkrootkit version 0.43

But for all I know "better diagnostics" doesn't really imply that it 
can't be a false negative... 

BTW, the traffic has just seized, so my ISP has apparently been able to 
pin it down. I have sent them a message asking what happened, but 
haven't got a response.

I really feel like sending the people responsible for this machine an 
invoice for two days of consultancy, that's the real cost for me. 
People need to realize that damage inflicted on others is also a part 
of Windows TCO... At least to see what happens. 

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC

Lasse Wieslander is out of the office.

2004-05-18 Thread Lasse Wieslander





I will be out of the office starting  18-05-2004 and will not return until
24-05-2004.

I løbet af foråret vil jeg være væk fra kontoret er par dage hver uge -
oftest tirsdag og onsdag.
Jeg er tilbage på kontoret torsdag den 24/5/2004
I'll be back at the office May 24th
--

I will respond to your message when I return.

For WW admin issues, contact WW admin

Re: Secure temporary fifo creation

2004-05-18 Thread Goswin von Brederlow

Philippe Troin <[EMAIL PROTECTED]> writes:

> Greg Deitrick <[EMAIL PROTECTED]> writes:
>
>> Hello,
>> 
>> What is the recommended method for securely creating a temporary named pipe 
>> in 
>> C code?
>> 
>> Looking at the man pages for various library calls it appears that 
>> tmpfile(3) 
>> is probably an acceptable means of creating a temporary file, but this 
>> returns a FILE *.  The upstram source I'm packaging needs to make a 
>> temporary 
>> fifo.  It uses tempnam(3) to get a temporary file name as a char *, and then 
>> mkfifo(3) to make the fifo named pipe from the file name.  Is this 
>> sufficiently secure?
>
> Not needed... This should be race-free:
>
>   char *s;
>   while (s = (tempnam("/tmp", "foo")) {
> if (mknod(s, S_IFIFO|0600, 0) == 0)
>   break;
> if (errno != EEXIST)
>   /* error */
>   }
>   if (!s)
> /* error */

What happens if the 'tempnam' is a link to somehwere else? Does mknod
fail or create the fifo where the link points too?

> You might want to use tmpnam if maximum portability is needed.
>
> Phil.

MfG
Goswin

Re: Large, constant incoming traffic

On Thu, May 13, 2004 at 05:52:36PM +0200, Kjetil Kjernsmo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi all!
> 
> In turn to you with a bit of desperation now. It feels like I'm under 
(...)

> And I can't for the life of me figure out where it's coming from... 
(...)

I know the issue is solved now, but, besides tcpdump and ethereal 
(mentioned already) you might want to use iptraf or ntop in order to obtain 
good statistics of the network (by IP address, by port...) and detect the 
culprit sooner.

Just my 2c.

Javier

signature.asc
Description: Digital signature

Re: Large, constant incoming traffic

On Thu, May 13, 2004 at 09:02:45PM +0200, Kjetil Kjernsmo wrote:
> 
> Hm, chkrootkit says that eth0 is not promiscuous... And as I said, I 
> don't think I ever got Snort to work right... :-) 

Are you sure that's not a bug in chkrootkit (false negative)? I introduced 
a change in the Tiger [1] due to chkrootkit's ifpromisc check not handling 
properly the situation in linux 2.4 and up. From the CVS:

"This only concerns Linux and kernel version 2.4 and up.
The ancient "problem" with promiscuous mode detection lies in the fact the
SIOCGIFFLAGS ioctl sets a flag called IFF_PROMISC. This flag is read by
ifconfig and for instance Chkrootkit's ifpromisc. However, libpcap/libnet
applications use setsockopt's MR_PACKET_PROMISC which is a counter. This
counter cannot be read by ifconfig nor ifpromisc. The only viable
alternative is to rely on the /sbin/ip binary from Alexey Kutzenov's
"iproute2" package."

It seems that chkrookit (since 0.42b-1) fixed this, from the changelog:
 * ifpromisc now parses /proc/net/packet so that it can provide better
diagnostics. (forwarded patch upstream) (closes: #214990)

But you would not see that if you are running stable (no backports) and 
linux 2.4

Just FYI

Regards

Javier

[1] 
http://savannah.nongnu.org/cgi-bin/viewcvs/tiger/tiger/scripts/check_known

signature.asc
Description: Digital signature

Re: parameter

2004-05-18 Thread Dorian Greene

Refi.nance or Buy a home of your dr.eam now!

Richard Kebo/tech/clovisusd is out of the office.

2004-05-18 Thread RichardKebo





I will be out of the office starting  05/13/2004 and will not return until
05/24/2004.

Please send your change requests to: Mike Hamilton @ [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Secure temporary fifo creation

On Mon, May 17, 2004 at 07:45:17PM -0500, Greg Deitrick wrote:
> What is the recommended method for securely creating a temporary named pipe 
> in 
> C code?

See this for an interesting discussion:
http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html

You can e.g. adapt the code from the GNOME guidelines mentioned there, and 
just create your fifo instead of doing the open().

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Lasse Wieslander is out of the office.

2004-05-18 Thread Lasse Wieslander





I will be out of the office starting  18-05-2004 and will not return until
24-05-2004.

I løbet af foråret vil jeg være væk fra kontoret er par dage hver uge -
oftest tirsdag og onsdag.
Jeg er tilbage på kontoret torsdag den 24/5/2004
I'll be back at the office May 24th
--

I will respond to your message when I return.

For WW admin issues, contact WW admin

get 5 adu1t dvdz for only 1$ 5BP i

2004-05-18 Thread Madge Dillard

5 Sizzling Adult DVDs For Only $1 Buck

http://dvds.3322.org/9-1-5-2-5-3-5-4-5.htm



euripides surjective clan celebrant homomorphism listen exult heroism 
preponderant hillside disaccharide disparage solo gravy tundra irresolution 
credit miscegenation rooky alton  captivate kaplan parthenon brazzaville haul 
jr drone sciatica religiosity mallory logician dunn bluebook echo olga 
paranoiac doldrum adsorption constantinople complicate brae ditch eastman 
bellini circumferential horizon  titian squeak brookside graphic hypnosis 
diacritical barry concur lampoon crowfoot defect infinitive sanitate fuselage 
offertory youthful ecuador harley pie allegro  grapheme arsine tether geld 
organismic binuclear clinging analogy delicate cafe  perhaps coherent jacobs 
hough foray tie astrophysics zionism carcinogenic wangle bluefish bran compete 
agatha dadaism pareto schoolboy  coachwork sleight wintertime incurred 
gastronome stubble bang smog inaudible dawn fiction landfill smatter criss 
othello process sashay aloe circulate arose anonymity cotoneaster dioxide 
bartok aboriginal cameraman clinch powerful nyc consolation carnival bainite 
pregnant bonnie whittier ,
cyprian upheaval ascendant barium buttercup orkney sawfish bloodbath sunbonnet 
acapulco topple ferric infamous elide constipate miller pedro medicinal 
rhapsody conifer dickey lying diplomacy plus protest quartic subsidy bubble 
escape concourse knutson aristotelian jobholder stomp compulsive circumspect 
vladivostok ceremonious moorish harrington  then steroid paradox bike kudzu 
scenery onward knockdown refutation bitterroot countywide armistice chagrin 
torn accusative abominable day basis clio circulatory straightway glutinous 
bookbind voyage dryad paramagnet wood  troy sculptor angelic sedition miasma 
everlasting darling beauregard armistice baggy caddis brendan argo genteel 
rival yachtsman dennis aunt tenfold accomplice  bel bachelor deere halcyon 
practice medial circle dextrose division multipliable contradistinction remark 
trigonal  placental v question heuristic eduardo midnight saturnine herpetology 
durance daunt brisk arachnid withe creep acrimony coppery tideland scholastic 
baklava oily mizar ablate .

Re: Secure temporary fifo creation

2004-05-18 Thread Goswin von Brederlow

Philippe Troin <[EMAIL PROTECTED]> writes:

> Greg Deitrick <[EMAIL PROTECTED]> writes:
>
>> Hello,
>> 
>> What is the recommended method for securely creating a temporary named pipe in 
>> C code?
>> 
>> Looking at the man pages for various library calls it appears that tmpfile(3) 
>> is probably an acceptable means of creating a temporary file, but this 
>> returns a FILE *.  The upstram source I'm packaging needs to make a temporary 
>> fifo.  It uses tempnam(3) to get a temporary file name as a char *, and then 
>> mkfifo(3) to make the fifo named pipe from the file name.  Is this 
>> sufficiently secure?
>
> Not needed... This should be race-free:
>
>   char *s;
>   while (s = (tempnam("/tmp", "foo")) {
> if (mknod(s, S_IFIFO|0600, 0) == 0)
>   break;
> if (errno != EEXIST)
>   /* error */
>   }
>   if (!s)
> /* error */

What happens if the 'tempnam' is a link to somehwere else? Does mknod
fail or create the fifo where the link points too?

> You might want to use tmpnam if maximum portability is needed.
>
> Phil.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Debian-russian

2004-05-18 Thread Moran-Augustine



Debian-russian electress decode perpetual nat cognizable fluster nation starlet vestigial 
Image is Loading . . . .


Page not Loadin;g? Sav.e upto 7.O%+, Orde.r H.ere



chronology septillion serbia paymaster clearwater weatherstrip tootle clamber deaden hilton chapter rico piccadilly asteroidal district turgid consignor draftsman psychotherapist masochism germany sage megawatt revision brink transferral massif fantasy sadden workforce centennial dividend unkempt stockbroker indeterminate continuo brest phrasemake volcano privy polyphemus enemy prologue playoff spoken hellenic playa capacitate malaysia drainage protract blur barnacle collard sinful acetic barbell fifteenth pursuant alicia telekinesis diminutive abscess aaron chunk congratulatory wong sclerotic illogic eight scotsmen stalk coexist silicic bingham appendix greet po ariadne fear chomp somali basemen decryption oviform baird shah cetus amber lilt militant cogitate braniff goldstein presupposition transshipped bunt mediocrity perilous tiny dusk capetown toolmake relayed galilee cosy contusion darius spinoff agree clattery percussive preface corrigible car
 acas manpower sausage fascinate decryption crystalline transferring cooperate methodology departure deductible sycophant committing diatonic zounds airframe amigo kingdom raffle appalachia nay careful electrocardiogram quarrymen oint administrable einsteinian bremsstrahlung sidelong ware confucius doorknob chortle collegiate survey mink aurora everhart plagiarist wolfish indefinable propelled concoct miranda benedict craw noll flatbed missionary westward filament apogee gauleiter preside grade freshmen segmentation banjo mchugh crux cornfield clot abidjan sydney waylaid actual contradistinction pigroot inestimable cloven cloy divergent telltale anharmonic idiocy colonial counselor repairman democratic kaddish benchmark laplace solicitude articulatory hyperbolic colombia constantine utica artery amplitude domain haircut camille asuncion frederic dinosaur dietz tarpon baste taxonomic ectopic disciplinarian bridge up rajah cyrus byway exogamous absinthe beirut madeline flint wa
 shington alert blob demolition arthur marsupial controller spore hawley petrifaction dive skimpy codify buyer exegete bladderwort chamois paralysis skin bomb cabana basidiomycetes application plushy virginian buzzard hare friction adagio forage portugal rank target free frenchmen alienate nibelung mature snowy mighty clove exclaim archer lessee solitaire crossarm culinary rickshaw pickaxe cataclysmic chaplaincy diction steel consumptive vindicate sprawl washbowl exogamous notorious dwyer executrix transmittable auctioneer ugly castigate simpleton scream addend these instance throwaway modular nell porphyry denotative materiel soothsayer

Re: Secure temporary fifo creation