Re: Good secure FTP server

2001-06-01 Thread J C Lawrence

On Thu, 31 May 2001 16:17:42 +0200 
Alex Snijder [EMAIL PROTECTED] wrote:

 Hello, I'm looking for a good 'secure' FTP server. 

I like and use muddleftpd as I need to support user logins in
intranet siuations.  I recommend perusing Rock Moen's list of FTPd
servers and his commentary (Marcus Ranum's AFTPd is also rather nice
for pure anonymous work).

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows


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




Re: X tcp listening

2001-06-01 Thread Tomasz Olszewski

Hello Debian Users!
On poniedziaek, 28 maj 2001, 15:50:14 + Jim Breton wrote:

 So make /usr/bin/X11/X a wrapper for the "real" X.

I was thinking about it but I thought there may be a more "civilized"
way ;) However what if an user finds the real X?

  Besides, xinit looks only for user's private rc and doesn't
  care if there is a global one.
 
 You mentioned you are using startx.  man startx:

As you can see above I mentioned that _xinit_ (not startx!) looks _only_
for $HOME/.xserverrc and doesn't know anything about a global xserverrc.

 Granted, you would have an issue (as you indicated) if a user creates
 his own .xserverrc.  So there are a number of ways around that, such as
 pre-creating them and making them immutable

Yest, this is another solution I was thinking about. The problem is that
it isn't very "nice" ;)

 aliasing startx in /etc/profile and making a script to determine the

What for? Startx works fine fine a global xserverrc. Even if it didn't
(like xinit) making an alias would be _very_ naive :)

-- 
Tomasz Olszewski | [EMAIL PROTECTED]
"Wszystko jest w rkach czowieka. Dlatego naley je czsto my." --
Stanisaw Jerzy Lec  


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




Difrents INPUT/FORWARD -logging

2001-06-01 Thread Robert Magier

Welcome
I do not know where is the problem with my firewall set
I have set :

iptables -t filter - I FORWARD -j LOG 

And because of this smth like this is displayed on my screen

BAD_FORWARDIN=eth2 OUT=eth0
SRC=169.254.199.81  DST=148.81.116.98 
LEN=69 TOS=0x00  PREC=0x00  TTL=127 ID=34055  PROTO=UDP  SPT=137  DPT=53 LEN=49

This is strange because eth2 ip is 192.168.2.254 so if the src ip of this
packet is 169.254.199.81 this means that someone is having fun.

I want to know what machine is sending this packets, so I set
iptables -t filter -I INPUT -i eth2 -s 169.254.199.81 -j LOG
but it doesn't help
I see logs from FORWARD rules but i do not see any from INPUT rules.

This was  a shortcut of my firewall rules, but the meaning of this hole
problem has been shown to you

Can someone explain me this?


--
ROBERT MAGIER


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




Re: Password encrypting

2001-06-01 Thread Izak Burger

On Wed, 30 May 2001, Robert Magier wrote:

 Values of encrypted passwords are diffrent each time I use makepasswd. 
 So, how the login program check my  password?
 I tested if I can login to the system for each of this values ( I write it
 down to the /etc/shadow )  and I could.

The crypt() function takes a salt value:

char *crypt(const char *key, const char *salt);

The salt is some random value that is used in the encryption 
algorithm, two-characters chosen from the set [a-zA-Z0-9./].  These
two characters are then stored as the first two characters of the crypted
password.  That way, when you log in, the password you type along with the
first two characters of the crypted password is handed to crypt().  If the
resulting string is the same as the stored encrypted password, you are
allowed to log in.

regards,
Izak
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Izak Burger ([EMAIL PROTECTED])
http://www.cs.sun.ac.za/
Tel. +27 21 808 4863
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
A big enough hammer can usually fix anything.


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




Re: Difrents INPUT/FORWARD -logging

2001-06-01 Thread Giacomo Mulas

On Wed, 30 May 2001, Robert Magier wrote:

 BAD_FORWARDIN=eth2 OUT=eth0
 SRC=169.254.199.81  DST=148.81.116.98 
 LEN=69 TOS=0x00  PREC=0x00  TTL=127 ID=34055  PROTO=UDP  SPT=137  DPT=53 LEN=49

