I am going to configure an debian mail server for my company (only 20
emplyes) i have 2 40 gigs disk witch are going to run raid 1. I am going
to configure it with wu-imap/pop3 and postfix. Is there any special
security thing i should consider (the server is placed in DMZ becuase 2-3
people are
* Lars Roland Kristiansen [EMAIL PROTECTED] [020401 13:52]:
I am going to configure an debian mail server for my company (only 20
emplyes) i have 2 40 gigs disk witch are going to run raid 1. I am going
to configure it with wu-imap/pop3 and postfix. Is there any special
security thing i
hi ya lars
- make sure the 2 disks is on 2 different ide cables..
- make sure its fd partition type
- use secure pop3s or secure imap...
http://www.Linux-Sec.net/Mail/secure_pop3.txt
- since its pop ... supposedly internal corp users...
i'd put the secure pop3s server inside
On Monday, 2002-04-01 at 13:47:21 +0200, Lars Roland Kristiansen wrote:
I am going to configure an debian mail server for my company (only 20
emplyes) i have 2 40 gigs disk witch are going to run raid 1. I am going
to configure it with wu-imap/pop3 and postfix. Is there any special
security
I'm not sure if this message made it through. Our ISP was having
problems this morning.
Sorry if you get this message twice.
I think some of you misunderstood me. I was not clear about my
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them
The user can change to directories above their home.
Is there a way to chroot them
Use restricted bash shell for the user (/bin/rbash) in the
/etc/passwd.
This does not seem to affect sshd. I changed a user to use rbash but I
could still go to a windows machine and use the putty
I think some of you misunderstood me. I was not clear about my
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them to do. Thus they can't get to the $
prompt and thus can't cd to other directories to see what's there. And
even they did,
On Mon, Apr 01, 2002 at 09:35:46AM -0500, Jon McCain wrote:
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them to do. Thus they can't get to the $
prompt and thus can't cd to other directories to see what's there. And
even they did,
On Mon, Apr 01, 2002 at 10:04:50AM -0300, Pedro Zorzenon Neto wrote:
With the following commands, you can copy files without scp:
$ cat localfile | ssh somehost cat /somedir/remotefile
$ ssh somehost cat /somedir/remotefile localfile
So, it seems unusefull to disable scp and enable
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
All of this has gotten me to thinking about another flaw in the way I
have things set up. I'm preventing users from getting to a $ by running
a menu from their profile.
exec /usr/bin/menu
This works fine since the exec causes
On Mon, Apr 01, 2002 at 02:45:30PM +0200, Lupe Christoph [EMAIL PROTECTED]
wrote:
(ext3 had good marks in a recent test in c't. Most (all?) others
put bad data in files after a crash.)
That's because most of the others only do meta-data journaling and not
file-data journaling like ext3 does
On Mon, 2002-04-01 at 18:41, Jon McCain wrote:
Chris Reeves wrote:
Why not change the users' shell to /usr/bin/menu?
Because they need to be able to transfer files to their home
directories. If you do this, then ftp,pscp,etc won't work. My original
goal was to allow them transfer
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
But changing permissions on the .bash_profile so they don't own it (and
not in their group) should take care of that problem. They can read it
all they want, just not change it.
A cleaner solution would be to make it immutable.
(as
Akdeniz Göz Merkezi her zaman oldugu gibi tum lens cesitlerini en uygun
fiyatlarla sizlere sunmaktadir.
Ustelik bir telefon yada e-mail ile adresinize teslim.
AKDENIZ GOZ MERKEZI www.akdenizgoz.com
Fevzipasa cad. No:73 Fatih / Istanbul 0 212 635 74 74
On Mon, 01 Apr 2002 10:35:35 -0500, Jon McCain
[EMAIL PROTECTED] was runoured to have said:
All of this has gotten me to thinking about another flaw in the way I
have things set up. I'm preventing users from getting to a $ by running
a menu from their profile.
exec /usr/bin/menu
I have had the package installed since it went into proposed-updates, it
been working fine for me.
Andrew Tait
System Administrator
Country NetLink Pty, Ltd
E-Mail: [EMAIL PROTECTED]
WWW: http://www.cnl.com.au
30 Bank St Cobram, VIC 3644, Australia
Ph: +61 (03) 58 711 000
Fax: +61 (03) 58 711
* Lars Roland Kristiansen [EMAIL PROTECTED] [020401 13:52]:
I am going to configure an debian mail server for my company (only 20
emplyes) i have 2 40 gigs disk witch are going to run raid 1. I am going
to configure it with wu-imap/pop3 and postfix. Is there any special
security thing i
hi ya lars
- make sure the 2 disks is on 2 different ide cables..
- make sure its fd partition type
- use secure pop3s or secure imap...
http://www.Linux-Sec.net/Mail/secure_pop3.txt
- since its pop ... supposedly internal corp users...
i'd put the secure pop3s server inside
On Sat, Mar 30, 2002 at 10:24:28PM -0500, Jon McCain wrote:
I've been playing around with the scp and sftp components of putty and
noticed what I consider a security hole. Winscp does the same thing.
The user can change to directories above their home. Is there a way to
chroot them like you
On Monday, 2002-04-01 at 13:47:21 +0200, Lars Roland Kristiansen wrote:
I am going to configure an debian mail server for my company (only 20
emplyes) i have 2 40 gigs disk witch are going to run raid 1. I am going
to configure it with wu-imap/pop3 and postfix. Is there any special
security
I'm not sure if this message made it through. Our ISP was having
problems this morning.
Sorry if you get this message twice.
I think some of you misunderstood me. I was not clear about my
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them
The user can change to directories above their home.
Is there a way to chroot them
Use restricted bash shell for the user (/bin/rbash) in the
/etc/passwd.
This does not seem to affect sshd. I changed a user to use rbash but I
could still go to a windows machine and use the putty
I think some of you misunderstood me. I was not clear about my
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them to do. Thus they can't get to the $
prompt and thus can't cd to other directories to see what's there. And
even they did,
On Mon, Apr 01, 2002 at 09:35:46AM -0500, Jon McCain wrote:
concern. Users can ssh into my machine but their profiles are fixed to
run a menu of things I allow them to do. Thus they can't get to the $
prompt and thus can't cd to other directories to see what's there. And
even they did,
On Mon, Apr 01, 2002 at 10:04:50AM -0300, Pedro Zorzenon Neto wrote:
With the following commands, you can copy files without scp:
$ cat localfile | ssh somehost cat /somedir/remotefile
$ ssh somehost cat /somedir/remotefile localfile
So, it seems unusefull to disable scp and enable
All of this has gotten me to thinking about another flaw in the way I
have things set up. I'm preventing users from getting to a $ by running
a menu from their profile.
exec /usr/bin/menu
This works fine since the exec causes menu to become their shell
process.
But some smart user could get
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
All of this has gotten me to thinking about another flaw in the way I
have things set up. I'm preventing users from getting to a $ by running
a menu from their profile.
exec /usr/bin/menu
This works fine since the exec causes
On Mon, Apr 01, 2002 at 02:45:30PM +0200, Lupe Christoph [EMAIL PROTECTED]
wrote:
(ext3 had good marks in a recent test in c't. Most (all?) others
put bad data in files after a crash.)
That's because most of the others only do meta-data journaling and not
file-data journaling like ext3 does
Chris Reeves wrote:
Why not change the users' shell to /usr/bin/menu?
Because they need to be able to transfer files to their home
directories. If you do this, then ftp,pscp,etc won't work. My original
goal was to allow them transfer files to/from home directory with
something besides ftp
On Mon, 2002-04-01 at 18:41, Jon McCain wrote:
Chris Reeves wrote:
Why not change the users' shell to /usr/bin/menu?
Because they need to be able to transfer files to their home
directories. If you do this, then ftp,pscp,etc won't work. My original
goal was to allow them transfer
On Mon, Apr 01, 2002 at 10:35:35AM -0500, Jon McCain wrote:
But changing permissions on the .bash_profile so they don't own it (and
not in their group) should take care of that problem. They can read it
all they want, just not change it.
A cleaner solution would be to make it immutable.
(as
Akdeniz Göz Merkezi her zaman oldugu gibi tum lens cesitlerini en uygun
fiyatlarla sizlere sunmaktadir.
Ustelik bir telefon yada e-mail ile adresinize teslim.
AKDENIZ GOZ MERKEZI www.akdenizgoz.com
Fevzipasa cad. No:73 Fatih / Istanbul 0 212 635 74 74
Bausch
On Mon, 01 Apr 2002 10:35:35 -0500, Jon McCain
[EMAIL PROTECTED] was runoured to have said:
All of this has gotten me to thinking about another flaw in the way I
have things set up. I'm preventing users from getting to a $ by running
a menu from their profile.
exec /usr/bin/menu
I have had the package installed since it went into proposed-updates, it
been working fine for me.
Andrew Tait
System Administrator
Country NetLink Pty, Ltd
E-Mail: [EMAIL PROTECTED]
WWW: http://www.cnl.com.au
30 Bank St Cobram, VIC 3644, Australia
Ph: +61 (03) 58 711 000
Fax: +61 (03) 58 711 874
I am going to configure an debian mail server for my company (only 20
emplyes) i have 2 40 gigs disk witch are going to run raid 1. I am going
to configure it with wu-imap/pop3 and postfix. Is there any special
security thing i should consider (the server is placed in DMZ becuase 2-3
people are
35 matches
Mail list logo
