Linode Forum
Linode Community Forums 		 FAQFAQ    SearchSearch    MembersMembers      Register Register 
 LoginLogin [ Anonymous ] 
Post new topic  Reply to topic

Board index » Linux Community Forums » General Discussion
  Previous topic | Next topic 
Author Message
jebblue
PostPosted: Mon Oct 28, 2013 10:02 am 
Offline
Senior Member

Joined: Sun May 23, 2010 1:57 pm
Posts: 315
Website: http://www.jebblue.net
dwfreed wrote:
jebblue wrote:
>> can't result in you getting locked out of your own system because

If you can successfully fail to log into your system more than a few times in a row then you might want to consider installing fail2ban or at least iptables rate limiting. Preferably both.


Both of which only reduce logspam, and we're back to the point I gave before. Neither of them increase security in any useful way, but instead cause unnecessary headache for legitimate users.

-Doug


Are you saying iptables rate limiting is just good for reducing log congestion?
Top
   
Reply with quote  
sblantipodi
PostPosted: Mon Oct 28, 2013 12:09 pm 
Offline
Senior Member

Joined: Wed May 13, 2009 1:32 pm
Posts: 737
Location: Italy
Hi,
I would add to the logs somethings that says me if linode can connect to the internet.

I don't want to ping google every 5 minutes so I would like to find an alternative solution.

Do you think that this command is a good solution to see if my linode is online and ready to connect to the internet?
Code:
ping -q -w 1 -c 1 `ip r | grep default | cut -d ' ' -f 3` > /dev/null && echo ok || echo error
Top
   
Reply with quote  
Ox-
PostPosted: Mon Oct 28, 2013 2:31 pm 
Offline
Senior Member

Joined: Fri Jul 03, 2009 2:31 am
Posts: 54
ICQ: 897607
jebblue wrote:
sednet wrote:
Fail2ban. The cause of oh so much pain and oh so little benefit.


So stopping people who are actively trying to break into your server is a bad idea? That's what it does, monitors logs, sees suspicious activity, bans the IP. How's that "little benefit"?


The key word here is "distributed". More and more of the brute force attempts are coming from distributed botnets as opposed to a single script running on a single system. This means Fail2ban will fill up your firewall deny rules with thousands of hosts and still not stop the attack.

Rate limiting is a good idea though (as you mention in later posts).
Top
   
Reply with quote  
akerl
PostPosted: Mon Oct 28, 2013 2:35 pm 
Offline
Senior Member

Joined: Mon Jul 05, 2010 5:13 pm
Posts: 392
I rate limit connections to SSH with the following ruleset:

Code:
# cat /etc/iptables/iptables.rules
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT


Those firewall rules have served me well over the years.

- Les
Top
   
Reply with quote  
sblantipodi
PostPosted: Mon Oct 28, 2013 4:04 pm 
Offline
Senior Member

Joined: Wed May 13, 2009 1:32 pm
Posts: 737
Location: Italy
Ox- wrote:
jebblue wrote:
sednet wrote:
Fail2ban. The cause of oh so much pain and oh so little benefit.


So stopping people who are actively trying to break into your server is a bad idea? That's what it does, monitors logs, sees suspicious activity, bans the IP. How's that "little benefit"?


The key word here is "distributed". More and more of the brute force attempts are coming from distributed botnets as opposed to a single script running on a single system. This means Fail2ban will fill up your firewall deny rules with thousands of hosts and still not stop the attack.

Rate limiting is a good idea though (as you mention in later posts).


in any case it sends you an email warning you about what it is happening.
I don't think that botnet has so many IPs to do thousands attacks from different IPs.
Top
   
Reply with quote  
Ox-
PostPosted: Tue Oct 29, 2013 12:00 am 
Offline
Senior Member

Joined: Fri Jul 03, 2009 2:31 am
Posts: 54
ICQ: 897607
sblantipodi wrote:
in any case it sends you an email warning you about what it is happening.


For that you want a real HIDS because it will give you a better idea of the strength of the threat, not to mention it will send you warning emails on many other things attackers will try. Check out OSSEC.
Top
   
Reply with quote  
sblantipodi
PostPosted: Tue Oct 29, 2013 5:43 am 
Offline
Senior Member

Joined: Wed May 13, 2009 1:32 pm
Posts: 737
Location: Italy
akerl wrote:
I rate limit connections to SSH with the following ruleset:

Code:
# cat /etc/iptables/iptables.rules
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT


Those firewall rules have served me well over the years.

- Les


what is the difference between rate limiting IPs and using fail2ban?
rate limiting limits the numbers of connections from an IP, fail2ban limits the numbers of errors from an IP.

I find fail2ban more interesting than IP tables rate limiting.
Am I wrong? If yes, please argument why. Thanks.
Top
   
Reply with quote  
ken-ji
PostPosted: Tue Oct 29, 2013 6:10 am 
Offline
Senior Newbie

Joined: Fri Oct 19, 2012 8:35 pm
Posts: 15
akerl wrote:
I rate limit connections to SSH with the following ruleset:

Code:
# cat /etc/iptables/iptables.rules
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT


Those firewall rules have served me well over the years.

- Les



I believe I understand most iptables implementations, but yours don't seem like it gonna work.
You accept ICMP. Good
You accept connections to the loopback interface. Good
You do conn-tracking of existing or related connections, Good
You drop everything else. -> wait a minute, what happens if your net connection/session flakes out or you terminal craps out and you try to reconnect?

I don't get how this ruleset would help anybody unless they have console access and is using the box as a personal desktop. - Please enlighten me.
Top
   
Reply with quote  
Display posts from previous:  Sort by  
Post new topic  Reply to topic

Board index » Linux Community Forums » General Discussion


Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
RSS

Powered by phpBB® Forum Software © phpBB Group