hosts.deny ; ALL : ALL restrictions

fbeye · 08-16-2017, 12:08 PM

Good Morning

Currently I am not utilizing the hosts.dent/allow files but am using fail2ban / iptables combination. The only service I am running would be dovecot/postfix email.

I am the only person who has an account for emails or even the system at all so I was thinking, instead of my rc.firewall list adding 20-50 IPs a day to ban for malicious / brute force attempts can't I just utilize hosts.deny ALL :ALL and add my static ip that I use to be the only person allowed in, whatsoever?

But then I began thinking... when someone, anyone, sends me a legitimate email from various random email addresses (friends, family or business related) will hosts.deny block those touchdowns from the email coming in or does hosts.deny just block actual Connection attempts opposed to the somewhat "relay" connection that an incoming email uses?

I did what I could on researching and really did not find an answer to what I was questioning... quite possibly because I didn't know exactly how to inquire correctly.

Thanks

Turbocapitalist · 08-17-2017, 06:10 AM

If you're want only yes/no decisions about access, then iptables would be the way to go. Fewer and fewer daemons still support tcpwrappers (tcpd) anyway. If I recall correctly it pre-dates even the ipchains filter, and that has been since replaced with iptables. tcpd did have some extra features but it sounds like you are not using them. So I would recommend just whitelisting your machines in ipatbles.

fbeye · 08-18-2017, 04:52 PM

Quote:

Originally Posted by Turbocapitalist

If you're want only yes/no decisions about access, then iptables would be the way to go. Fewer and fewer daemons still support tcpwrappers (tcpd) anyway. If I recall correctly it pre-dates even the ipchains filter, and that has been since replaced with iptables. tcpd did have some extra features but it sounds like you are not using them. So I would recommend just whitelisting your machines in ipatbles.

Ahhh I get what you are suggesting. Block all incoming except the ip I choose and then no more to be done.
Boy, I was not thinking Big enough

This then raises again my other question... when blocking ALL IP's from incoming except mine, am i still able to receive incoming email from the Internet? I am not knowing if incoming emails would be considered as connection attempts or even failed attempts to the server and be rejected as such. As far as then adding specific ports to allowing incoming connections based on server type (email) if that would put me back to square one as I would be getting attached over again.

Habitual · 08-18-2017, 06:25 PM

tcpwrappers A.K.A. /etc/hosts.{allow,deny}
is only valid if openssh-server is < 6.7

Maybe things have changed but I don't think so.

Code:

ssh -V

will show you some details. look for the first entry.

So, if you have openssh-server equal to or greateer than 6.7
/etc/hosts.{allow,deny} won't even be enforced. AFAIK.
But, AFAIK, you can use a "patch" or hook into xinet{d,.d} (IDK, it's been a few).

Pivot to Turbocapitalist

Code:

man hosts_access
man hosts.allow
man hosts.deny

on such a system would be the definitive source.

Fail2ban with ignoreip = <you>

Code:

maxretry = 1
bantime = 604800
findtime = 600

bantime value is a week in seconds

and port 25 has to stay open to receive mail.
Please let us know.

ufw or iptables. There's a few ways to restrict access, not sure tcpwrappers is suitable for your situation.

Turbocapitalist · 08-18-2017, 10:06 PM

Quote:

Originally Posted by fbeye

Ahhh I get what you are suggesting. Block all incoming except the ip I choose and then no more to be done.
Boy, I was not thinking Big enough

This then raises again my other question... when blocking ALL IP's from incoming except mine, am i still able to receive incoming email from the Internet? I am not knowing if incoming emails would be considered as connection attempts or even failed attempts to the server and be rejected as such. As far as then adding specific ports to allowing incoming connections based on server type (email) if that would put me back to square one as I would be getting attached over again.

You can use iptables to block based on direction (in/out), port number (for some protocols), protocol (TCP,UDP,ICMP), and IP address, or any combination of those. Some distros have a front end to iptables called UFW, but you can do everything with iptables-save and iptables-restore. There's also a package iptables-persistent which makes it easy to save rules.

When changing iptables rules, don't lock yourself out. Use iptables-apply to safely test your rules or else use an at job to restore the last known-good set manually.

When first implementing new rules, set iptables to log blocked packets and then go through the logs before they get too big. Then you can adjust the filter as needed before something breaks. Then as things work, turn off logging of the filter.

Ok. With that out of the way, for incoming mail you'll need to allow incoming SSH (usually port 22) TCP to manage the system. For the actual mail you'll need to allow incoming SMTP (port 25) and SMTPS (port 465) if you are using it. Check to be sure. Then to read the mail you'll also need to allow incoming IMAPS (usually port 993) to be able to read your mail. Oh, and of course the incoming component of related/established connections as well.

Hopefully I have not missed anything there.

If it's a production server, and not going to be changing, and only doing mail you can later try to tighten down the outgoing connections but that is an adventure in itself.