How do I filter out an IP address from connecting to my router & radio ssh port?

Looking at my ubiquiti airos log file of my rooftop wifi wisp radio, I see someone constantly trying to log into the ssh port of my static IP address.

I can log into my radio and view the log file to see the login attempts:

$ ssh -l admin radio_ip_address # tail -f /var/log/messages Dec 10 08:39:07 dropbear[2818]: login attempt for nonexistent user from ::ffff:59.53.94.9:35088 Dec 11 12:18:43 dropbear[3304]: login attempt for nonexistent user from ::ffff:59.53.94.9:42011 Dec 12 16:33:24 dropbear[5512]: login attempt for nonexistent user from ::ffff:59.53.94.9:24119 Dec 13 22:40:12 dropbear[7789]: login attempt for nonexistent user from ::ffff:59.53.94.9:22078

I can't change the ssh port because the wisp requires port 22 for air control software. I'm not too worried about the attack per se, but I'd sure like to simply send that IP address away. I tried setting a firewall static route to 0.0.0.0 but airos insists on requiring a gateway IP address:

Dec 15 06:26:32 route: add ip 59.53.94.9, netmask 255.255.255.255, gw 0.0.0.0, FAIL [error: 12]

Airos won't accept 0.0.0.0 or null as a gateway IP address.

Q: Is there a clever way to send a specific IP address into oblivion?

Reply to
Tony Palermo
Loading thread data ...

I can log into my radio and view the log file to see the login attempts:

$ ssh -l admin radio_ip_address # tail -f /var/log/messages Dec 10 08:39:07 dropbear[2818]: login attempt for nonexistent user from ::ffff:59.53.94.9:35088 Dec 11 12:18:43 dropbear[3304]: login attempt for nonexistent user from ::ffff:59.53.94.9:42011 Dec 12 16:33:24 dropbear[5512]: login attempt for nonexistent user from ::ffff:59.53.94.9:24119 Dec 13 22:40:12 dropbear[7789]: login attempt for nonexistent user from ::ffff:59.53.94.9:22078

I can't change the ssh port because the wisp requires port 22 for air control software. I'm not too worried about the attack per se, but I'd sure like to simply send that IP address away. I tried setting a firewall static route to 0.0.0.0 but airos insists on requiring a gateway IP address:

Dec 15 06:26:32 route: add ip 59.53.94.9, netmask 255.255.255.255, gw 0.0.0.0, FAIL [error: 12]

Airos won't accept 0.0.0.0 or null as a gateway IP address.

Q: Is there a clever way to send a specific IP address into oblivion? ====================

Block it in your firewall.

Reply to
D. Stussy

I'm not sure the settings as I've never set anything in a firewall.

How does this look?

FIREWALL SECTION OF RADIO: Enabled = [x] (choices are on or off) Target = [DROP] (choices are DROP or ACCEPT) Interface = [WLAN0] (choices are ANY, WLAN0, or BRIDGE0) IP Type = [TCP] (choices are IP, ICMP, TCP, UDP, or P2P) Source ! = [ ] (choices are on or off) Source IP/Mask = 59.53.94.9/32 (I'm not sure what mask to use???) Source ! = [ ] (choices are on or off) Source Port = [22] (choices are any number) Destination ! = [ ] (choices are on or off) Destination IP/Mask = 59.53.94.9/32 (I'm not sure what mask to use???) Destination ! = [ ] (choices are on or off) Destination Port = [22] (choices are any number)

Reply to
Tony Palermo

::ffff:59.53.94.9:35088

::ffff:59.53.94.9:42011

::ffff:59.53.94.9:24119

::ffff:59.53.94.9:22078

that IP address away.

requiring a gateway IP address:

FAIL [error: 12]

/etc/hosts.allow sshd: 59.53.94.9 :deny

sshd will check that address against that list and if it occurs, simply drop the connection.

I have a program which checks the /var/log/messages file for sshd bad connections and augment those lines in hosts.allow. (MUST be less than about 100 addresses on a line. There is a severe bug in tcpwrappers which Venema refuses to fix which puts tcpwrapper into an eternal loop if there are too many which uses 95% of cpu.)

Reply to
unruh

Create a static route to it via a non-existent IP address on the LAN and the responses will never get back to it.

Reply to
alexd

Now that is an interesting approach to dropping addresses on a radio!

On my Linux laptop, I use the /etc/hosts file extensively as per

formatting link

127.0.0.1 ad2.doubleclick.net #Drops all doubleclick ad content 127.0.0.1 ads.gameservers.com #Drops all gameservers ad content 127.0.0.1 affiliate.friendsearch.com #Drops all friendsearch ads etc.

On my Linux laptop, I have the following: $ ls /etc/host* /etc/hosts (contains 10K lines of hosts to ignore) /etc/hosts.allow (contains just template comments) /etc/hosts.deny (contains just template comments)

I never thought that the hosts file could be taken advantage on a rooftop wireless ISP radio.

On the radio, there are far fewer files in /etc/: $ ssh -l administrator radio_IP_address # ls /etc/host* /etc/hosts (contains 1 line: 127.0.0.1 localhost.localdomain localhost) /etc/host.conf (contains 2 default lines)

Do you think adding a hosts.allow on the Ubiquiti wi-fi radio will work?

Reply to
Tony Palermo

I had tried that but I wasn't sure how to set the "Gateway IP". How does this look to send the attempts to that static IP address?

  1. Log into the Ubiquiti AirOS radio using the browser interface https://radio_ip_address
  2. Open up the Network tab & click on "+Static Routes".
  3. Fill out the fields: a. Target Network IP = 59.53.94.9 b. Netmask = 255.255.255.255 c. Gateway IP = ?

