Re: [qmailtoaster] Re: fail2ban - now more than ever
On Saturday 05 April 2014 07:38 AM, Eric Shubert wrote: Another option (of course) is to have both public and private interfaces on any public facing host (as many servers do), and only allow ssh access from the private side. And yet another is to have a perimeter firewall that port forwards traffic to QMT. This case should not allow ssh on port 25 at all, and forwards no ssh traffic anywhere from a public address. Yet QMT can accept SSH connections from anywhere, since the firewall is taking care of potentially malicious traffic. I'd be interested to know how many people run QMT on a public address, vs behind a NATing router. This affects how the QMT firewall is configured, and I'm planning to automate that setup. Just curious to know though how people are setting up their QMT hosts. (Survey Says:) I run an openvpn server and force SSHD/FTP to bind to the VPN IP. Access is only via a client connected using a VPN. Port scans won't reveal anything on the public IP. In one instance IMAP, POP3 and SUBMISSION also listen only on the VPN IP. BTW, this isn't a QMT setup, but there's no reason why it couldn't be implemented. Bharath - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: fail2ban - now more than ever
On 04/05/2014 04:44 AM, Bharath Chari wrote: On Saturday 05 April 2014 07:38 AM, Eric Shubert wrote: Another option (of course) is to have both public and private interfaces on any public facing host (as many servers do), and only allow ssh access from the private side. And yet another is to have a perimeter firewall that port forwards traffic to QMT. This case should not allow ssh on port 25 at all, and forwards no ssh traffic anywhere from a public address. Yet QMT can accept SSH connections from anywhere, since the firewall is taking care of potentially malicious traffic. I'd be interested to know how many people run QMT on a public address, vs behind a NATing router. This affects how the QMT firewall is configured, and I'm planning to automate that setup. Just curious to know though how people are setting up their QMT hosts. (Survey Says:) I run an openvpn server and force SSHD/FTP to bind to the VPN IP. Access is only via a client connected using a VPN. Port scans won't reveal anything on the public IP. In one instance IMAP, POP3 and SUBMISSION also listen only on the VPN IP. BTW, this isn't a QMT setup, but there's no reason why it couldn't be implemented. Bharath - I do essentially the same thing (I think), using IPCop to manage the VPNs. IPCop eliminates some of the complexity of setting up an openvpn (or IPSec) VPN, as well as providing other network services. I run everything as virtual hosts under ProxmoxVE, so there's minimal hardware involved. You say this isn't a QMT setup. I presume you mean that the VPN is separate from your QMT host. How is your QMT configured with regards to networking? How many NICs? Public or private addresses? Thanks for chiming in, Bharath. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] qtp-backup won't work
Hello list, on my qtp installation the backup doesn't work any more. I don't remember that I've change something in the script, so maybe it's an issue one of the yum update processes. I've trace the issue to the next command which is located in the script: tar -C $backupdest \ -czf $backupdest/$curlfile $DATENAME-* When I start the command on the console it result to an error: [root@mail ~]# tar -C /backup/qmailbkup -czf /backup/qmailbkup/201404052008-backup.tar.gz 201404052008-* tar: 201404052008-*: Cannot stat: No such file or directory tar: Error exit delayed from previous errors When I look in the directory /backup/qmailbkup I see the next files: 201404052008-assign.tar.bz2 201404052008-backup.tar.gz 201404052008-qmailadminpasswd.tar.bz2 201404052008-qmailcontrol.tar.bz2 201404052008-spamassassin-files.tar.bz2 201404052008-squirrelmail-plugins.tar.bz2 201404052008-squirrelmail-prefs.tar.bz2 201404052008-vpopmail.sql.gz The problem is that I don't see the difference with command which is also in the qtp-backup script: tar -C /var/lib/squirrelmail/prefs \ -cjf $backupdest/$SQMAILPREFS * I hope one of you can see the problem. Regards, Peter - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: qtp-backup won't work
On 04/05/2014 11:13 AM, Peter Peterse wrote: Hello list, on my qtp installation the backup doesn't work any more. I don't remember that I've change something in the script, so maybe it's an issue one of the yum update processes. I've trace the issue to the next command which is located in the script: tar -C $backupdest \ -czf $backupdest/$curlfile $DATENAME-* When I start the command on the console it result to an error: [root@mail ~]# tar -C /backup/qmailbkup -czf /backup/qmailbkup/201404052008-backup.tar.gz 201404052008-* tar: 201404052008-*: Cannot stat: No such file or directory tar: Error exit delayed from previous errors When I look in the directory /backup/qmailbkup I see the next files: 201404052008-assign.tar.bz2 201404052008-backup.tar.gz 201404052008-qmailadminpasswd.tar.bz2 201404052008-qmailcontrol.tar.bz2 201404052008-spamassassin-files.tar.bz2 201404052008-squirrelmail-plugins.tar.bz2 201404052008-squirrelmail-prefs.tar.bz2 201404052008-vpopmail.sql.gz The problem is that I don't see the difference with command which is also in the qtp-backup script: tar -C /var/lib/squirrelmail/prefs \ -cjf $backupdest/$SQMAILPREFS * I hope one of you can see the problem. Regards, Peter - My apologies for breaking this. I don't see the difference either to be honest. I thought this version had been run already, and perhaps it was with an older version where it worked. tar is a little squirrelly with the options. It doesn't appear to be picking up the -C option properly, for whatever reason. Please try this: # tar --create --gzip --file $backupdest/$curlfile \ --directory $backupdest $DATENAME-* and let us know if that works. P.S. Which versions are you running (OS and qtp)? -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: fail2ban - now more than ever
On Saturday 05 April 2014 08:33 PM, Eric Shubert wrote: On 04/05/2014 04:44 AM, Bharath Chari wrote: On Saturday 05 April 2014 07:38 AM, Eric Shubert wrote: Another option (of course) is to have both public and private interfaces on any public facing host (as many servers do), and only allow ssh access from the private side. And yet another is to have a perimeter firewall that port forwards traffic to QMT. This case should not allow ssh on port 25 at all, and forwards no ssh traffic anywhere from a public address. Yet QMT can accept SSH connections from anywhere, since the firewall is taking care of potentially malicious traffic. I'd be interested to know how many people run QMT on a public address, vs behind a NATing router. This affects how the QMT firewall is configured, and I'm planning to automate that setup. Just curious to know though how people are setting up their QMT hosts. (Survey Says:) I run an openvpn server and force SSHD/FTP to bind to the VPN IP. Access is only via a client connected using a VPN. Port scans won't reveal anything on the public IP. In one instance IMAP, POP3 and SUBMISSION also listen only on the VPN IP. BTW, this isn't a QMT setup, but there's no reason why it couldn't be implemented. Bharath - I do essentially the same thing (I think), using IPCop to manage the VPNs. IPCop eliminates some of the complexity of setting up an openvpn (or IPSec) VPN, as well as providing other network services. I run everything as virtual hosts under ProxmoxVE, so there's minimal hardware involved. You say this isn't a QMT setup. I presume you mean that the VPN is separate from your QMT host. How is your QMT configured with regards to networking? How many NICs? Public or private addresses? Thanks for chiming in, Bharath. I do run the VPN separate from the Mail Server host because I run other services which aren't mail related and require connectivity via a VPN. Sadly this isn't a QMT setup, it's a posfix / dovecot setup. I only run QMT for my personal testing and pleasure these days :) Bharath - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: fail2ban - now more than ever
On 04/05/2014 06:33 PM, Bharath Chari wrote: On Saturday 05 April 2014 08:33 PM, Eric Shubert wrote: On 04/05/2014 04:44 AM, Bharath Chari wrote: On Saturday 05 April 2014 07:38 AM, Eric Shubert wrote: Another option (of course) is to have both public and private interfaces on any public facing host (as many servers do), and only allow ssh access from the private side. And yet another is to have a perimeter firewall that port forwards traffic to QMT. This case should not allow ssh on port 25 at all, and forwards no ssh traffic anywhere from a public address. Yet QMT can accept SSH connections from anywhere, since the firewall is taking care of potentially malicious traffic. I'd be interested to know how many people run QMT on a public address, vs behind a NATing router. This affects how the QMT firewall is configured, and I'm planning to automate that setup. Just curious to know though how people are setting up their QMT hosts. (Survey Says:) I run an openvpn server and force SSHD/FTP to bind to the VPN IP. Access is only via a client connected using a VPN. Port scans won't reveal anything on the public IP. In one instance IMAP, POP3 and SUBMISSION also listen only on the VPN IP. BTW, this isn't a QMT setup, but there's no reason why it couldn't be implemented. Bharath - I do essentially the same thing (I think), using IPCop to manage the VPNs. IPCop eliminates some of the complexity of setting up an openvpn (or IPSec) VPN, as well as providing other network services. I run everything as virtual hosts under ProxmoxVE, so there's minimal hardware involved. You say this isn't a QMT setup. I presume you mean that the VPN is separate from your QMT host. How is your QMT configured with regards to networking? How many NICs? Public or private addresses? Thanks for chiming in, Bharath. I do run the VPN separate from the Mail Server host because I run other services which aren't mail related and require connectivity via a VPN. Sadly this isn't a QMT setup, it's a posfix / dovecot setup. I only run QMT for my personal testing and pleasure these days :) Bharath - That's quite all right, Bharath. I still appreciate your participation. You never know, qmailtoaster might just evolve into emailtoaster some day (with postfix). So in generic terms, you have your mail server on a private IP address behind a NATing perimeter router/firewall. Is that correct? -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: fail2ban - now more than ever
On Sunday 06 April 2014 07:17 AM, Eric Shubert wrote: On 04/05/2014 06:33 PM, Bharath Chari wrote: On Saturday 05 April 2014 08:33 PM, Eric Shubert wrote: On 04/05/2014 04:44 AM, Bharath Chari wrote: On Saturday 05 April 2014 07:38 AM, Eric Shubert wrote: Another option (of course) is to have both public and private interfaces on any public facing host (as many servers do), and only allow ssh access from the private side. And yet another is to have a perimeter firewall that port forwards traffic to QMT. This case should not allow ssh on port 25 at all, and forwards no ssh traffic anywhere from a public address. Yet QMT can accept SSH connections from anywhere, since the firewall is taking care of p I do run the VPN separate from the Mail Server host because I run other services which aren't mail related and require connectivity via a VPN. Sadly this isn't a QMT setup, it's a posfix / dovecot setup. I only run QMT for my personal testing and pleasure these days :) Bharath - That's quite all right, Bharath. I still appreciate your participation. You never know, qmailtoaster might just evolve into emailtoaster some day (with postfix). So in generic terms, you have your mail server on a private IP address behind a NATing perimeter router/firewall. Is that correct? These are the scenarios I run : 1)The entire mail server on a public IP. All services are accessible via the public internet (including FTP/SSH) - invitation for the black hats to try but unavoidable for some cases. 2) The mail server on a public IP but all FTP/SSH only on a VPN IP. 3) The mail server on a private IP with port forwards from the firewall. FTP/SSH via private IPs. 4) The mail server on a private IP with port forwards from the firewall for mail. FTP/SSH only via VPN. Bharath - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
