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

security issue caught with shibby 121 - help

Discussion in 'Tomato Firmware' started by ghoffman, Jul 13, 2014.

  1. ghoffman

    ghoffman Addicted to LI Member

    i yesterday upgraded from victek 2014g to shibby 121 on my e4200v1. everything seems great, and back on tomatoanon again. lst evening i started getting these security threats in my logs:
    Jul 12 21:00:01 hoffman1 syslog.info root: -- MARK --
    Jul 12 22:00:01 hoffman1 syslog.info root: -- MARK --
    Jul 12 22:17:08 hoffman1 daemon.info dnsmasq-dhcp[1875]: DHCPREQUEST(br0) 192.168.1.162 10:9a:dd:a9:da:66
    Jul 12 22:17:08 hoffman1 daemon.info dnsmasq-dhcp[1875]: DHCPACK(br0) 192.168.1.162 10:9a:dd:a9:da:66 nrh-mba
    Jul 12 22:44:45 hoffman1 authpriv.info dropbear[5170]: Child connection from 61.144.43.235:50756
    Jul 12 22:44:47 hoffman1 authpriv.warn dropbear[5170]: Bad password attempt for 'root' from 61.144.43.235:50756
    Jul 12 22:44:47 hoffman1 authpriv.info dropbear[5170]: Exit before auth (user 'root', 1 fails): Disconnect received
    Jul 12 22:44:48 hoffman1 authpriv.info dropbear[5171]: Child connection from 61.144.43.235:51872
    Jul 12 22:44:49 hoffman1 authpriv.warn dropbear[5171]: Bad password attempt for 'root' from 61.144.43.235:51872
    Jul 12 22:44:50 hoffman1 authpriv.info dropbear[5171]: Exit before auth (user 'root', 1 fails): Disconnect received
    Jul 12 22:44:50 hoffman1 authpriv.info dropbear[5172]: Child connection from 61.144.43.235:52542
    Jul 12 22:44:52 hoffman1 authpriv.warn dropbear[5172]: Bad password attempt for 'root' from 61.144.43.235:52542
    Jul 12 22:44:52 hoffman1 authpriv.info dropbear[5172]: Exit before auth (user 'root', 1 fails): Disconnect received
    Jul 12 23:00:01 hoffman1 syslog.info root: -- MARK --
    Jul 12 23:11:00 hoffman1 authpriv.info dropbear[5369]: Child connection from 61.174.51.208:25801
    Jul 12 23:11:04 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:04 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:05 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:06 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:06 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:07 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:07 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:08 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:09 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:09 hoffman1 authpriv.warn dropbear[5369]: Bad password attempt for 'root' from 61.174.51.208:25801
    Jul 12 23:11:10 hoffman1 authpriv.info dropbear[5369]: Exit before auth (user 'root', 10 fails): Max auth tries reached - user 'root' from 61.174.51.208:25801
    Jul 12 23:11:10 hoffman1 authpriv.info dropbear[5370]: Child connection from 61.174.51.208:28243
    Jul 12 23:11:13 hoffman1 authpriv.warn dropbear[5370]: Bad password attempt for 'root' from 61.174.51.208:28243
    Jul 12 23:11:14 hoffman1 authpriv.warn dropbear[5370]: Bad password attempt for 'root' from 61.174.51.208:28243
    Jul 12 23:11:15 hoffman1 authpriv.warn dropbear[5370]: Bad password attempt for 'root' from 61.174.51.208:28243

    these threats have contninued all night.
    is there a possible way to hack into tomatoanon to get ip addresses of tomato routers?
    how to i report 61.174.51.208 as abusive?
     
  2. kthaddock

    kthaddock Network Guru Member

    That is quite common port scan nothing to worry about. Do you use SSH and with password or key login?
    If you use key you have nothing to worry about. That scan comes from China.
    Maby you can turn on:
    Limit Connection Attempts SSH / Telnet
     
  3. ghoffman

    ghoffman Addicted to LI Member

    kthadock - thank you. what is weird is that i have not had portscanning attacks in a long while, and not while on victek. or is there a difference in what gets logged?
    yes i limit logins and i use ssh. is it safer to turn off telnet access completely?
     
  4. kthaddock

    kthaddock Network Guru Member

    Well there have been a puse with port scanning but have started again. I have 16 ip blocked in my blocking script.
    No need to turn off SSH if you use key to login it's safe enough. Isn't telenet only from LAN side?
    One thing to do is use another port that 22 - 23
     
  5. ghoffman

    ghoffman Addicted to LI Member

    intersting -there is no option to limit telnet to lan side. i thought it used to be there.
     
  6. koitsu

    koitsu Network Guru Member

    I'm not sure why telnet is even being discussed here (telnetd = telnet daemon) -- the "attacks" in question are all SSH (dropbear = SSH daemon). The stock behaviour of the firmware does not allow inbound TCP connections to port 23 (telnet).

    I've discussed this "problem" in the past (re: "attacks" from random IPs on the Internet; geographic region has little to do with it, though yes, a large number of scans come from the Asias including Russia and eastern European countries, but again that really has no relevance).

    The only way to deal with this 99.9% reliably is to make firewall rules that block connections to port 22 by default, and then add exceptions for IPs or networks which you commonly connect from.

    Another approach, which is in no way/shape/form foolproof, is to move the SSH daemon from port 22 to another port in the ephemeral range, ex. port 54718. Most scanners don't bother searching above port 1023, but nothing stops people from doing it, so keep that in mind. You can also do this by keeping the SSH daemon on port 22 (for LAN access, ex. machine 192.168.1.5 can still SSH to 192.168.1.1 on port 22, but when coming from an Internet IP you'd have to connect to WANIP port 54718) but redirecting connections coming to your WANIP:54718 to port 22. This cannot be done from the Port Forward GUI, and instead requires a pair of iptables rules (in this case it would be iptables -t nat -A WANPREROUTING -p tcp --dport 54718 -j DNAT --to-destination :22 and iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT)
     

Share This Page