Re: Block certain remote hosts on submission port
On 22 Aug 2013, at 21:28 , Stan Hoeppner s...@hardwarefreak.com wrote: ~$ wget http://ipdeny.com/ipblocks/data/countries/us.zone ~$ sed 's/$/ OK/g' us.zone us.cidr ~$ cp us.cidr /etc/postfix ~$ postfix reload and you're off to the races. Interesting idea. I'm in much the same boat. Although I do have international users, they all use webmail to access mail, so I'm interested in trying this. A couple of questions: 1) I wouldn't think that CIDR list changes very often, but how often should it be refreshed? 2) If I did this I also would like to log these rejections to a separate file, possible? Under 2.10, would it make sense to put those restriction in the smtpd_relay_restrictions if port 25 is open for connections? -- Rosa sat, so Martin could walk. Martin walked, so Obama could run. Obama ran, so our children can fly. (paraphrased from NPR)
Re: Block certain remote hosts on submission port
On 8/24/2013 1:18 PM, LuKreme wrote: On 22 Aug 2013, at 21:28 , Stan Hoeppner s...@hardwarefreak.com wrote: ~$ wget http://ipdeny.com/ipblocks/data/countries/us.zone ~$ sed 's/$/ OK/g' us.zone us.cidr ~$ cp us.cidr /etc/postfix ~$ postfix reload and you're off to the races. Interesting idea. I'm in much the same boat. Although I do have international users, they all use webmail to access mail, so I'm interested in trying this. A couple of questions: 1) I wouldn't think that CIDR list changes very often, but how often should it be refreshed? How often does APNIC reassign, for example, a /22 from an entity in Vietnam to one in Japan, if ever? I don't have the answer to that. But this is the only type of situation that would prompt you to refresh, now that all IPv4 space has been allocated to the RIRs. We now know every IP by region, but what country it is assigned in may or may not change in future. And BTW, it's better to do this at the firewall if at all practical. 2) If I did this I also would like to log these rejections to a separate file, possible? Not directly. You'd specify a custom reject code then parse your mail log for that, pipe to another file. If you do it at the firewall it would depend on the firewall's features. Under 2.10, would it make sense to put those restriction in the smtpd_relay_restrictions if port 25 is open for connections? In the other half of the instructions I gave, which you cut, I show that this needs to be done in master.cf. smtpd_foo_restrictions in main.cf are global. You want this restriction only on the submission port, not the public smtp port. -- Stan
Re: Block certain remote hosts on submission port
On 8/24/2013 3:52 PM, Stan Hoeppner wrote: On 8/24/2013 1:18 PM, LuKreme wrote: On 22 Aug 2013, at 21:28 , Stan Hoeppner s...@hardwarefreak.com wrote: ~$ wget http://ipdeny.com/ipblocks/data/countries/us.zone ~$ sed 's/$/ OK/g' us.zone us.cidr ~$ cp us.cidr /etc/postfix ~$ postfix reload and you're off to the races. ... And BTW, it's better to do this at the firewall if at all practical. If you do the reject in postfix you'll be able to see the sender details, which may be valuable for seeing which accounts have been compromised and/or troubleshooting false positive reports. All the firewall can show is some IP was blocked. 2) If I did this I also would like to log these rejections to a separate file, possible? Not directly. You'd specify a custom reject code then parse your mail log for that, pipe to another file. If you do it at the firewall it would depend on the firewall's features. You can append a wildcard reject AT THE END of the cidr file with a custom message. That message will be sent to the client and will be included in your log. # us cidr table ... everything else 0.0.0.0/0 REJECT submission not allowed from your location geoip Under 2.10, would it make sense to put those restriction in the smtpd_relay_restrictions if port 25 is open for connections? In the other half of the instructions I gave, which you cut, I show that this needs to be done in master.cf. smtpd_foo_restrictions in main.cf are global. You want this restriction only on the submission port, not the public smtp port. Yes indeed. -- Noel Jones
Re: Block certain remote hosts on submission port
On 08/22/2013 01:51 PM, Charles Marcus wrote: [snip] The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? [snip] Hi, Sometimes it seems like a good solution to filter out all countries but your own. In fact it's not a good idea at all IMO. People do travel and they need to read and write email while they are abroad. Laptop and/or smartphone users will not like your new restriction policy when they try to get some work done while visiting a partner company in Germany. Use fail2ban as suggested by others. Mikael
Re: Block certain remote hosts on submission port
On 08/23/2013 12:47 PM, Mikael Bak wrote: [snip] In fact it's not a good idea at all IMO. People do travel and they need to read and write email while they are abroad. Laptop and/or smartphone users will not like your new restriction policy when they try to get some work done while visiting a partner company in Germany. Unless they fire up a VPN and still be able to send their email. Regards, Patrick
Re: Block certain remote hosts on submission port
On 22 Aug 2013 13:52, Charles Marcus cmar...@media-brokers.com wrote: Hi all, This isn't about spam, this is about blocking obvious attempts to hack/connect to my submission port. I know and understand the argument against just blanket blocking hosts based on the country of origin, but I've recently been seeing random connections on my submission port from hosts @ .ru and .cn domains. The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? I'd also like to be able to whitelist certain domains, in the rare case where someone might be on vacation abroad, and when they call me complaining that they cannot send email, I can see the country they are in my reject logs and whitelist that country temporarily. Surely the simplest solution is fail2ban with the false attempts in x minutes resulting in a 20 minute ban? This works for me... Otherwise you'd get more flexibility at the firewall level for geoip ranges.. Simon
Re: Block certain remote hosts on submission port
On 2013-08-22 8:03 AM, Simon B simon.buongio...@gmail.com wrote: Surely the simplest solution is fail2ban with the false attempts in x minutes resulting in a 20 minute ban? No for two reasons... 1. Again, we have ZERO users who are outside the US, so why allow connections at all? and 2. I am not currently seeing massive hack/crack attempts from the same IP, just random connections from lots of different IP's. Otherwise you'd get more flexibility at the firewall level for geoip ranges.. Actually, yeah, that is probably a better way to do this anyway, seeing as we don't need to allow users from anywhere else to connect... Now to figure out how to log these firewall rejections to a separate log file, so I can see them if/when someone complains about not being able to connect. Thanks Simon. -- Best regards, */Charles/*
Re: Block certain remote hosts on submission port
Am 22.08.2013 14:23, schrieb Charles Marcus: Now to figure out how to log these firewall rejections to a separate log file, so I can see them if/when someone complains about not being able to connect nothing easier than that * the first rule logs with rate-control to avoid self-DOS * the second one rejects * the same works for any iptables rule (log-line excatly like the other rule, different action) iptables -A INPUT -p tcp --dport 587 -s source-range/ip -m conntrack --ctstate NEW -m limit --limit 1/m -j LOG --log-level debug --log-prefix Firewall: iptables -A INPUT -p tcp --dport 587 -s source-range/ip -m conntrack --ctstate NEW -j REJECT --reject-with icmp-admin-prohibited ___ rsyslog.conf *before* all other rules :msg, contains, Firewall -/var/log/firewall.log ~
Re: Block certain remote hosts on submission port
On 8/22/2013 6:51 AM, Charles Marcus wrote: The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? Use the us.zone ipdeny file to build a CIDR table to accept any US client IPs and reject everything else. http://ipdeny.com/ipblocks/data/countries/us.zone But not now as it's currently broken. Already notified the OPs. Not sure how this happened. This is a big deal as automated systems rely on this data. I'd think it'll be fixed today, within hours. Anyway, your solution should be as simple as something like this: submission inet n - - - - smtpd ... -o smtpd_client_restrictions=check_client_access\ /etc/postfix/us.cidr, reject You could do the reverse and reject the rest of the world with your table, however building an maintaining that CIDR file is a massive PITA. If you have personnel traveling in other countries they use a VPN client to get into your network. That's what roaming VPN clients are for. You can setup a FLOSS VPN server for no cost but your labor/learning curve. Or simply enable/configure it on your edge router if it has VPN capability. -- Stan
Re: Block certain remote hosts on submission port
On 8/22/2013 9:57 AM, Stan Hoeppner wrote: On 8/22/2013 6:51 AM, Charles Marcus wrote: The simple fact is, we do not have any users based *anywhere* but the US, so, is what is the simplest way to block any/all non-US based client connections on my submission port? Use the us.zone ipdeny file to build a CIDR table to accept any US client IPs and reject everything else. http://ipdeny.com/ipblocks/data/countries/us.zone But not now as it's currently broken. It's fixed now. Anyway, your solution should be as simple as something like this: submission inet n - - - - smtpd ... -o smtpd_client_restrictions=check_client_access\ /etc/postfix/us.cidr, reject After you modify master.cf as above, do ~$ wget http://ipdeny.com/ipblocks/data/countries/us.zone ~$ sed 's/$/ OK/g' us.zone us.cidr ~$ cp us.cidr /etc/postfix ~$ postfix reload and you're off to the races. -- Stan