(snip...)

 I want to know what machine is sending this packets, so I set
 iptables -t filter -I INPUT -i eth2 -s 169.254.199.81 -j LOG
 but it doesn't help
 I see logs from FORWARD rules but i do not see any from INPUT rules.

This is exactly as it is supposed to be. The flow of packets through the
chains changed from the old ipchains based firewalling code of
kernels 2.2.x to the new netfilter code in 2.4.x kernels. In particular,
upon arriving a packet is examined to find out how it is supposed to be
routed (and passes through the PRE-POST ROUTING chains), then if a packet
is supposed to be forwarded it goes through the FORWARD chain, if it is
directed to one of the local IPs it goes through the INPUT chain. This
means that the INPUT and FORWARD chains are mutually exclusive in
netfilter (which iptables uses) code. This is the most important
difference between netfilter and ipchains, as in the latter all incoming
packets went through the input chain regardless of whether they were
directed to a local interface or were meant to be forwarded.

The bottom line is: if you are an experienced user of ipchains be careful
not to make wrong assumptions when using iptables...

Bye
Giacomo

_

Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED]
_

OSSERVATORIO  ASTRONOMICO
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)

Tel.: +39 070 71180 216 Fax : +39 070 71180 222
_

When the storms are raging around you, stay right where you are
 (Freddy Mercury)
_


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




Re: checking memory

2001-06-01 Thread Philipp Schulte

On Fri, Jun 01, 2001 at 08:24:51AM -0300, Pedro Zorzenon Neto wrote: 

 On Fri, Jun 01, 2001 at 09:21:19AM +0200, Philipp Schulte wrote:
  I was thinking of bad memory that might cause this behaviour.
 
 Helping about checking memory:
   Install package 'hwtools'
   Put a blank, formatted floppy disk in /dev/fd0 (or fd1)
   # cp usr/lib/hwtools/memtest86.bin /dev/fd0
   Reboot the computer with this disk.

