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?
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? ====================
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)
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.)
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?
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).
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.
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
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
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.
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.
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.
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.