LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   hosts.allow/deny questions (http://www.linuxquestions.org/questions/linux-security-4/hosts-allow-deny-questions-532878/)

kkjensen 02-27-2007 07:53 AM

hosts.allow/deny questions
 
Hi there,

I've been reading up on securing ssh a little more (our server at work was hacked since a machine somewhere on the shared network had a trojan so now I've got to secure the machine better). I have read this post: http://www.linuxquestions.org/questi...=340366&page=3 and it contains mostly scripts and things to actively lock things up. I have some general questions about the hosts.allow and hosts.deny files.

I thought I had the format of hosts.deny right (from following the thread I mentioned) by using the following:
Quote:

#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!

sshd: .cn, .cn.net, .cn.com, .jp, .jp.com, .net
shd: UNKNOWN
but it would seem that something isn't right since /var/log/messages contains the following
Quote:

Feb 26 15:06:32 rhserver sshd(pam_unix)[20600]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=213.41.120.35
Feb 26 15:06:35 rhserver sshd: warning: /etc/hosts.deny, line 10: can't verify hostname: getaddrinfo(hosting-35.120.rev.fr.colt.net, AF_INET) failed
Feb 26 15:06:35 rhserver sshd(pam_unix)[20602]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=213.41.120.35 user=root
Feb 26 15:06:38 rhserver sshd: warning: /etc/hosts.deny, line 10: can't verify hostname: getaddrinfo(hosting-35.120.rev.fr.colt.net, AF_INET) failed
Feb 26 15:06:39 rhserver sshd(pam_unix)[20604]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=213.41.120.35 user=guest
Feb 26 15:06:41 rhserver sshd: warning: /etc/hosts.deny, line 10: can't verify hostname: getaddrinfo(hosting-35.120.rev.fr.colt.net, AF_INET) failed
Feb 26 15:06:42 rhserver sshd(pam_unix)[20606]: check pass; user unknown
Feb 26 15:06:42 rhserver sshd(pam_unix)[20606]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=213.41.120.35
Feb 26 15:06:44 rhserver sshd: warning: /etc/hosts.deny, line 10: can't verify hostname: getaddrinfo(hosting-35.120.rev.fr.colt.net, AF_INET) failed
What did I miss to have it not deny the attempt alltogether?

Ultimately I'd like to ONLY consider local network connections from 192.168.5.0/24 and from the "dynamic" but never changing ip address that my router at home. Every attempt I've made at putting these into the hosts.allow file has ended up with a lot of lines in /var/log/messages about missing colons and such. If someone could give me an example of how I should put these into the file, it would be greatly appreciated.

thanks in advance...

live_dont_exist 02-27-2007 08:46 AM

Hey kkJensen,
Got this straight off google...;) .. try this out.

Code:

sshd: 10.0.0.0/255.0.0.0, isp.dial.up.pool/255.255.255.0
You might want to try a couple of iptables rules if you're interested to allow specific connections.

Also you might want to eventually look at the AllowUsers and AllowGroups parameters in sshd_config.

Cheers
Arvind

yawe_frek 02-27-2007 09:53 AM

i advice you deploy a firewall using iptables

Capt_Caveman 02-27-2007 09:16 PM

In hosts.deny:
Code:

SSHD: ALL
In hosts.allow:
Code:

SSHD: 192.168.5.0/24 hostname.isp.net
So your setup would basically be "that which isn't specifically allowed in host.allow is implicitly denied"

kkjensen 02-28-2007 07:32 AM

Thanks for the replies everyone.

Yes, I'm also reading up on iptables...I've had some recommendations to use webmin and shorewall...so I've got my reading to do on them. I've got both installed on a test machine and I can configure shorewall via webmin but it's the shorewall details that I've got to learn. This is a thread for another day...
Quote:

In hosts.deny:
Code:

SSHD: ALL


In hosts.allow:
Code:

SSHD: 192.168.5.0/24 hostname.isp.net


So your setup would basically be "that which isn't specifically allowed in host.allow is implicitly denied"
...this is what I want to do. Thanks. [edit] how to I find a hostname (for "hostname.isp.net") if it's just a simple USR wireless router? I guess if it's always turned on and the ip address doesn't renew that I can just use an ip address...[/edit]

I'll also be looking into the allowusers and allowgroups to see if I can get it working with my users....aside from root the only users on the machine are imported with getent from a windows domain. Trying to log in with there uses is always denied and I eventually want the root to only be able to log in locally.

Thanks for the help everyone!

Capt_Caveman 02-28-2007 07:49 AM

With SSHD you should absolutely never allow remote root logins. It's very easy to turn off and I would highly recommend doing so.