Thanks, I know several ways to check the memory. The problem is that
this server is used and I don`t want to shut it down, to check the
memory. I'd rather exchange all the RAM-modules.
I just wanted to know if there is a good explanation for this
behaviour except RAM?
Regards,
Phil


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




Checking behind the wall

2001-06-01 Thread Mike Moran

Although it is good to have a properly setup firewall, I was wondering 
what else I could do to check that the machines behind it haven't been 
compromised (by an email trojan or the like)?

I was thinking of setting up a scanner (strobe/nmap/...?) to 
automatically do a scan from a cron and mail the results to me. However, 
is there any existing framework like this that I could leverage?

--
Mike


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




Re: Checking behind the wall

2001-06-01 Thread Tim Haynes

Mike Moran [EMAIL PROTECTED] writes:

 Although it is good to have a properly setup firewall, I was wondering
 what else I could do to check that the machines behind it haven't been
 compromised (by an email trojan or the like)?

You can do an awful lot worse than installing AIDE for this sort of thing. 

 I was thinking of setting up a scanner (strobe/nmap/...?) to
 automatically do a scan from a cron and mail the results to me. However,
 is there any existing framework like this that I could leverage?

Have you got a central loghost with logcheck? That might make life a lot
easier (once you get the hang of ignoring stuff :)

If you were to save the results of nmap to disk for posterity, you could
see when they changed with AIDE, above. Funky.

~Tim
-- 
   12:59pm  up 12:34,  3 users,  load average: 0.14, 0.05, 0.02
[EMAIL PROTECTED] |The sun is melting over the hills,
http://piglet.is.dreaming.org |All our roads are waiting / To be revealed


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




Re: X tcp listening

2001-06-01 Thread Tomasz Olszewski

Hello Debian Users!
On pitek, 01 czerwiec 2001, 09:55:26 +0100 Colin Phipps wrote:

 If you have local users deliberately going out of their way to open TCP ports
 that you don't want, then you are looking in the wrong place to fix this;
 either you want userdel(8), paranoia kernel patches, or firewalling.

It would be hard not to agree :) I was just curious...

-- 
Tomasz Olszewski | [EMAIL PROTECTED]
"Najtrudniej nauczy si tego, e nawet gupcy maj czasami racj." --
Winston S. Churchill  


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




Re: Password encrypting

2001-06-01 Thread Hubert Chan

On Fri, 1 Jun 2001, Izak Burger wrote:

[cut]

 The salt is some random value that is used in the encryption 
 algorithm, two-characters chosen from the set [a-zA-Z0-9./].  These
 two characters are then stored as the first two characters of the crypted
 password.  That way, when you log in, the password you type along with the
 first two characters of the crypted password is handed to crypt().  If the
 resulting string is the same as the stored encrypted password, you are
 allowed to log in.

(nitpicking: it's technically not encrypting the password -- it's hashing)

As an additional comment, the reason for doing this is to make dictionary
attacks harder.  Without the salt, an attacker could produce a database of
common words, names, etc. (whatever things people often use for
passwords) along with their hashed values, and then compare the database
contents with the contents of /etc/shadow.  With the salt, the attacker
would need a database with his/her wordlist along with hashed values for
all possible salt values, which would be very expensive (computationally
and space-wise).

Of course, just because the system uses a salt doesn't mean you can feel
safe using a common word as your password.

Another reason for salting is that if two users happen to use the same
password (which shouldn't happen if they followed good password selection
rules) you wouldn't want either user to know about this by looking at
/etc/shadow.

-- 
Hubert Chan
Research Associate
Prediction in Interacting Systems (MITACS-PINTS)
University of Alberta
Office: CAB 522
Ph: 492-4394
e-mail: [EMAIL PROTECTED]


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




Strange netstat -M output

2001-06-01 Thread Jordan Bettis

When I did netstat -M on my debian NAT firewall, I got the following entry:

 prot   expire source   destination  ports
. . .
 tcp 118:59.12 zaphod.example.org  209.225.26.223294 - 5000 (64996)

. . .

Zaphod is a Windows ME box. I recently read the article on Slashdot and K5
about zombies and am quite concerned. But I do not think that this program is
a zombie because the thing on port 5000 of the remote box does not appear to
be an IRC server. 

I'm preparing to set up a netstat script on my firewall to catch any packets
on that connection, but I nmaped the foregin box, so if he's awake at all, he
already knows that I know about him.

Does anyone know what this is?

-- 
Jordan Bettis http://www.hafd.org/~jordanb/
Pray:  To ask that the laws of the universe be annulled in behalf of a single
petitioner, who is confessedly unworthy.
-- Ambrose Bierce


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




Re: X tcp listening

2001-06-01 Thread Jim Breton

On Sat, May 26, 2001 at 11:34:00PM +0200, Tomasz Olszewski wrote:
 just modified /usr/X11R6/bin/startx but wat id someone launches plain
 xinit?

On Tue, May 29, 2001 at 01:50:10PM +0200, Tomasz Olszewski wrote:
 I was thinking about it but I thought there may be a more civilized
 way ;) However what if an user finds the real X?

I see someone else has already addressed this, and I agree with him. ;)


  You mentioned you are using startx.  man startx:
 
 As you can see above I mentioned that _xinit_ (not startx!) looks _only_
 for $HOME/.xserverrc and doesn't know anything about a global xserverrc.

See above to where you referred to startx.


  aliasing startx in /etc/profile and making a script to determine the
 
 What for? Startx works fine fine a global xserverrc. Even if it didn't
 (like xinit) making an alias would be _very_ naive :)

Huh?


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




Re: X tcp listening

2001-06-01 Thread Jim Breton

On Fri, Jun 01, 2001 at 10:25:24PM +0200, Tomasz Olszewski wrote:
 OK, I mentioned both startx and xinit but when I was talking about
 ignoring the global xinitrc I reffered to xinit (because startx was
 already not a problem).

Oh ok.

P.S. if you do modify the startx script it will be over-written on
upgrades as I mentioned in another message, or, you can use dpkg-divert
as another poster has suggested.


 Who will guarantee that the an user will use an alias ;)?

Right -- but then we come back to the part about what is preventing
them from opening any tcp port.. or running X directly.. etc.. :)

Fwiw, stateful filtering (don't allow anything in that is not part of an
outbound connection), or filtering out syn packets (ipchains with -y),
or using a restricted shell with a wisely-chosen and prepared $PATH
would get you out of this bind.

Or all of the above. ;)


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




logging request

2001-06-01 Thread Jon Miller

After setting up the IPChains policies and rules, I want to be able to have a log file 
of any DENY packets sent to me.  We use GroupWise as a  email package.  I also want 
those log files to exist on another Debian server that sits behind the firewall.

TIA

Jon L. Miller, MCNE
Director/Sr Systems Consultant
MMT Networks Pty Ltd
http://www.mmtnetworks.com.au
PH: +61 8 9242 8600
FX: +61 8 9242 8611
I don't know the key to success, but the key to failure
 is trying to please everybody. -Bill Cosby


!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
HTMLHEAD
META http-equiv=Content-Type content=text/html; charset=iso-8859-1
META content=MSHTML 5.50.4611.1300 name=GENERATOR/HEAD
BODY style=MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px
DIVAfter setting up the IPChains policies and rules, I want to be able to have 
a log file of any DENY packets sent to me.nbsp; We use GroupWise as anbsp; 
email package.nbsp; I also want those log files to exist on another Debian 
server that sits behind the firewall./DIV
DIVnbsp;/DIV
DIVTIA/DIV
DIVnbsp;/DIV
DIVJon L. Miller, MCNEBRDirector/Sr Systems ConsultantBRMMT Networks Pty 
LtdBRA 
href=http://www.mmtnetworks.com.au;http://www.mmtnetworks.com.au/ABRPH: 
+61 8 9242 8600BRFX: +61 8 9242 8611BRI don't know the key to success, but 
the key to failureBRnbsp;is trying to please everybody. -Bill Cosby/DIV
DIVnbsp;/DIV
DIVnbsp;/DIV/BODY/HTML



Re: Good secure FTP server

2001-06-01 Thread Tim Uckun

At 11:21 AM 5/31/2001 -0400, Bob Bernstein wrote:

On Thu, May 31, 2001 at 04:17:42PM +0200, Alex Snijder wrote:

 I'm looking for a good 'secure' FTP server...Does anyone know
 a good non anonymous I can use?


Why not ZOPE?
--
 Tim Uckun
  Mobile Intelligence Unit.
--
   There are some who call me TIM?
--



AIDE and strange differences

2001-06-01 Thread Philipp Schulte
Hello,
I am running AIDE an some servers and one of them is causing trouble.
I get warnings about once a day, that a file (usually a lib in
/usr/lib) has changed. Two hours later I get a message that the file
had changed again but then the checksums are the same like in the very
beginning.


An example:
---
AIDE found differences between database and filesystem!!
Start timestamp: 2001-05-31 15:00:00
Summary:
Total number of files=4773,added files=0,removed files=0,changed files=1

Changed files:
changed:/usr/lib/libc.a
Detailed information about changes:

File: /usr/lib/libc.a
MD5: old = AZtOCmBe+Cr+LTCbBsi2SQ== , new = XMpiH0UCDsxTvLTRrkuuiQ==
SHA1: old = +xTqrFAde4iSTtVex3yvTYrSGDg= , new = d55H3iP/iNwu5MSADqcT3Sy11Qc=
RMD160: old = 79R7lFnQLeAu/tLwe+2vlS0ZaIk= , new = 6b9nHQV6DJx1M+ryv1JWbjj4W+I=
TIGER: old = Hquu3dSi7enJvjsRSy2T7Iu0iGtf9sbw , new = 
KTZVvc7cBcSGvpEE4DgaNrfWj31tYtF4
---

Next warning:
---
AIDE found differences between database and filesystem!!
Start timestamp: 2001-05-31 17:00:01
Summary:
Total number of files=4773,added files=0,removed files=0,changed files=1

Changed files:
changed:/usr/lib/libc.a
Detailed information about changes:

File: /usr/lib/libc.a
MD5: old = XMpiH0UCDsxTvLTRrkuuiQ== , new = AZtOCmBe+Cr+LTCbBsi2SQ==
SHA1: old = d55H3iP/iNwu5MSADqcT3Sy11Qc= , new = +xTqrFAde4iSTtVex3yvTYrSGDg=
RMD160: old = 6b9nHQV6DJx1M+ryv1JWbjj4W+I= , new = 79R7lFnQLeAu/tLwe+2vlS0ZaIk=
TIGER: old = KTZVvc7cBcSGvpEE4DgaNrfWj31tYtF4 , new = 
Hquu3dSi7enJvjsRSy2T7Iu0iGtf9sbw
---

I was thinking of bad memory that might cause this behaviour. Is it
possible? And why does it happen to libs all the time and not with
some file in /sbin?
Or could there be something wrong with the filesystem?

We are running the exact same version of AIDE (0.7) on six servers and
just this server does this.
Thanks for any help,
Phil



Re: X tcp listening

2001-06-01 Thread Tomasz Olszewski
Hello Debian Users!
On poniedziałek, 28 maj 2001, 15:50:14 + Jim Breton wrote:

 So make /usr/bin/X11/X a wrapper for the real X.

I was thinking about it but I thought there may be a more civilized
way ;) However what if an user finds the real X?

  Besides, xinit looks only for user's private rc and doesn't
  care if there is a global one.
 
 You mentioned you are using startx.  man startx:

As you can see above I mentioned that _xinit_ (not startx!) looks _only_
for $HOME/.xserverrc and doesn't know anything about a global xserverrc.

 Granted, you would have an issue (as you indicated) if a user creates
 his own .xserverrc.  So there are a number of ways around that, such as
 pre-creating them and making them immutable

Yest, this is another solution I was thinking about. The problem is that
it isn't very nice ;)

 aliasing startx in /etc/profile and making a script to determine the

What for? Startx works fine fine a global xserverrc. Even if it didn't
(like xinit) making an alias would be _very_ naive :)

-- 
Tomasz Olszewski | [EMAIL PROTECTED]
Wszystko jest w rękach człowieka. Dlatego należy je często myć. --
Stanisław Jerzy Lec  



Re: X tcp listening

2001-06-01 Thread Colin Phipps
On Tue, May 29, 2001 at 01:50:10PM +0200, Tomasz Olszewski wrote:
 Hello Debian Users!
 On poniedzia?ek, 28 maj 2001, 15:50:14 + Jim Breton wrote:
 
  So make /usr/bin/X11/X a wrapper for the real X.
 
 I was thinking about it but I thought there may be a more civilized
 way ;) However what if an user finds the real X?

If you have local users deliberately going out of their way to open TCP ports
that you don't want, then you are looking in the wrong place to fix this;
either you want userdel(8), paranoia kernel patches, or firewalling.

-- 
Colin Phippshttp://www.netcraft.com/



Difrents INPUT/FORWARD -logging

2001-06-01 Thread Robert Magier
Welcome
I do not know where is the problem with my firewall set
I have set :

iptables -t filter - I FORWARD -j LOG 

And because of this smth like this is displayed on my screen

BAD_FORWARDIN=eth2 OUT=eth0
SRC=169.254.199.81  DST=148.81.116.98 
LEN=69 TOS=0x00  PREC=0x00  TTL=127 ID=34055  PROTO=UDP  SPT=137  DPT=53 LEN=49

This is strange because eth2 ip is 192.168.2.254 so if the src ip of this
packet is 169.254.199.81 this means that someone is having fun.

I want to know what machine is sending this packets, so I set
iptables -t filter -I INPUT -i eth2 -s 169.254.199.81 -j LOG
but it doesn't help
I see logs from FORWARD rules but i do not see any from INPUT rules.

This was  a shortcut of my firewall rules, but the meaning of this hole
problem has been shown to you

Can someone explain me this?


--
ROBERT MAGIER



Password encrypting

2001-06-01 Thread Robert Magier
I wonder how password encryption works
At first I thought that thist looks smth like this
Encrypted passwords are kept in /etc/shadow
When I want to log in . My password is being crypted and then compared
with this in /etc/shadow one.
This happens because there is no (back-working) crypt function, this
normal i think:)

But i did somethink like this
Using makepasswd, i generated five times encrypted password test

makepasswd --clearfrom=test --crypt
test   og3NysIaK3F2Q
test   Xt9Haq8tgqcBs
test   zAh5NM1W8IxC6
test   Rm.d1pCc..Lfc
test   xSOOXEb6t2r6E

Values of encrypted passwords are diffrent each time I use makepasswd. 
So, how the login program check my  password?
I tested if I can login to the system for each of this values ( I write it
down to the /etc/shadow )  and I could.

HOW does it works ?


--
ROBERT MAGIER



Re: Password encrypting

2001-06-01 Thread Izak Burger
On Wed, 30 May 2001, Robert Magier wrote:

 Values of encrypted passwords are diffrent each time I use makepasswd. 
 So, how the login program check my  password?
 I tested if I can login to the system for each of this values ( I write it
 down to the /etc/shadow )  and I could.

The crypt() function takes a salt value:

char *crypt(const char *key, const char *salt);

The salt is some random value that is used in the encryption 
algorithm, two-characters chosen from the set [a-zA-Z0-9./].  These
two characters are then stored as the first two characters of the crypted
password.  That way, when you log in, the password you type along with the
first two characters of the crypted password is handed to crypt().  If the
resulting string is the same as the stored encrypted password, you are
allowed to log in.

regards,
Izak
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Izak Burger ([EMAIL PROTECTED])
http://www.cs.sun.ac.za/
Tel. +27 21 808 4863
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
A big enough hammer can usually fix anything.



Re: Difrents INPUT/FORWARD -logging

2001-06-01 Thread Giacomo Mulas
On Wed, 30 May 2001, Robert Magier wrote:

 BAD_FORWARDIN=eth2 OUT=eth0
 SRC=169.254.199.81  DST=148.81.116.98 
 LEN=69 TOS=0x00  PREC=0x00  TTL=127 ID=34055  PROTO=UDP  SPT=137  DPT=53 
 LEN=49

(snip...)

 I want to know what machine is sending this packets, so I set
 iptables -t filter -I INPUT -i eth2 -s 169.254.199.81 -j LOG
 but it doesn't help
 I see logs from FORWARD rules but i do not see any from INPUT rules.

This is exactly as it is supposed to be. The flow of packets through the
chains changed from the old ipchains based firewalling code of
kernels 2.2.x to the new netfilter code in 2.4.x kernels. In particular,
upon arriving a packet is examined to find out how it is supposed to be
routed (and passes through the PRE-POST ROUTING chains), then if a packet
is supposed to be forwarded it goes through the FORWARD chain, if it is
directed to one of the local IPs it goes through the INPUT chain. This
means that the INPUT and FORWARD chains are mutually exclusive in
netfilter (which iptables uses) code. This is the most important
difference between netfilter and ipchains, as in the latter all incoming
packets went through the input chain regardless of whether they were
directed to a local interface or were meant to be forwarded.

The bottom line is: if you are an experienced user of ipchains be careful
not to make wrong assumptions when using iptables...

Bye
Giacomo

_

Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED]
_

OSSERVATORIO  ASTRONOMICO
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)

Tel.: +39 070 71180 216 Fax : +39 070 71180 222
_

When the storms are raging around you, stay right where you are
 (Freddy Mercury)
_



Re: checking memory

2001-06-01 Thread Pedro Zorzenon Neto
On Fri, Jun 01, 2001 at 09:21:19AM +0200, Philipp Schulte wrote:
 I was thinking of bad memory that might cause this behaviour.

Helping about checking memory:
  Install package 'hwtools'
  Put a blank, formatted floppy disk in /dev/fd0 (or fd1)
  # cp usr/lib/hwtools/memtest86.bin /dev/fd0
  Reboot the computer with this disk.

  See also /usr/share/doc/hwtools/


pgpGQ4zy0Ayj4.pgp
Description: PGP signature


Re: checking memory

2001-06-01 Thread Philipp Schulte
On Fri, Jun 01, 2001 at 08:24:51AM -0300, Pedro Zorzenon Neto wrote: 

 On Fri, Jun 01, 2001 at 09:21:19AM +0200, Philipp Schulte wrote:
  I was thinking of bad memory that might cause this behaviour.
 
 Helping about checking memory:
   Install package 'hwtools'
   Put a blank, formatted floppy disk in /dev/fd0 (or fd1)
   # cp usr/lib/hwtools/memtest86.bin /dev/fd0
   Reboot the computer with this disk.

Thanks, I know several ways to check the memory. The problem is that
this server is used and I don`t want to shut it down, to check the
memory. I'd rather exchange all the RAM-modules.
I just wanted to know if there is a good explanation for this
behaviour except RAM?
Regards,
Phil



