Greetings,

I'm having problems with a user trying to ssh to one of my servers from his home DSL. As the ISP seems to assign random addresses to the user, I have added the line:

sshd : .verizon.net : allow

to the hosts.allow file to (I assumed) allow all connections from that domain. The user can connect sometimes, but not others (which I find most curious!) An example of a disallowed connection in my messages file is:

warning: /etc/hosts.allow, line 7: can't verify hostname: getaddrinfo(pool-68-238-143-94.sea.dsl-w.verizon.net, AF_INET) failed

So... why can the user connect sometimes, but not others from the verizon.net domain? Obviously DNS can't resolve the above address, but shouldn't the ".verizon.net" domain specification in the hosts.allow file allow for any connection from that domain?

I thought about using the AllowUsers variable in the sshd_config file, but that seems to me to be opening the machine up for more mischief.

Suggestions...?

Thanks in advance!

-l-

From the tcpd man page:

For some reason, the nslookup for the name doesn't match the nslookup for the ip or it is timing out.

HTH

Forrest

I spoke to another sysad about this and he said that the problem with with ISPs gaining blocks of addresses that are not registered with DNS. He suggested to get around my problem using iptables instead and tie to the MAC rather than the domain. I'll take a whack at it from that avenue.

Thanks,

-l-

MAC addresses don't get routed, hence they don't work on the Internet. They work with data link layer protocols, unlike IP (Internet Protocol) which works with the network layer. Using AllowUsers along with Fail2Ban (or something similar) would seem like a perfectly acceptable setup IMHO.

Exactly how random are the IP addresses? I'm guessing that they are probably fairly close in range. Adding:

sshd : 68.238.143. : allow

to your hosts.allow file would probably work for any IP your user would get as they are still going to access the same switch even if it assigns them a different IP. Look at your logs and see what IP's have been assigned in the past.

Or is this multiple users?

To open up the list to about a thousand possible hosts around the same IP use:

sshd : 68.238.140.1/255.255.252.0 : allow


HTH

Forrest

In running wireshark on the server, I noticed that the IP addresses were wildly different (i.e. 131.191.xxx.xx to 65.46.xxx.xxx) from the same mac. What was curious is that the mac didn't coincide with the end user's mac, the mac of her airport, nor the mac of her cablemodem. Not sure where the true connection point is, but iptables turned out the way to go in letting the user in. I set DROP as the default rule and added the line:

-A RH-Firewall-1-INPUT -p tcp --destination-port 22 -m mac --mac-source 00:1A:A6:CA:B7:10 -j ACCEPT


The servers now let in that machine without a hitch and drop other (uninvited) clients. What's really nice is that outside attackers now get no reply from the servers as their packets are dropped rather than rejected (as they were using hosts.allow.)

Thanks All!

-l-

Yes, as has been explained, MACs don't get routed (without special tools). It's not curious, it's expected.

What would be curious (perhaps even strange/weird) is if they did match.

If this is indeed an Internet setup, then your rule is bogus. Most likely it's the MAC of your router's LAN interface (it's definitely something on your LAN). Thus, the MAC match in the rule would be pointless, as it would be the same MAC which would show-up for anyone hitting that SSH daemon (or anything else on your box for that matter, when accessed via the WAN/Internet). When you look at iptables INPUT logs, the "MAC=" field's first six segments are the MAC of the interface the packet came into. The next six segments are the MAC of the LAN point which sent you the packet. With packets coming into your box from the Internet, these will always be the same (unless your router/modem is changed or whatever) - regardless of the source IP. Once again, just to be clear: MAC address filtering does not apply to packets coming from the Internet.

Here is the hardware vendor assigned to that mac address if it helps determine what it is:

00-1A-A6 (hex) Telefunken Radio Communication Systems GmbH &CO.KG
001AA6 (base 16) Telefunken Radio Communication Systems GmbH &CO.KG
Eberhard-Finckh-Strasse 55
Ulm Baden-Württemberg 89075
GERMANY

Also, win32sux, where did you get this info about the MAC info, I'd never heard that. I just figured that the mac was the mac of whatever router/switch the server was plugged into.

HTH

Forrest

"MAC address filtering does not apply to packets coming from the Internet."

Whelp, I can't argue with that! I feel a bit like Don Quioxote... I thought that cool trick worked... it was, indeed, the router's address (as I found when I still saw hoards of traffic coming through after my "magic fix".) 'Guess I should pay more attention to the bright folks here than to my local "expert" sources!

I'll take a whack at using the fail2ban solution and report back!

Thanks!

-l-

You have also put back into play the hosts.allow solution as the IP addresses you were seeing can now be known to be from any host that was attempting to contact your server, not just your users.