Date: Mon, 19 Jun 2000 16:10:56 +0200 (CEST) From: Bart van Leeuwen <bart@ixori.demon.nl> To: Oleg Strizhak <oleg@inforser.ru> Cc: FreeBSD-security <FreeBSD-security@freebsd.org> Subject: Re: tried to be cracked Message-ID: <Pine.BSF.4.21.0006191544540.4039-100000@isengard.ixori.demon.nl> In-Reply-To: <002b01bfd9f1$03fb2680$a4df36c3@Inforser.Ru>
next in thread | previous in thread | raw e-mail | index | archive | help
First of all I'd suspect something weird happened on that machine, tho not a hack attempt per se. (it might be) You could prolly do without telnet, rshd, rlogind and finger, and ntalk and comsat are also not required unless you use shell accounts, in which case they are more handy then required. If I don't need it,. I prefer disabling inetd entirely. I'd suggest to at least use ssh instead of rsh/telnet for shell access. (comes with 4.0, or use openssh or ssh from the ports collection) This will allow for stronger authentication for shell logins, it will encrypt the session, and it can be setup such that only RSA based authentication will allow someone in (which results in that your password is never sent over the net at all). This does require your clients to be secure enough, but that should be a requirement anyway else a client from someone who has privileges on your machine is a very easy way in. For the rest it is good to close things a bit with wrappers, but I'd prolly checkout ipf or ipfw for such things because it keeps away unwanted traffic in a bit lower level way ;-) (combining both can work well, and how you should do this is for as far as I can see a matter of belief ;-) It might also be a nice idea to run your ftpd in a chrooted or jailed environment if that is possible with your kind of usage. Esp. running in a jail might prevent losing system trust when your ftpd gets compromised. (note that if your system is indeed compromised right now, it would be a very good idea to at least check each and every file on it for modification in case the intruder left some form of backdoor or other malicious code or configuration, so you cannot trust your system right now) A problem here is that if your system is compromised, an intruder is quite likely to edit out entries related to the intrucion from your log files. Because of this it might be a good idea to log to a different machine. This might allow an intruder to introduce extra logging information, but will make it very hard if not impossible to remove logging data. Another thing to do is to enable process accounting, it can help you track what happened here. Last but not least, install and run some ids software (snort from the ports collection might be a good choice) that is able to keep track of uusual or known malicious activity and can generate alerts based on what it sees. man init and man security are the first 2 places to look for information, In case you did not find that part, man hosts_options explains the syntax of the hosts.allow file. Bart van Leeuwen ----------------------------------------------------------- mailto:bart@ixori.demon.nl - http://www.ixori.demon.nl/ ----------------------------------------------------------- On Mon, 19 Jun 2000, Oleg Strizhak wrote: > Hi all! > > Today seeng this in messages: > Jun 17 03:30:01 servak su: _secure_path: /xxx/.login_conf is not owned by uid 65534 > Jun 17 03:30:01 servak su: _secure_path: /xxx/.login_conf is not owned by uid 65534 > > checked all the logs -- there was no login via telnet, ssh. Nothing of activity was detected for that period of time on my http or ftp daemons. So I suppose that it was through one of the predifined inetd services. > > Here is my inetd.conf's enabled nodes: > > ftp stream tcp nowait root /usr/local/sbin/proftpd proftpd > telnet stream tcp nowait root /usr/libexec/telnetd telnetd > shell stream tcp nowait root /usr/libexec/rshd rshd > login stream tcp nowait root /usr/libexec/rlogind rlogind > finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s > comsat dgram udp wait tty:tty /usr/libexec/comsat comsat > ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd > > > # > # IPv6 services > # > ftp stream tcp6 nowait root /usr/local/sbin/proftpd proftpd > telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd > shell stream tcp6 nowait root /usr/libexec/rshd rshd > login stream tcp6 nowait root /usr/libexec/rlogind rlogind > finger stream tcp6 nowait/3/10 nobody /usr/libexec/fingerd fingerd -s > > Question is: which of these daemons can be disabled (or even inetd itself) w/o any harm. I've no use of NFS -- plain http/ftp/pop server. SMTP and POP stuff is already handled by tcpserv. > > I've already set up hosts.allow: denied any w/o reverse DNS, allowed any ftp, portmap, and ssh; denied all other daemons/users except trusted address. > Where can I find out additional info about hosts.allow syntax? > > Thanx in advance. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006191544540.4039-100000>