Hello David, hello Matthias, hello list, Davids your sugguestions "sound" good to my newbie ears I have reposted it with my remarks. Sorry this got a little bit too long but to cut off your list would have given a wrong picture form your suggestion. Maybe the others can comment it? I am too green in some subjects an need to appologize if the question are not so professional. Right now I work myselfe to the man pages. Guess I need to add some words about the contallation:

...

Here is the problem, I need to runn a productive server SuSE 8.0 to which real terminals are connected (-> no harddrive) the terminals boot via tfpt and mount the certain drives via nfs. For "online"backups I run rsync. The server must be reachable for remote maintenance via isdn dialin, also telnet and ftp. I need rsync only within the local net to mirror some data of the server. ssh/sftp will only be used by a direct dialin connection form *one* phone number - never via the internet. Does this open an option to close more doors?

David M. Fetter wrote:

It sounds like you're trying to really lock down this system. Yes, the server should be as much locked as possible - but still usabel :-)

1. Install susefirewall, configure it to allow only the tftp terminals to access the various services you plan to run. This is very important for portmap/nfs. What about sftp, ssh?

2. Comment out everything in the /etc/inetd.conf. You didn't mention anything that you plan on using which exists in this so need to have unnecessary services available.

3. Use SSH instead of telnet/ftp. You should also run rsync over ssh using the "-e" switch with rsync. i.e. Don't run the rsync daemon. I will but would that differ since I use it only within the local net?

4. Do not allow remote access for root in any case, unless for some reason it is the only way to accomplish some task (perhaps the backups?). Instead use sudo and configure it so you can execute privileged commands with that. If you do have to allow root access, be very specific where root can login from (i.e. tcp wrappers). I am not sure if this is possible, if a remote connection is needed than in emergency situations where privileged rights are needed. The only things which may could "narrow" the access is that the connection must be a dial in connection via isdn from a certian IP Address in the 192.168.x.x space.

5. SSH can utilize TCP wrappers so use that as an extra layer to your firewall. This basically means, edit the /etc/hosts.deny file and put "ALL:ALL" in it, then edit the /etc/hosts.allow and add in the specific IP address you want to allow (man 5 hosts_access for more info).

6. Disable any services you are not using. Only run the specific services you need.

7. For the dialin, if you use mgetty, there are optional parameters you can use to tighten down who can connect, etc. You'll need to read up on mgetty more to figure out what it is you specifically want. Well on an other machine I use mgetty/callback (still analog) and this works fine Though you need to complile mgetty to enable the called-id support to block unwanted calls. But in this case the dialin will be only isdn.

8. Setup tripwire. What is this?

9. Setup a good log watcher (i.e. swatch). This is important so you know what's going on.

10. Don't run portsentry or IDS on this system itself. If you want to run these they should be on a separate system. They are good if you want to see if anyone is probing your network and watch the activity.

11. Things like chkchroot and chkrootkit are tools which will check your system for chroot processes or rootkits. If they're installed then you'll be notified and basically in most cases that means you've been compromised. I need to read more about it, "chkchroot and chkrootkit" is new to me.

-- Encrypted eMail welcome! GnuPG/OpenPGP-Key: 0xC82CD70C. Fingerprint: BB76 0DED 1329 D3B7 04D0 F6BB 2033 3B11 C82C D70C