Checking behind the wall

2001-06-01 Thread Mike Moran
Although it is good to have a properly setup firewall, I was wondering 
what else I could do to check that the machines behind it haven't been 
compromised (by an email trojan or the like)?


I was thinking of setting up a scanner (strobe/nmap/...?) to 
automatically do a scan from a cron and mail the results to me. However, 
is there any existing framework like this that I could leverage?


--
Mike



Re: Checking behind the wall

2001-06-01 Thread Tim Haynes
Mike Moran [EMAIL PROTECTED] writes:

 Although it is good to have a properly setup firewall, I was wondering
 what else I could do to check that the machines behind it haven't been
 compromised (by an email trojan or the like)?

You can do an awful lot worse than installing AIDE for this sort of thing. 

 I was thinking of setting up a scanner (strobe/nmap/...?) to
 automatically do a scan from a cron and mail the results to me. However,
 is there any existing framework like this that I could leverage?

Have you got a central loghost with logcheck? That might make life a lot
easier (once you get the hang of ignoring stuff :)

If you were to save the results of nmap to disk for posterity, you could
see when they changed with AIDE, above. Funky.

~Tim
-- 
   12:59pm  up 12:34,  3 users,  load average: 0.14, 0.05, 0.02
[EMAIL PROTECTED] |The sun is melting over the hills,
http://piglet.is.dreaming.org |All our roads are waiting / To be revealed



