Results 1 to 7 of 7
  1. #1

    Apache/Linux Security Question (/etc/hosts.allow)

    I have a few questions about security. Feel free to take a stab at them.

    I am trying to secure my RH 7.1/Apache 1.3.26 box from hackers. As far as security is concerned, I have found that more is better, of course.

    So, I am up late thinking about this issue. Here is what I am theorizing.

    1. It seems that a hacker/cracker requires shell access (telnet or SSH) in order to do their dasterdly deeds and without shell access, they cant do bad things from the inside. Is this correct?

    2. If this is correct, then a Linux/Apache server can be made quite secure by blocking all telnet and ssh access in /etc/hosts.deny and opening up ssh access only to known ISPs such as my own. Is this a good assumption?

    3. Thus, with tight control over /etc/hosts.deny and /etc/hosts.allow, hackers will have no ability to hack/crack a server. Yes or no?

    Your thoughts on these issues are welcome.

  2. #2
    Join Date
    Mar 2002
    No, a hacker can very much execute a deadly command through the address bar.

    ./etc/host.deny has nothing to do with apache. It's part of TCP_WRAPPER package. Denying access using host.deny and host.allow is just a small way to go. There are other methods you should do.

  3. #3
    Okay. Some commands can be executed through an address bar. But, serious hacking incidents, at least from my experience, have required the offender to access the machine, upload files to the machine, and then execute those programs.

    Thus, in that regard, tightening access via /etc/hosts.deny and /etc/hosts.allow should theoretically prevent these types of attacks. Am I wrong?

  4. #4
    Join Date
    Oct 2001
    san diego
    your better off with ipchains/iptables, you might want to get a good security book.

  5. #5
    wscreate, you're completely wrong.

    "serious hacking incidents" usually come from exploits in commonly running services on your server that will give you a shell prompt from which you are either have root access or can exploit further vulnerabilities to gain root access. To name a few in the recent past that carefully crafted data sent to common daemons running on your server can give you such access, that have nothing to do with hosts.deny/hosts.allow are:
    1. SSH (typically, not run through TCP Wrappers)
    2. Apache
    3. BIND (DNS Server)
    4. IMAP
    5. QPOPPER (POP3 Server)
    6. WuFTPd (if not running through TCP Wrappers)
    7. Proftpd (if not running through TCP Wrappers)
    8. A whole plethora of CGI Perl and PHP scripts

    To name but a few. If you're not running in some cases the latest, others a very recent version, of these products it would be trivial to hack into your server with, or to gain, root permissions, regardless of anything in your hosts.deny/hosts.allow files.

  6. #6
    I appreciate everyone's comments. It is very helpful.

    I am running SSH through tcp, which is a main concern as OpenSSH has exploits in older versions and seems to get new exploits as time goes on. Thus, in this regard, /etc/hosts.allow implementation and running SSH through tcp is a good thing. And, I think many hackers simply attempt to hack via shell access so tightening security here saves a lot of trouble for me.

    Now, I understand that other exploits are out there for FTP, Bind, Apache, etc. For those, it seems that being knowledgeable about new exploits and keeping them udpated to the latest versions is a good way to go. For example, I understand about the vulnerability in older versions of Apache and did install 1.3.26.

    Now, one thing that I am attempting to learn, and keep in mind, I am not a hacker and do not yet think like one, is how one can gain shell access via, say, an FTP exploit. Let me extrapolate...

    Say there is an FTP exploit, how does the hacker work the exploit to gain root access? I mean, if a hacker is going to do things on the server, they need shell access, right? Shell access, in my mind, is using an SSH program such as putty to interface to SSH via port 22. I understand that FTP, not run through TCP, does not obey the rules of /etc/hosts.allow, /etc/inetd.conf, etc. But, how does a hacker gain shell (or does he) thorugh this type of exploit. Does he manipulate the exploit to connect to a shell via FTP, thereby bypassing TCP and the /etc/hosts.allow file? Is that what happens?

    Forgive me for my lack of knowledge in this regard. I am not dumb, I just haven't yet learned these things. I am spending a lot of time reading and learning about web server security recently. WHT forum has been quite helpful.

    Thanks again to all.

  7. #7
    About TCP, and running sshd, imap, etc.....

    This is the contents of my /etc/inetd.conf file

    sshd stream tcp nowait root /usr/sbin/tcpd sshd
    talk dgram udp wait root /usr/sbin/tcpd in.talkd
    ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
    imap stream tcp nowait root /usr/sbin/tcpd imapd

    Are there any other programs which I can run through TCP in order to make it obey the /etc/hosts.allow and /etc/hosts.deny protocols?

    I think that FTP run through tcp would be cumbersome, since all customers on a shared server would require it to upload their site and thus, would require their ISP IP be listed in /etc/hosts.allow (A lot of work for me!)

    But, what about other common hacker targets that are not listed in my /etc/inetd.conf. Which ones can be run through tcp for security reasons, with consideration that this is a shared web server and needs fairly open access.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts