Hello :)> You can parse the output of ''dig'' or ''nslookup'' in your > /etc/shorewall/params file and set your variables that way. If the > lookup fails, you set some some of default address (the last one you > looked up manually, for example).Tom once said the above statement, and I couldn''t find anymore info about this in the shorewall docs or mailing list archives. In South Africa its not so easy/cheap to get a static IP so we use dynamic dns often and therefore sometimes have to use dns names in the rules file. I would love to find out how better to do this. Would someone be able to provide an example for the above recommendation from Tom? (a params file that looks up the IP of the DNS name and if fails reverts to some other IP or something better/similar?) My shorewall has failed a few times as I put a script in place that restarts shorewall at 5:30 and 19:30 so that I could connect from home with my dyndns address(because then shorewall/iptables learns the new dyndns IP). Thanks for any suggestions/ideas -- Divan Santana Skype: DivanSantana Gtalk/MSN: Divan.Santana@GMail.com Love God, Love People, Love Life! ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Mon, Aug 13, 2007 at 10:52:02AM +0200, Divan Santana wrote:> In South Africa its not so easy/cheap to get a static IP so we use > dynamic dns often and therefore sometimes have to use dns names in > the rules file.Whatever you are doing, it sounds like a bad idea. Are you aware that DNS responses can be trivially faked by an attacker? There''s no particular reason to expect the value returned from a DNS query over the public internet to be accurate. This sort of thing is only really appropriate for local DNS servers, and that doesn''t sound like what you have here. (And that''s before considering that the DNS result picked up by shorewall is going to continue being used even when somebody else has received that IP address, until shorewall is next restarted) You probably want to create restrictions based on something other than the IP address. If you told us more about what you''re doing, we might have some better ideas. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Monday 13 August 2007 11:09:55 Andrew Suffield wrote:> Whatever you are doing, it sounds like a bad idea. Are you aware that > DNS responses can be trivially faked by an attacker? There''s no > particular reason to expect the value returned from a DNS query over > the public internet to be accurate. This sort of thing is only really > appropriate for local DNS servers, and that doesn''t sound like what > you have here. (And that''s before considering that the DNS result > picked up by shorewall is going to continue being used even when > somebody else has received that IP address, until shorewall is > next restarted) > > You probably want to create restrictions based on something other than > the IP address. If you told us more about what you''re doing, we might > have some better ideas.Hi Andrew, You are quite correct, I agree with you, its not really a good idea at all. End goal in this case was to secure ssh. I only wanted to allow ssh in from the internet from static IPs I know(work) and from my home(which was a dyndns address hence the problem). A better way would probably be to secure ssh better perhaps with ssh rate limiting or something? I have changed all my rules to only use IPs now as that is better. Thanks for the feedback. -- Divan Santana Skype: DivanSantana Gtalk/MSN: Divan.Santana@GMail.com Love God, Love People, Love Life! ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Divan Santana wrote:>A better way would probably be to secure ssh better perhaps with ssh rate >limiting or something?Configure sshd to only allow selected users (and specifically NOT root !), make sure all allowed users have good passwords. Then install something like fail2ban. fail2ban simply watches your logs, and if you have a number (configurable) of failed login attempts it adds an iptables rule to block connections from that IP for a (configurable) time. Apart from limiting to specific fixed IPs, it''s probably about as secure as you''ll get it. I used to regularly get hundred of connection attempts every day, obvious brute force attacks - now they simply get blocked by fail2ban and the attacker simply goes somewhere else. If you still want to filter by IP address, how about filtering by the IP block that home and work are allocated from ? It won''t stop someone on the same ISP from attacking you (in which case you could complain and get them kicked out), but it will stop the rest of the world. NB - You may want to read http://www.ossec.net/en/attacking-loganalysis.html and then add a few ''$''s to the regex''s in the config file. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Monday 13 August 2007 12:21:34 Simon Hobson wrote:> Configure sshd to only allow selected users (and specifically NOT > root !), make sure all allowed users have good passwords. Then > install something like fail2ban. > > fail2ban simply watches your logs, and if you have a number > (configurable) of failed login attempts it adds an iptables rule to > block connections from that IP for a (configurable) time. Apart from > limiting to specific fixed IPs, it''s probably about as secure as > you''ll get it. I used to regularly get hundred of connection attempts > every day, obvious brute force attacks - now they simply get blocked > by fail2ban and the attacker simply goes somewhere else. > > > If you still want to filter by IP address, how about filtering by the > IP block that home and work are allocated from ? It won''t stop > someone on the same ISP from attacking you (in which case you could > complain and get them kicked out), but it will stop the rest of the > world.Hi Simon, Yeah this sounds like some very good ideas. I should find out what the IP block is at my ISP and will look into using fail2ban or similar and lastly will put to practice using IPs and not DNS names in the rules file etc. :) Thanks for the tipps! :) -- Divan Santana Skype: DivanSantana Gtalk/MSN: Divan.Santana@GMail.com Love God, Love People, Love Life! ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Mon, Aug 13, 2007 at 11:21:34AM +0100, Simon Hobson wrote:> Divan Santana wrote: > > >A better way would probably be to secure ssh better perhaps with ssh rate > >limiting or something? > > Configure sshd to only allow selected users (and specifically NOT > root !), make sure all allowed users have good passwords. Then > install something like fail2ban. >Even better, configure ssh to only accept public keys. Use a different key on each computer from which you connect and make sure that each has a strong passphrase on it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Monday 13 August 2007 23:25:08 Roberto C. Sánchez wrote:> Even better, configure ssh to only accept public keys. Use a different > key on each computer from which you connect and make sure that each has > a strong passphrase on it.Hmmm, I like this idea, cause I only use ssh keys anyway... I'll try this out as well, thanks! -- Divan Santana Skype: DivanSantana Gtalk/MSN: Divan.Santana@GMail.com Love God, Love People, Love Life! ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users