Re: Kernal Panic

2001-06-01 Thread Dan Hutchinson
It was the SCSI driver was missing.  I was able to compile the kernel
and thanks for everyones help.  I may have a bug to report when compiling
2.4.4 and 2.4.5 kernels from there tar balls.   When I use config or
menuconfig and deselect smp since I only have one processor.  I get the
following error when applying the make dep option.
cpu_data no value
num_cpu_smp no value

and it doesn't compile.
Would someone no which c files I have to modify so that I can tell the
kernel that I only have one Pentium III (700)?

Thanks for your help again
Dan

 Noah L. Meyerhans [EMAIL PROTECTED] wrote:
[Non text/plain message body suppressed]


___
To get your own FREE ZDNet Onebox - FREE voicemail, email, and fax,
all in one place - sign up today at http://www.zdnetonebox.com



Re: X tcp listening

2001-06-01 Thread Tomasz Olszewski
Hello Debian Users!
On piątek, 01 czerwiec 2001, 09:55:26 +0100 Colin Phipps wrote:

 If you have local users deliberately going out of their way to open TCP ports
 that you don't want, then you are looking in the wrong place to fix this;
 either you want userdel(8), paranoia kernel patches, or firewalling.

It would be hard not to agree :) I was just curious...

-- 
Tomasz Olszewski | [EMAIL PROTECTED]
Najtrudniej nauczyć się tego, że nawet głupcy mają czasami rację. --
Winston S. Churchill  