In the sshd config file (usually /etc/ssh/sshd_config), set the PermitRootLogin parameter to "no" and make sure that it is uncommented. Then just login as a normal user and use su - for root access.

kkjensen 02-28-2007 10:56 AM

I think I'll have to add a couple non-ads users for maintenance and give them ssh login access. About a week ago we found out the hard way that there's a backdoor onto our network (we share an internet connection with 2 other companies in the building) and someone has a trojan or something, somewhere that is allowing people onto the network. Over the weekend someone brute-forced their way into the root account, added a couple users, dropped off a script and set it up to deny local logins...come monday we were in trouble. Luckily /home and all our data was on different drives so it didn't take long to wipe and start over but it's pretty annoying to feel powerless when stuff is going on. For now I've shut down ssh completely until I get a chance to make all the necessary changes.

This is a file server, connected to and ads domain and has encrypted passwords enabled....I suppose if someone can make it this far they can brute-force their way through a samba password too? For samba I DEFINATELY only want local network access. Let me guess:

add to /etc/hosts.deny
Code:

smb: ALL
and add to /etc/hosts.allow
Code:

smb: 192.168.5.0/24
Correct?

Capt_Caveman 02-28-2007 09:00 PM

Quote:

Originally Posted by kkjensen
Over the weekend someone brute-forced their way into the root account, added a couple users, dropped off a script and set it up to deny local logins...come monday we were in trouble.

I hope that you've reset any passwords that were shared with other machines.

Quote:

Luckily /home and all our data was on different drives so it didn't take long to wipe and start over but it's pretty annoying to feel powerless when stuff is going on.
Make sure that you've scanned it with some kind of AV to be (relatively) sure that is clean of malware.

Quote:

I suppose if someone can make it this far they can brute-force their way through a samba password too? For samba I DEFINATELY only want local network access.
Definitely, there are a number of SMB bruteforcing tools that work like Hydra, plus in general SMB isn't really designed to be a hardened internet-facing service.

Quote:

Let me guess:
add to /etc/hosts.deny
smb: ALL
and add to /etc/hosts.allow
smb: 192.168.5.0/24
Correct?
I believe it would technically be smbd, but offhand I'm not sure whether Samba has built-in support for tcp_wrappers (aka /etc/hosts.allow/deny). That's a real gotcha with using tcp wrappers where you need to be careful. Not all applications have support built-in, so not all applications can be protected by putting entries in hosts.allow. Of course you won't get any errors as the file is parsed which can leave you falsely believing you're secure. To check, run the following as root:
Code:

ldd /path/to/smbd | grep libwrap.so
If that doesn't produce any output, then look at /etc/xinetd.d and /etc/xinetd.conf for smbd entries. If there aren't any, then likely it doesn't support tcp_wrappers.

anomie 02-28-2007 09:14 PM

I'll concur with some of the others; tcp_wrappers is a very handy mechanism, but it would be better to filter traffic to these ports using iptables (particularly when you are doing this for numerous services, some of which may not have tcp_wrappers support built in).

That way you don't show up on portscans and you block access attempts at the netfilter level. (Yes, in practice the two methods will probably achieve the same results, but that's my opinion.)

kkjensen 03-01-2007 09:06 AM

I know about clamav...but have never done a full system scan with it or anything. I haven't installed it on this machine yet.

Like I said, I want to do iptables but have my other hat that I wear in the office that I need to wear most of the time. I have been setting up a machine with 2nic cards and am hoping to place it between our network switch and the other switches/router that make up the infrastructure of the building. This way I'm sure that our network is our problem and shouldn't have to deal with whatever implicit/explicit weaknesses the other companies have in their setups.

Could anyone suggest a newbie friendly distro for a router box, preferably something with a good web gui to get things going quickly? I've heard of ipcop and a couple others. This router box of ours, it's a 1Ghz xeon w/ 512MB RAM and I'd like to have a total 3nics. One for our network, one going to the building infrastructure and possibly a third going to the dmz of the building router...my boss has asked if I could set something up to allow our offsite employees to get access to our scalix calendering/email server and to ftp files...we can be many timezones apart and phoning someone to email something isn't always an option. Anyway, I've got some reading to do...

Capt_Caveman 03-03-2007 09:12 PM

IPCop and Smoothwall are 2 of the more popular "router-in-box" type distros and are pretty easy to get up and working if you have a fairly standard network structure and don't need to do complex filtering/NAT (GUIs tend to choke when it comes to the more complex iptables functions). I'd highly recommend installing it on a test network first and getting comfortable with it before deploying it live.

Most other distros usually offer a stripped-down install option that leaves off most of the non-necessary software packages and is suitable for deploying as a router/firewall as well. If you have any questions about getting a iptables firewall written, feel free to post a new thread.


All times are GMT -5. The time now is 03:39 AM.