1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Max remote https login attempts: Is it possible?

Discussion in 'Tomato Firmware' started by asdfasdf, Dec 11, 2009.

  1. asdfasdf

    asdfasdf Addicted to LI Member

    I was wondering if there was a way to allow remote https login, but lock out for a short period of time after a couple of failed attempts. I know this can be done with ssh, but what about the web interface?

    Thanks
     
  2. anik

    anik Addicted to LI Member

    If no one come up with a better idea, Google fail2ban - it might do what you want.
     
  3. i1135t

    i1135t Network Guru Member

    Try pasting this into your firewall script and test it:
    Code:
    iptables -I INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 3600 --hitcount 5 --rttl --name HTTPS -j DROP
    iptables -I INPUT -p tcp --dport 443 -m state --state NEW -m recent --set --name HTTPS
    This should allow 5 attempts, then lock the hacker out for 1 hour.
     
  4. asdfasdf

    asdfasdf Addicted to LI Member

    Thanks for the ideas, can't believe I didn't think to just use iptables. Unfortunately I've never really had to mess with it, and the given script doesn't work. Remote access over https is enabled on port 443, and I can connect (remotely), but it never locks me out.
     
  5. i1135t

    i1135t Network Guru Member

    It should work, I would have to test it later when I get home though. Are you sure you pasted the code into your Admin --> Scripts --> Firewall section & save?
     
  6. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Since those are being added to the INPUT chain (after the port forward from external port to internal port), you'll either need to change the port number to the internal one (which will also limit the internal connections) or place the rules before the port forward.
     
  7. ntest7

    ntest7 Network Guru Member

    Also, this limits connections, not login attempts. You get several login attempts per connection (although I think most attack scripts use one connection per attempt).
     
  8. Planiwa

    Planiwa LI Guru Member

    So, it appears (from /etc/iptables) that the ssh rules are:

    Code:
    iptables -N shlimit
    iptables -A shlimit -m recent --set --name shlimit
    iptables -A shlimit -m recent --update --hitcount 3 --seconds 60 --name shlimit -j DROP
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
    
    wouldn't the equivalent https rules be?:

    Code:
    iptables -N htlimit
    iptables -A htlimit -m recent --set --name htlimit
    iptables -A htlimit -m recent --update --hitcount 3 --seconds 60 --name htlimit -j DROP
    iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j htlimit
    
     
  9. ntest7

    ntest7 Network Guru Member

    I think you'll need to use
    iptables -I INPUT ...
    rather than -A INPUT.

    Also, many web browsers make several parallel connections by default -- limiting them to 3 may cause odd behavior. Probably a limit of 5~10 is more reasonable.
     
  10. asdfasdf

    asdfasdf Addicted to LI Member

    No luck so far with anything posted here. :frown:
    (Yes, I'm adding it to the firewall scripting and saving changes before testing.)
     
  11. Planiwa

    Planiwa LI Guru Member

    Why is that?
    Does that mean that /etc/iptables is inaccurate?
    Or does it mean something else?

    This is quite true. As a matter of fact, as I have shown elsewhere, a single (refreshing) Tomato web page may generate dozens of concurrent connections, unless the Time_Wait timeout is reduced drastically from the default value of 120s.
     
  12. TurtleFang

    TurtleFang Addicted to LI Member

    I don't think that you can do it with iptables.

    I thought the same thing, and tried it out. Got it to "work", but also found out why it won't work.

    Here's the thing, rendering of webpages via port 443 (or whatever you are using) are not a single (tcp) connection. There are multiple object gets that are run in parallel in an attempt to make the page display as quickly as possible.

    Therefore, if you attempt to use iptables to limit the https login attempts the same way tomato limits ssh/telnet connections via "Limit Connection Attempts" under Administration -> Admin_Access in the menu, you will simply lock out on the X http get in Y seconds (3rd in 60 seconds is the default).

    And that's exactly what happened to me when I tried it out. I added https to the same rules applied to ssh and telnet connection limitations via the following comand...

    Code:
    iptables -I INPUT 8 -p tcp --dport https -m state --state NEW -j shlimit
    ... which inserted the https rule for shlimit right inline with the ones for ssh and telnet. Planiwa, why use "-I" instead of "-A"? You want to insert the new rule right inline with the ones for ssh and telnet, not append it at the end. Enter "iptables -h" or google/wikipedia iptables for more information.

    So I set it up then logged out of the web admin and then logged back in before trying the deny action. The page load started, but never completed as I get capped on the 3rd tcp connection that gets established while attempting to render the page.

    In summary, I don't think you can use iptables the same way you do for ssh and telnet to limit connection attempts.

    Hope this helps,
    -TurtleFang
     
  13. ntest7

    ntest7 Network Guru Member

    This "works"
    Code:
    iptables -N htlimit
    iptables -A htlimit -m recent --set --name htlimit
    iptables -A htlimit -m recent --update --hitcount 5 --seconds 60 --name htlimit -j DROP
    iptables -I INPUT -p tcp --dport 443 -m state --state NEW -j htlimit
    But remember -- this limits connections, not login attempts. With the web interface, you get numerous login attempts per connection. Still, this may provide some protection against attack scripts, which tend to make lots of connections.

    (Note setting hitcount to less than 5 may cause odd/slow behavior with browsers that make multiple connections; that's most browsers.)

    You can test that this is working by using tcping.

    For real login protection, you would need something like fail2ban.
     

Share This Page