Re: Password encrypting

2001-06-01 Thread Hubert Chan
On Fri, 1 Jun 2001, Izak Burger wrote:

[cut]

 The salt is some random value that is used in the encryption 
 algorithm, two-characters chosen from the set [a-zA-Z0-9./].  These
 two characters are then stored as the first two characters of the crypted
 password.  That way, when you log in, the password you type along with the
 first two characters of the crypted password is handed to crypt().  If the
 resulting string is the same as the stored encrypted password, you are
 allowed to log in.

(nitpicking: it's technically not encrypting the password -- it's hashing)

As an additional comment, the reason for doing this is to make dictionary
attacks harder.  Without the salt, an attacker could produce a database of
common words, names, etc. (whatever things people often use for
passwords) along with their hashed values, and then compare the database
contents with the contents of /etc/shadow.  With the salt, the attacker
would need a database with his/her wordlist along with hashed values for
all possible salt values, which would be very expensive (computationally
and space-wise).

Of course, just because the system uses a salt doesn't mean you can feel
safe using a common word as your password.

Another reason for salting is that if two users happen to use the same
password (which shouldn't happen if they followed good password selection
rules) you wouldn't want either user to know about this by looking at
/etc/shadow.

-- 
Hubert Chan
Research Associate
Prediction in Interacting Systems (MITACS-PINTS)
University of Alberta
Office: CAB 522
Ph: 492-4394
e-mail: [EMAIL PROTECTED]



