ISPConfig 3.2.5 perfect server instructions have you disable firewall/iptables so it can install Bastille, but then fail2ban is installed, which uses iptables, i believe (that's where it's rules are ending up). am i seeing that wrong, or misreading something. also, if you enable iptables - all network traffic stops. I'm betting thats because no default firewall was configured. here's my iptables list after running for a few days, even though it was off (and 31.130.184.51 is repeatedly attempting logins, but isn't blocked from trying because iptables isn't running) Chain INPUT (policy ACCEPT) target prot opt source destination f2b-postfix-sasl tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain f2b-postfix-sasl (1 references) target prot opt source destination REJECT all -- 31.130.184.51 0.0.0.0/0 reject-with icmp-port-unreachable RETURN all -- 0.0.0.0/0 0.0.0.0/0 thanks for the clarification
Just install ufw and configure the firewall ports to allow in the ispconfig interface. All the tools use iptables as the underlying firewall interface. Bastille is quite dated and doesn't support ipv6. What you so above is that you have fail2ban active and no other firewall rules.
that's the default result (plus the f2b rules it added) from the perfect server centos installation. I'm not familiar with the Bastille firewall, or ufw, but if the rules shown in iptables are supposed to be used and active, they aren't. as of 1 minute ago, 31.130.184.51 is still getting through to the system. if I "rpm -qa | grep astille" i see no Bastille listed, so maybe it got missed, but the PS instructions say Bastille is preferred and included and configured by the the ISPConfig install script - the instructions have you purposefully disable iptables. any other way to find it to make sure Bastille's working correctly or configured correctly? not accusing, just relaying what I'm finding and trying to figure it out. thanks!
If that's the output of "iptables -L -n -v" then yes, they are. Fail2ban will remove those firewall rules after 10 minutes, so you would have to check again if it's still in effect. Also the rule that is setup only matches traffic for destination ports 25, 465 and 587, so any other type of traffic will still be allowed (I generally (always?) configure fail2ban to use a different action so that all traffic is blocked, not just traffic to a few ports). bastille is a (set of) shell script(s) that ships with ISPConfig (and used to be available as a separate package in the OS; I think it was removed years ago in debian, but I have no idea about centos), so not being installed as an rpm isn't a problem. As far as disabling "iptables," I checked one centos tutorial and it shows disabling the "default CentOS firewall" with no mention of disabling "iptables", I'd guess maybe you're using an older centos version, and there is a service called "iptables"? (Both the bastille firewall script and ufw (and surely the "default CentOS firewall") are interfaces to use the 'iptables' command to setup firewall rules, so could be some confusion on terminology). It looks like the bastille-netfilter script itself disables that service via chkconfig if it is detected, so you actually might be covered already on that. If you're following the tutorial and with to continue with Bastille, did you set that as the firewall type in server config and specify a list of ports to allow? According to your iptables output, it isn't configured/enabled, there are no firewall rules other than fail2ban's. No worries, but I will again advise to abandon Bastille and install ufw. It creates a more comprehensive firewall rule set, and includes ipv6 (if you use Bastille, do not enable ipv6, or you will have absolutely no firewall in place, even though it works for ipv4 rules).
Thank you for the response and information, but I'm still not getting something... https://www.howtoforge.com/tutorial...l-php-pureftpd-postfix-dovecot-and-ispconfig/ that's the tuturial I used/am using I used iptables directly and heavily on my last server (about 30,000 rules, maintained hourly - I was a brutal blocker of anyone that failed to login from the same IP more than 9 times, and would block complete Class C subnets after I blocked 10 IPs from one. I was processing 1,000s of unnecessary emails a day, and it was effective). it was old enough that fail2ban wasn't installable, so I was hoping it would handle that workload on this new server. So if I'm understanding this correctly, iptables is just being used as a database to hold firewall rules for other applications at this point - Bastille specifically, because the others appear to be disabled. And Bastille is being used as needed by ISPConfig, but is not actively monitoring traffic to block incoming traffic full time. And fail2ban is putting rules in there, but there's no active firewall so those rules aren't being implemeneted, so the offenders are still doing their thing. maybe I'm misunderstanding something. iptables is the actual firewall AND the rule keeper, correct? because in my experience, enabling iptables would block the traffic, and disabling it would let it through. AND it was what i used to create/remove the rules. Bastille is rule maker, and maybe it applies those rules when it is asked to, but it doesn't actively monitor and block traffic by default. and it appears ufw is a rule maker as well - it still requires iptables to be do the work. So my main question comes back to why is iptables never enabled in the Perfect Server instruction ? Whats doing the actual blocking of traffic? Is there anything doing the blocking that iptables indicates should be done? and why does email traffic grind to a halt when I enable iptables directly? here's it's current status on my server: systemctl status iptables.service iptables.service - IPv4 firewall with iptables Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; vendor preset: disabled) Active: inactive (dead) since Thu 2021-09-09 08:34:10 EDT; 2 days ago Main PID: 1080 (code=exited, status=0/SUCCESS) Sep 08 17:35:41 my.server.com systemd[1]: Starting IPv4 firewall with iptables... Sep 08 17:35:45 my.server.com iptables.init[1080]: iptables: Applying firewall rules: [ OK ] Sep 08 17:35:47 my.server.com systemd[1]: Started IPv4 firewall with iptables. Sep 09 08:34:10 my.server.com systemd[1]: Stopping IPv4 firewall with iptables... Sep 09 08:34:10 my.server.com iptables.init[338229]: iptables: Setting chains to policy ACCEPT:> Sep 09 08:34:10 my.server.com iptables.init[338229]: iptables: Flushing firewall rules: [ OK ] Sep 09 08:34:10 my.server.com systemd[1]: iptables.service: Succeeded. Sep 09 08:34:10 my.server.com systemd[1]: Stopped IPv4 firewall with iptables. and here's my current iptables -L -n output Chain INPUT (policy ACCEPT) target prot opt source destination f2b-postfix-sasl tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain f2b-postfix-sasl (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 Sorry, it's just confusing, and it wasn't on my previous server, and I'd like to make use of it if it's not being used. And again, thank you for the enlightenment
here's my current IPTABLES output: Code: # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination f2b-dovecot tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 110,995,143,993 f2b-postfix-sasl tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain f2b-postfix-sasl (1 references) target prot opt source destination REJECT all -- 31.130.184.39 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.51 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.62 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.174 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.93 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.194 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.147 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.68 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.72 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.148 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.59 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 31.130.184.110 0.0.0.0/0 reject-with icmp-port-unreachable RETURN all -- 0.0.0.0/0 0.0.0.0/0 Chain f2b-dovecot (1 references) target prot opt source destination RETURN all -- 0.0.0.0/0 0.0.0.0/0 and here's some of the maillog entries Code: Oct 1 01:13:56 dns2 postfix/smtpd[2408685]: connect from unknown[31.130.184.59] Oct 1 01:13:56 dns2 postfix/smtpd[2408685]: discarding EHLO keywords: CHUNKING Oct 1 01:13:59 dns2 postfix/smtpd[2408688]: timeout after AUTH from unknown[31.130.184.46] Oct 1 01:13:59 dns2 postfix/smtpd[2408688]: disconnect from unknown[31.130.184.46] ehlo=1 auth=0/1 rset=1 commands=2/3 Oct 1 01:14:00 dns2 postfix/smtpd[2408685]: warning: unknown[31.130.184.59]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Oct 1 01:14:00 dns2 postfix/smtpd[2408685]: disconnect from unknown[31.130.184.59] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4 Oct 1 01:14:02 dns2 postfix/smtpd[2406567]: connect from unknown[31.130.184.148] Oct 1 01:14:03 dns2 postfix/smtpd[2406567]: discarding EHLO keywords: CHUNKING Oct 1 01:14:08 dns2 postfix/smtpd[2410283]: timeout after AUTH from unknown[31.130.184.55] Oct 1 01:14:08 dns2 postfix/smtpd[2410283]: disconnect from unknown[31.130.184.55] ehlo=1 auth=0/1 rset=1 commands=2/3 Oct 1 01:14:08 dns2 postfix/smtpd[2406567]: warning: unknown[31.130.184.148]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Oct 1 01:14:09 dns2 postfix/smtpd[2406567]: disconnect from unknown[31.130.184.148] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4 Oct 1 01:14:18 dns2 postfix/smtpd[2408757]: connect from unknown[31.130.184.72] Oct 1 01:14:18 dns2 postfix/smtpd[2408757]: discarding EHLO keywords: CHUNKING Oct 1 01:14:21 dns2 postfix/smtpd[2408757]: warning: unknown[31.130.184.72]: SASL LOGIN authentication failed: UGFzc3dvcmQ6 Oct 1 01:14:21 dns2 postfix/smtpd[2408757]: disconnect from unknown[31.130.184.72] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4 you can see that there are rules created by fail2ban specifically targeting the offending IPs trying to guess email passwords, yet they still get through and keep trying. why are these rules not blocking these offending IPs? is it because firewalld was disabled up front, so there's no firewall actually active?
so i did a little testing. i unmasked firewalld, enabled it, then started it. the maillog stopped updating, and the roundcube account I was logged into stopped responding. as soon as I stopped firewalld, the maillog started appending again, and roundcube became functional. so something in the way the iptables rules are created is somehow blocking http and postfix traffic. the policies for the 3 default chains are set to ACCEPT, and there are no HTTP specific rules, nor any rules that address my internal network, so not sure how traffic gets fully blocked when firewalld or iptables.service are started. Is this maybe an initial configuration problem with the iptables rules during setup?
So eg. this ip is in your f2b-postfix-sasl list; what is the time of the Ban showing in your fail2ban log (maybe /var/log/fail2ban) for it? According to that output, you still have no firewall in place, only fail2ban catching a few repeat offenders, seemingly for only the dovecot and postfix-sasl jails (eg. even the default sshd jail has been disabled). Most any sane firewall will block everything except what you explicitly allow; you enabled a firewall rule management system without allowing anything, so everything was blocked. Then you disabled that firewall rule setup and everything is allowed again.
I've pulled new data to include dates, so maybe this will help: Code: [root@dns2 bin]# date Fri Oct 1 11:28:57 EDT 2021 [root@dns2 bin]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 31.130.184.64 anywhere DROP all -- 31.130.184.68 anywhere DROP all -- 31.130.184.78 anywhere DROP all -- 31.130.184.201 anywhere DROP all -- 31.130.184.177 anywhere DROP all -- 31.130.184.147 anywhere DROP all -- 31.130.184.198 anywhere DROP all -- 31.130.184.110 anywhere DROP all -- 31.130.184.93 anywhere DROP all -- 31.130.184.76 anywhere DROP all -- 31.130.184.67 anywhere DROP all -- 31.130.184.72 anywhere DROP all -- 31.130.184.194 anywhere DROP all -- 31.130.184.148 anywhere DROP all -- 31.130.184.39 anywhere DROP all -- 31.130.184.59 anywhere DROP all -- 31.130.184.55 anywhere DROP all -- 31.130.184.46 anywhere DROP all -- 31.130.184.62 anywhere DROP all -- 31.130.184.51 anywhere DROP all -- 31.130.184.174 anywhere DROP all -- 31.130.184.182 anywhere DROP all -- 31.130.184.75 anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination note the date command at the top - the iptables command was run immediately afterwards. All chains have the default policy of ACCEPT. please also note the top 6 IPs being blocked... here's a chunk of the maillog that's relevant Code: Oct 1 11:30:26 dns2 postfix/smtpd[2613800]: timeout after AUTH from unknown[31.130.184.201] Oct 1 11:30:26 dns2 postfix/smtpd[2613800]: disconnect from unknown[31.130.184.201] ehlo=1 auth=0/1 rset=1 commands=2/3 Oct 1 11:30:32 dns2 postfix/smtpd[2613716]: timeout after AUTH from unknown[31.130.184.177] Oct 1 11:30:32 dns2 postfix/smtpd[2613716]: disconnect from unknown[31.130.184.177] ehlo=1 auth=0/1 rset=1 commands=2/3 Oct 1 11:30:37 dns2 postfix/smtpd[2613801]: timeout after AUTH from unknown[31.130.184.147] Oct 1 11:30:37 dns2 postfix/smtpd[2613801]: disconnect from unknown[31.130.184.147] ehlo=1 auth=0/1 rset=1 commands=2/3 Oct 1 11:30:39 dns2 postfix/smtpd[2613886]: timeout after RSET from unknown[31.130.184.198] Oct 1 11:30:39 dns2 postfix/smtpd[2613886]: disconnect from unknown[31.130.184.198] ehlo=1 rset=1 commands=2 Oct 1 11:30:43 dns2 postfix/smtpd[2614614]: timeout after AUTH from unknown[31.130.184.110] Oct 1 11:30:43 dns2 postfix/smtpd[2614614]: disconnect from unknown[31.130.184.110] ehlo=1 auth=0/1 rset=1 commands=2/3 Oct 1 11:30:56 dns2 postfix/smtpd[2614786]: timeout after RSET from unknown[31.130.184.76] Oct 1 11:30:56 dns2 postfix/smtpd[2614786]: disconnect from unknown[31.130.184.76] ehlo=1 rset=1 commands=2 please note the timestamps, and the IPs indicated. the rules in iptables are not port or protocol specific -they are blanket DROP rules. the log entries are also clearly 1-2 minutes AFTER the rules were displayed, and the rules are not rules that might drop - they manually entered (not fail2ban) rules that work on my other server where iptables is actively running. this sytem does NOT have iptables actively running, and firewalld was intentionally disabled during the Perfect Server instructions, and is off now. my frustration is that i believe I keep being told that the ISPConfig default bastille is doing the firewalling, and that it uses iptables to handle the rule storage, but if that's the case, the above traffic shouldn't be occurring, so I'm not seeing how there's any firewall active. When i do manually enable iptables (like my other ISPConfig server already has running), everything seems to be getting blocked (unlike my other server), even though the default action is ACCEPT. There's clearly something I'm missing, or misreading, oir misunderstanding, but I haven't figured that out yet, so I'm still asking questions. I appreciate the help in figuring it out. I agree with - but the rules specifically state ACCEPT all, DROP just this IP traffic. however, it's not doing that, with iptables on or off, meaning that when iptables is on, it's not following it's own rules, and when it's off, some other firewall isn't implementing the rules either. I disagree with not because I think they're wrong, but because the rules state otherwise - ACCEPT all, DROP this specific traffic, nothing else. and in regards to my firewalld testing on/off, I believe I was told previously that iptables was only the holder of the rules that firewalld implements, so hence my testing of firewalld. What am I missing? And again, thank you.
So those ips were blocked, and a minute and a half later postfix logged those connections as timing out, which is exactly what you would expect if those firewall rules were indeed working. You could have those log matched packets, and then you should see every time they take effect. I keep telling you you don't have any firewall rules in place, only fail2ban was setup Bastille is a shell script which uses iptables to setup firewall rules. ufw and firewalld are both similar, they create a set of firewall rules. The logs you show seem to indicate that the traffic did stop in mid-SMTP. I think it's more when you enabled firewalld without configuring it to allow anything, everything was blocked. I'm not familiar with firewalld specifically, but that is normal and intended behavior for most firewall scripts. Yes, you might search for general iptables/linux firewall info (an "intro" or "primer" type document). I'm saying some things repeatedly, so the words I'm using to describe it may not be coming across as intended, and a different presentation with a holistic view might help. Your rules at that time sent all traffic for ports 25, 465 and 587 to the f2b-postfix-sasl chain, which dropped traffic for specific source addrs. The statement, 'you enabled a firewall rule management system without allowing anything, so everything was blocked' was specifically in regard to your firewalld testing. The same would happen if you enabled ufw but didn't allow incoming traffic for any ports.
again, thank you for the help so i just checked the maillog file, and indeed, the 31.130.184.x IPs have stopped coming through, the last entry was within 5 minutes of the iptables -L timestamp, so if there's a 5 minute timeout, then that seems to give with your observation (yeah!) regarding the isn't the following a firewall rule definition? Code: Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 31.130.184.64 anywhere also, that second round of rules was ALL the rules - there were no fail2ban specific rules in the system any longer. all the ones listed there were manually entered by me to target those offending IPs. The fail2bqan rules may have been there in the previous data, but they weren't later. maybe my understanding of iptables is wrong - I was under the impression it was a full-service firewall - taht it allows for the creation and management of firewall rules, as well as implements those rules on network traffic at a base level. https://phoenixnap.com/kb/iptables-tutorial-linux-firewall seems to indicate that it's the full package deal - rules and implemenetor in one package, at a base level. And that's how it appears to work on my other server - i use iptables commands to create/delete rules, and only when the iptables service is running, is traffic blocked based on those rules. turn iptables off, and all traffic is allowed in/out (i only really block INCOMING). as far as i know, bastille is running on that server as well, as it's a Perfect Server ISPConfig installation, but I find no processes running that indicate they are bastille-related. Is there a definite way to tell if it's running? does ISPConfig revert to something else if it finds it's already active? Bastille doesn't appear to be a service - and people refer to it as a script, does something trigger it periodically? On this server, is bastille telling something else to implement the rules? or is it inserting the rules shown via iptables into some postfix/dovecot-specific configuration that's blocking traffic at that level, and not the base network level? again, thank you
Yes, that is a rule to block the specific ip address. Firewall configuration "scripts" like bastille/ufw/firewalld will add a bunch of rules to reject invalid state packets, permit established connections, allow specific incoming connections for the few ports you run public services on, etc. - you have none of that. For anyone on the internet but that handful of specifically blocked addrs, you effectively have no firewall whatsoever. So if maybe you accidentally installed nfs or samba or a print server or rpcbind or a "million" other things and didn't realize it, they are all wide open and not protected by firewall rules. Yes, that's basically it - iptables is the command used to configure the firewall rules, and I think also the name of a service on some (older?) OS's used to invoke the iptables command. Bastille and ufw and firewalld and numerous other systems are all used to create a firewall by calling iptables (and other utilities) to setup rules to implement the policy you want (eg. only allow ssh+mail ports on a mail server). Bastille is a script that runs to call iptables and create firewall rules (and it might have configured some other things back in the day, though I don't know if ISPConfig's copy does that), there is no running process. If you have your firewall type set to bastille and the firewall server plugin enabled, when you add ports to the server's firewall config in ispconfig, it will use generate a config file for bastille and run bastille-firewall with the new config. The effect will be firewall rules added which you could see in your "iptables -L -n -v" output - as that is missing, bastille has evidently not been configured/used.
thank you. one thing that I didn't mention, but assumed would be obvious standard operating procedure for anyone offering these types of services - i have a network firewall in front of this server. It only allows certain ports through to specific internal IP address (policy REJECT by default, ALLOW for specific criteria), so the rules on this machine don't have to do full internet-level firewall protection. On this server, i'm just trying to block specific abusers of the services offered on this machine (and the same on my other server), adding a layer of firewalling. So i don't need all the rules on this machine for all the ports and services a regular internet-facing router needs. That's why it looks wide open. Still, that doesn't mean it's not a firewall - it would still be a firewall, just a very poorly and ill-advised version of one Sorry I didn't catch that in your responses earlier. as for bastille and all the command line utilities referenced above that only create rules stored within iptables - understood - they only manage the rules. so what implements or uses the rules? what process checks every packet against the rules and says yes or no? iptables is also that process, based on my understanding. Am i wrong there? because turning the service on/off on my other machine affects the network traffic coming in. on a Perfect Server CentOS 8 machines, what is that service? the only thing mentioned related to firewalls that I've found in the PS instructions are related to turning off firewalld and how bastille is the preferred firewall. and that bastille statement is misleading anyway - it's not a firewall, it's a firewall rule maker, if i'm understanding you correctly. Again, thank you!
found this info regarding CentOS 8, which may explain a few things... * The 'iptables' command is a tool to modify the firewall rules that are in the kernel's 'netfilter' * The kernel in CentOS 8 (and all kernels from version 3.13 -- released Jan 2014) has 'nftables' that supersedes netfilter * Rules in netfilter are modified with 'nft' tool * The 'iptables' in CentOS 8 is a wrapper to 'nft' that merely converts your iptables-syntax to nftables-syntax i'm betting there a typo in there somewhere - nftables probably supersedes iptables, not netfilter, as stated? so it appears that maybe netfilter is whats implementing the rules the other utilities create for netfilter. i'll keep digging...
Just to document what I've figured out... Prior to CentOS 8, iptables was the firewall mechanism of choice - it was responsible for making the firewall rules, and may have also been the underlying implementor of those rules (haven't dug that far, mute point at this point for me, but it does appear that way). In CentOS 8, netfilter is now the firewall mechanism of choice - it hooks into the kernel, and it establishes a ruleset that the kernel consults for filtering purposes. The rule maker (there's a distinction) that goes along with netfilter is nf(tables). iptables/firewalld/bastille/ufw/etc are all just additional rule makers that can contribute to the ruleset. iptables in particular is now just a mapper that converts rules to nft format and submits them via nft (simplified, but essentially thats how it works). From what I've read, stopping iptables/nft/firewalld/etc "services" really just causes nft to flush the ruleset so it's wide open and no effective filtering is done. starting nft loads a nft.conf files, starting iptables loads an iptables.save file, and i assume something similar happens for the other two. I'm guessing that the rules I was making were getting into the ruleset and were getting applied, I was just probably not realizing the log entries I was seeing were timeout messages, not continuing attempts - thanks for pointing out that difference. I'm also guessing that my starting/stopping iptables wasn't really doing what I thought. Most likely starting iptables (while the ruleset already had some rules defined) was probably merging my iptables.save rules into the existing ruleset, not replacing it, and causing conflicts that caused all traffic to stop flowing. Stopping iptables probably wiped the ruleset clean, thereby letting stuff flow again. So my solution is to disable and mask off iptables as well as firewalld. I don't plan to create any rules from within ISPConfig, so I essentially don't have to worry about bastille conflicts, and I'm going to use nf(tables) directly for the filtering rules I create, insuring that there won't be many if any ruleset conflicts like I was causing. Maybe a note about the change to iptables in the Perfect Server CentOS 8 instructions would be advisable? I don't know, but seems like it might be a good place to make people aware. Thanks to those that tried to get me to this point - I really do appreciate the feedback, and the education. Hopefully someone will find this experience useful down the road.