Since my LAN is on the 192.168.0.1 subnet, are you suggesting I set the Gateway IP to something unused such as 192.168.0.254?

Reply to
Tony Palermo

127.0.0.1
Reply to
Allodoxaphobia

Yes.

I'm not certain that will have the desired effect - won't 127.0.0.1 just use it's default route?

Reply to
alexd

formatting link
networking-concepts-HOWTO.txt 18-Dec-2010 13:56 28K packet-filtering-HOWTO.txt 18-Dec-2010 13:56 51K

formatting link
45604 Oct 10 2008 Networking-Overview-HOWTO 278012 Oct 10 2008 Security-Quickstart-HOWTO 76194 Jan 5 2010 Unix-and-Internet-Fundamentals-HOWTO

Those are somewhat old Linux docs - read them for concepts and principles rather than exact instructions

I's probably go for "IP" which should include the others. But OK

As of last night, there were 3482353856 IP addresses assigned or allocated by the five Regional Internet Registries - are you going to try to block them one-by-one? A "whois" query of that address gives

inetnum: 59.52.0.0 - 59.55.255.255 netname: CHINANET-JX descr: CHINANET Jiangxi province network descr: China Telecom

If you have no expectation of you or your users connecting from Jiangxi province (450 miles/700 km NNE of Hong Kong), you might just block 59.52.0.0/14.

Your logs show (as expected) the source port numbers are "above" 1024. I'd leave this off.

You'd want to block connections _TO_ your system, and not worry about replies. If your system can't "hear" them guys, it won't answer.

Yes

COMMENT: As of last night, there were nearly 3 1/2 billion IPv4 addresses "out there" (and 14 x 10^33 IPv6 addresses). Do you have to allow access from all? Have you removed the locks on the doors of your house? If not, do you give keys to everyone in the world and only take back the keys from people you don't like/want to come in? A better solution is to only give keys to those you do want to come in. My home firewall allows access from just three outside networks (two /24s and a /22 - or a total of 1530 addresses). This would be something like

Target = [ACCEPT] Interface = [ANY] IP Type = [IP]

Source IP/Mask = 192.168.1.0/24

Source IP/Mask = 192.0.2.0/24

Source IP/Mask = 198.51.100.0/24

Source IP/Mask = 198.18.24.0/22

and ignoring/dropping any other connection attempts. Note that this does not prevent an "inside" host from initiating a connection to any address "outside" - it just prevents an "outside" host not in the desired address range from initiating a connection to "me". Note also that I don't bother specifying a port number, though I may narrow it down for the three "outside" IP ranges (but not the "inside" range).

Old guy

Reply to
Moe Trin

Well, you can put stuff in there if you want.

sshd is designed to make use of tcpwrapper. I do not know if dropbear is designed that way, so it may be that hosts.allow will not work. See if your system has the file libwrap.so* somewhere. And try it to see if dropbear uses libwrap.

that does not mean you cannot add files. It simply means that the distribution decided not to put certain files in there by default.

IF dropbear is designed to use tcpwrapper, it will work, if not it will not. I have never used dropbear so have no idea.

>
Reply to
unruh

Note that it's up to services to act on those entries, it's not a firewall rule.

This is for forward DNS lookups. Unless you want to stop yourself from being able to SSH to a specific host from your router, it won't be much use to you.

It certainly could be, but only applications that will act on it are those running on the router - hosts using your router as a gateway will not be affected.

At a guess, I would say no, ie it's not there as a template so probably isn't used. Can you find a libwrap anywhere on your router? Does

ldd `which sshd` | grep wrap

return anything?

Reply to
alexd

That's an intriguing idea!

I don't need ANY outside address connecting to me (other than my WISP who comes in with a private address anyway).

I wonder how I just block them all?

Reply to
Tony Palermo

From my Linux box, I log into the Ubiquiti rooftop radio: $ ssh -l administrator radio_ip_address # ldd `which sshd` | grep wrap SAYS: -sh: ldd: not found # which sshd SAYS: nothing # echo $PATH SAYS: /usr/bin:/bin:/usr/sbin:/sbin # cd / # find . -name sshd -print SAYS: nothing

Darn.

Reply to
Tony Palermo

In /etc/hosts.allow sshd: 192.168.0.0/16 :accept sshd: ALL: deny (or your own sshd daemon instead of sshd if you are using something else than sshd). Again, assumes it is using tcpwrappers.

The above accepts all connections in the address range 192.160.0.0 t0

192.168.255.255 and denys everything else. Note when you alter /etc/hosts.allow, always try loggin in from an outside machine that is supposed to be accepted BEFORE you log out of the connection that you used to edit /etc/hosts.allow to make sure that you can get back in. If not, you will be permanantly shut out. Above I assume by "private address" you meant something in the 192.168.x.x address range.
Reply to
unruh

Looking through dropbear source, it does not seem to support libwrap. However, if you are running it from xinetd, rather than as an eternally running daemon, then xinetd usually does support libwrap.

Reply to
unruh

You've got neither sshd nor ldd so the diagnostic I suggested won't work [note what unruh said about dropbear].

'find / | grep libwrap' might be more useful.

Reply to
alexd

$ ssh -l administrator radio XM.v5.5.2# cd / XM.v5.5.2# find . -name libwrap -print XM.v5.5.2# find / | grep libwrap

Both report nothing, unfortunately

Reply to
Tony Palermo

OK, so libwrap isn't there as a shared library, which means that anything that uses libwrap would have it statically linked, but this is an embedded system where disk space is at a premium, so from that I think we can conclude that nothing is using libwrap.

Reply to
alexd

Drat.

Reply to
Tony Palermo

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.