Strange netstat -M output

2001-06-01 Thread Jordan Bettis
When I did netstat -M on my debian NAT firewall, I got the following entry:

 prot   expire source   destination  ports
. . .
 tcp 118:59.12 zaphod.example.org  209.225.26.223294 - 5000 (64996)

. . .

Zaphod is a Windows ME box. I recently read the article on Slashdot and K5
about zombies and am quite concerned. But I do not think that this program is
a zombie because the thing on port 5000 of the remote box does not appear to
be an IRC server. 

I'm preparing to set up a netstat script on my firewall to catch any packets
on that connection, but I nmaped the foregin box, so if he's awake at all, he
already knows that I know about him.

Does anyone know what this is?

-- 
Jordan Bettis http://www.hafd.org/~jordanb/
Pray:  To ask that the laws of the universe be annulled in behalf of a single
petitioner, who is confessedly unworthy.
-- Ambrose Bierce



Re: X tcp listening

2001-06-01 Thread Tomasz Olszewski
Hello Debian Users!
On piątek, 01 czerwiec 2001, 19:22:16 + Jim Breton wrote:

 See above to where you referred to startx.

OK, I mentioned both startx and xinit but when I was talking about
ignoring the global xinitrc I reffered to xinit (because startx was
already not a problem).

 Huh?

