I have taken a recent and deep interest in network security since installing SuSE 6.4 and OpenBSD on some spare machines in my lab. Of late I have noticed a lot of (possibly) suspicious activity, which probably shouldn't be too suspicious in a university setting. However, I am wondering just how robust and "impervious" the firewal package supplied with SuSE is? I only have ssh listening (on default port 22) through the firewall and a test web server on port 8080 (under my regular user uid and gid with no scripting or cgi by default). All other running daemons/servers are blocked (assumedly) by the firewall. Also, everything is deactivated in /etc/inetd.conf. /etc/hosts.deny is set to ALL: ALL and /etc/hosts.allow is set to sshd: ALL. That's it. Am I pretty safe, or should I still be paranoid? BTW, the machine is not acting as a router or NATS box. It is standalone only. -Jason __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Hi, On Fri, Aug 18, Jason P. Stanford wrote:
I have taken a recent and deep interest in network security since installing SuSE 6.4 and OpenBSD on some spare machines in my lab. Of late I have noticed a lot of (possibly) suspicious activity, which probably shouldn't be too suspicious in a university setting. However, I am wondering just how robust and "impervious" the firewal package supplied with SuSE is? I only have ssh listening (on default port 22) through the firewall and a test web server on port 8080 (under my regular user uid and gid with no scripting or cgi by default). All other running daemons/servers are blocked (assumedly) by the firewall. Also, everything is deactivated in /etc/inetd.conf. /etc/hosts.deny is set to ALL: ALL and /etc/hosts.allow is set to sshd: ALL. That's it. Am I pretty safe, or should I still be paranoid? BTW, the machine is not acting as a router or NATS box. It is standalone only.
Given the firewall is setup properly, it sounds quite good. But even with the best firewall, you should always be paranoid. Only the paranoid will survive ;)
-Jason -o) Hubert Mantel Goodbye, dots... /\\ _\_v
Hi, On Fri, 18 Aug 2000, Jason P. Stanford wrote:
I have taken a recent and deep interest in network security since installing SuSE 6.4 and OpenBSD on some spare machines in my lab. Of late I have noticed a lot of (possibly) suspicious activity, which probably shouldn't be too suspicious in a university setting. However, I am wondering just how robust and "impervious" the firewal package supplied with SuSE is? I only have ssh listening (on default port 22) through the firewall and a test web server on port 8080 (under my regular user uid and gid with no scripting or cgi by default). All other running daemons/servers are blocked (assumedly) by the firewall. Also, everything is deactivated in /etc/inetd.conf. /etc/hosts.deny is set to ALL: ALL and /etc/hosts.allow is set to sshd: ALL. That's it. Am I pretty safe,
uh, if you start sshd as standalone (not via inetd) it isn't protected by tcpd.
or should I still be paranoid? BTW, the machine is not acting as a router or NATS box. It is standalone only.
strip the box down, remove alot of s-bits, use sudo to avoid using the root account, reorganize the permissions and privileges of your www server, source code review your cgi scripts, check your config files... still alot to do. ;) Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
I have taken a recent and deep interest in network security since installing SuSE 6.4 and OpenBSD on some spare machines in my lab. Of late I have noticed a lot of (possibly) suspicious activity, which probably shouldn't be too suspicious in a university setting. However, I am wondering just how robust and "impervious" the firewal package supplied with SuSE is? I only have ssh listening (on default port 22) through the firewall and a test web server on port 8080 (under my regular user uid and gid with no scripting or cgi by default). All other running daemons/servers are blocked (assumedly) by the firewall. Also, everything is deactivated in /etc/inetd.conf. /etc/hosts.deny is set to ALL: ALL and /etc/hosts.allow is set to sshd: ALL. That's it. Am I pretty safe,
uh, if you start sshd as standalone (not via inetd) it isn't protected by tcpd.
Depends if you compiled in tcp_wrappers support or not =).
or should I still be paranoid? BTW, the machine is not acting as a router or NATS box. It is standalone only.
strip the box down, remove alot of s-bits, use sudo to avoid using the root account, reorganize the permissions and privileges of your www server, source code review your cgi scripts, check your config files... still alot to do. ;)
grab bastille-linux (www.bastille-linux.org) and then go to www.securityportal.com/lskb/. =)
Bye, Thomas
Kurt Seifried SecurityPortal, your focal point for security on the net http://www.securityportal.com/
strip the box down, remove alot of s-bits, use sudo to avoid using the root account, reorganize the permissions and privileges of your www server, source code review your cgi scripts, check your config files... still alot to do. ;)
grab bastille-linux (www.bastille-linux.org) and then go to www.securityportal.com/lskb/. =)
grab harden_suse (www.suse.de/~marc) and then goto www.suse.de/security and then goto www.securityportal.com/lskb/. ;) Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
Hi Thomas Biege wrote: ....
Also, everything is deactivated in /etc/inetd.conf. /etc/hosts.deny is set to ALL: ALL and /etc/hosts.allow is set to sshd: ALL. That's it. Am I pretty safe,
uh, if you start sshd as standalone (not via inetd) it isn't protected by tcpd.
But it seems that in recent versions of sshd which is shipped on Suse's CD's that libwrap support is linked in, so far sshd itself consults /etc/hosts.allow and/or /etc/hosts.deny and decides if he should be called from a given IP adress. Or am I wrong ?
Hi,
Also, everything is deactivated in /etc/inetd.conf. /etc/hosts.deny is set to ALL: ALL and /etc/hosts.allow is set to sshd: ALL. That's it. Am I pretty safe,
uh, if you start sshd as standalone (not via inetd) it isn't protected by tcpd.
But it seems that in recent versions of sshd which is shipped on Suse's CD's that libwrap support is linked in, so far sshd itself consults /etc/hosts.allow and/or /etc/hosts.deny and decides if he should be called from a given IP adress.
Or am I wrong ?
No, you are right. Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
Hi
Thomas Biege wrote:
....
Also, everything is deactivated in /etc/inetd.conf. /etc/hosts.deny is set to ALL: ALL and /etc/hosts.allow is set to sshd: ALL. That's it. Am I pretty safe,
uh, if you start sshd as standalone (not via inetd) it isn't protected by tcpd.
But it seems that in recent versions of sshd which is shipped on Suse's CD's that libwrap support is linked in, so far sshd itself consults /etc/hosts.allow and/or /etc/hosts.deny and decides if he should be called from a given IP adress.
Or am I wrong ?
This is definitely correct.
I think we need to add a small patch to the ssh package that gives a new
tcp-wrapper token: sshdfwd-all. The problem with the libwrap is that you
can't reject everything (hosts.deny: ALL : ALL) without adding a rule for
each port that you want to have forwarded by sshd. This may look like:
sshdfwd-X11: ALL : ALLOW
sshd: ALL : ALLOW
sshdfwd-1000: ALL : ALLOW
sshdfwd-443: ALL : ALLOW
There is no general directive like sshdfwd-all.
Anyway, just a small thing. There are more important issues...
Thanks,
Roman.
--
- -
| Roman Drahtmüller
participants (6)
-
Gerd Bitzer -
Hubert Mantel -
Jason P. Stanford -
Kurt Seifried -
Roman Drahtmueller -
Thomas Biege