Issue with hosts.deny - Unix

This is a discussion on Issue with hosts.deny - Unix ; Hi all, I administer my remote server (Ubuntu 8.04.1 server) with ssh. For some reasons, I am not able to log in my remote server anymore with my computer at work while I am still able to log in with ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Issue with hosts.deny

  1. Issue with hosts.deny

    Hi all,

    I administer my remote server (Ubuntu 8.04.1 server) with ssh. For
    some reasons, I am not able to log in my remote server anymore with my
    computer at work while I am still able to log in with my computer at
    home.

    The error message "sshd[4283]: refused connect from XXX.XXX.XXX.XXX"
    is logged in /var/log/auth.log

    I found out that the IP address of my work computer is logged in /etc/
    hosts.deny. This explains why I am not able to log in with my work
    computer anymore. However, when I delete this entry, it is logged back
    few seconds after having save the file for some reasons I don't
    understand.

    fail2ban is running on my remote server but it does not seem to
    interfere with the /etc/hosts.deny file. I emptied the /var/log/
    auth.log file as fail2ban parses the log to ban clients but it did not
    manage to solve my issue and the IP address of my work computer still
    gets logged in /etc/hosts.deny.

    Many thanks for your help
    Antonin

  2. Re: Issue with hosts.deny

    Antonin wrote:
    > Hi all,
    >
    > I administer my remote server (Ubuntu 8.04.1 server) with ssh. For
    > some reasons, I am not able to log in my remote server anymore with my
    > computer at work while I am still able to log in with my computer at
    > home.
    >
    > The error message "sshd[4283]: refused connect from XXX.XXX.XXX.XXX"
    > is logged in /var/log/auth.log
    >
    > I found out that the IP address of my work computer is logged in /etc/
    > hosts.deny. This explains why I am not able to log in with my work
    > computer anymore. However, when I delete this entry, it is logged back
    > few seconds after having save the file for some reasons I don't
    > understand.


    If you put the work computer address in /etc/hosts.allow it should work
    (AFAIK.)



    John
    --
    Perl isn't a toolbox, but a small machine shop where you
    can special-order certain sorts of tools at low cost and
    in short order. -- Larry Wall

  3. Re: Issue with hosts.deny

    On Sep 22, 8:57*pm, "John W. Krahn" wrote:
    > Antonin wrote:
    > > Hi all,

    >
    > > I administer my remote server (Ubuntu 8.04.1 server) with ssh. For
    > > some reasons, I am not able to log in my remote server anymore with my
    > > computer at work while I am still able to log in with my computer at
    > > home.

    >
    > > The error message "sshd[4283]: refused connect from XXX.XXX.XXX.XXX"
    > > is logged in /var/log/auth.log

    >
    > > I found out that the IP address of my work computer is logged in /etc/
    > > hosts.deny. This explains why I am not able to log in with my work
    > > computer anymore. However, when I delete this entry, it is logged back
    > > few seconds after having save the file for some reasons I don't
    > > understand.

    >
    > If you put the work computer address in /etc/hosts.allow it should work
    > (AFAIK.)
    >
    > John
    > --
    > Perl isn't a toolbox, but a small machine shop where you
    > can special-order certain sorts of tools at low cost and
    > in short order. * * * * * * * * * * * * * *--Larry Wall


    This should work yes, but I cannot figure out why the IP address of my
    work computer does not stop to get logged in /etc/hosts.deny right
    after I removed the entry from the file.

    I've even tried to totally empty the /etc/hosts.deny file. Few seconds
    after I saved the file, all the previous entries I had removed were
    logged back in the file.

    Are there some services that monitor / update the file /etc/hosts.deny
    periodically and that could cause to override my changes ?

    Many thanks
    Antonin

  4. Re: Issue with hosts.deny

    On Mon, 22 Sep 2008, in the Usenet newsgroup comp.unix.admin, in article
    <464f9ad4-d633-415d-b8e1-57b1855a36a0@m44g2000hsc.googlegroups.com>, Antonin
    wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.

    >I found out that the IP address of my work computer is logged in
    >/etc/hosts.deny. This explains why I am not able to log in with my
    >work computer anymore.


    You may want to study 'man 5 hosts_access' and compare the concept
    of "mostly open" verses "mostly closed". The world has changed a bit
    since Wietse Venema released the last version in 1997.

    > However, when I delete this entry, it is logged back few seconds
    >after having save the file for some reasons I don't understand.


    You are running a "Let me help you shoot yourself in the foot" tool,
    and the thing is misconfigured.

    >fail2ban is running on my remote server but it does not seem to
    >interfere with the /etc/hosts.deny file.


    Well, what OTHER "let me shoot you in your foot" software are you
    running? There are others like 'denyhost', 'BlockHosts' 'PortSentry'
    and 'bruteforceblocker' that will do the same thing.

    >I emptied the /var/log/auth.log file as fail2ban parses the log to ban
    >clients but it did not manage to solve my issue and the IP address of
    >my work computer still gets logged in /etc/hosts.deny.


    What you've probably done is set 'fail2ban' to permanently ban any
    address it decides is "attacking" you, AND you had somehow had a
    problem connecting from work (wrong password or similar) or someone
    spoofed your work address, and BINGO you discovered how these tools are
    so easily used to perform a Self-Denial-Of-Service attack.

    Go look at the "documentation" for 'fail2ban' - looking specifically at
    the "time" that a host will be banned. Perhaps the 'debug' output will
    show this - you're looking for "jails" with a time less than zero.
    This so-called helper interprets that to mean permanent blocking.

    If you really think you need this dangerous tool, you'd best study
    the documentation more. What many people do INSTEAD of using things
    designed to help you attack yourself is to set up your firewall such
    that it _allows_ connections from (either) specific addresses, or
    address ranges where you know you should allow connections - and
    block all other by default. As of last week, there were 2708817080
    IPv4 addresses in use on 88156 networks in the world. You can ban
    them one at a time (that ought to slow your system to a crawl) or
    you can block most (except for the ones you expect to use). My
    firewall at home allows SSH in to my network from just 1530 "outside"
    addresses (a /22 and two /24s) rather than all 4.3 trillion possible
    IPv4 addresses. Setting the SSH server to use only RSA hashes (as
    opposed to username and password) also reduces the need for these
    dangerous tools.

    Most of these Self-Denial-Of-Service tools know they are prone to
    configuration errors, and can be set to "never block this address".
    You can set that for your home and office IPs, or wait until someone
    spoofs an attack from those addresses, and locks you out.

    Old guy

+ Reply to Thread