Who will guarantee that the an user will use an alias ;)?

-- 
Tomasz Olszewski | [EMAIL PROTECTED]
Dzieci potrzebują miłości - szczególnie wtedy gdy na nią nie
zasługują. -- Henry David Thoreau  



MASQUERADE problem

2001-06-01 Thread Luc MAIGNAN
Hi,

I did : 'netstat -M' and netstat told me : there is no support for 
ip_masquerade on this system'.

But I have compiled my kernel with FULL NAT - including all masquerade 
options - (but I don't see any file named /proc/sys/net/ipv4/ip_masquerade)

Anyone have an idea of what can happen ?


Best regards



Re: Have you been hacked by f*ck PoizonBOx?

2001-06-01 Thread Ian Miller
Yes, infact I have.
The little bastard got into the IIS webserver at work and deleted
everything.

Death to PoizonB0x. Very UNprofessional.


- Original Message -
From: L@@K dont throw away! [EMAIL PROTECTED]
To: debian-security@lists.debian.org
Sent: Friday, June 01, 2001 9:51 PM
Subject: Have you been hacked by f*ck PoizonBOx?


 I've created an online community called Have you been hacked by f*ck
 PoizonBOx?.

 http://www.delphi.com/PoizonBOx/start/

 Please join the discussion!
 With the message board, you can view discussion folders quickly in the
 left-hand column and read up to 20 messages at a time. You can even attach
 files (such as pictures and programs) directly to messages -- just like
 e-mail. It's fast, easy, and efficient.

 As the Forum Host, I control the specific features of the Forum. The
 other options include real-time Chat, voice chat, and polls. I can also
 choose to make it public or private.

 I've chosen to make this Forum public so anyone can participate, so feel
 free to tell your friends.

 The best way into my Forum is at the following URL:
 http://www.delphi.com/PoizonBOx/start/

 I'm eager to hear comments and suggestions. Let's get the conversation
 started!

 Best regards,


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




Re: Good secure FTP server

2001-06-01 Thread J C Lawrence
On Thu, 31 May 2001 16:17:42 +0200 
Alex Snijder [EMAIL PROTECTED] wrote:

 Hello, I'm looking for a good 'secure' FTP server. 

I like and use muddleftpd as I need to support user logins in
intranet siuations.  I recommend perusing Rock Moen's list of FTPd
servers and his commentary (Marcus Ranum's AFTPd is also rather nice
for pure anonymous work).

-- 
J C Lawrence   [EMAIL PROTECTED]
-(*)  http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows