> -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx > [mailto:redhat-list-bounces@xxxxxxxxxx]On Behalf Of David Bear > Sent: Thursday, April 14, 2005 2:30 PM > To: General Red Hat Linux discussion list > Subject: Re: Blackhole > > > On Thu, Apr 14, 2005 at 01:47:14PM -0700, Tobias Speckbacher wrote: > > > > > 10-15 mins of downtime. > > > > Best solution to the problem in my opinion is to only allow > ssh access from trusted networks. > > The entire issue goes away. > > uh, untill some host in the trusted network gets compromised... Agreed, but you narrowed it down to a smaller entity that presumably is easier to protect. Especially if you dont have to offer any network services from the network(s). > > > > sshd supports tcpwrapper, or you can use iptables, or a > firewall external to the system, etc... > > > > lets pretend you are in a university like I am. there are 15000 > machines in our network. I firewall out everyone outside our campus > from ssh. My trusted network is then narrowed to 15000 possible hosts, > which really may appear to be more. Why? ip spoofing.. since we have 2 > class B networks we could really have over 120,000 possible addresses > that could attack me. Every solution has to fit the implementation. It seems that you are implying that every host on those 2 class B's has equal amount of access to any service on your networks. > > so, I narrow it down even more to ... what? I think of all the > locations (ip addresses) I could use to ssh into my servers. I narrow > it down to 5 different subnets.. unless I happen to be on a machine > the uses dhcp.. Then I won't know the subnet a priori. > > I think about the only thing I can accomplish with blocking hosts > based on ip is narrowing the scope of the threat. Even then, one of > those hosts in those trusted networks could get comporised. Agreed, "limiting the threat" is the key here. This is why we patch systems, you dont eliminate threats you limit them to known issues. I'd consider access to my shell service from the entire universe of ip addresses a known issue. > > So, as I review my logs, I only see 300 ssh attempts from hosts on my > network rather than 1000000 from hosts around the world. It only makes > my life easier when I need to generate a trouble ticket to have some > system adminstrator look at a box doing strange things. Great example, clearly demonstrating it "limiting the threat". > > yes, we could look a vlans as well. but the point of the internet is > connectedness. You can be as connected as you want when using vlans. > > > > > > > You were talking mathmatics and chances of something > > > happening being a > > > valid reason to restrict access.. > > > > > > So let us put this in perspective. > > > > > > * Root password is lowercase characters only, a-z > (considered a weak > > > password) > > > * 8 characters long > > > * 100ms to complete the key exchange required for and ssh > connection > > > * 3 password retrys before connection dropped > > > > > > 26^8 (a reasonably close approximate as to how many different > > > combinations > > > to try - this assumes we actually know the password length, > > > normally it > > > would be more along the lines of 26 + 26^2 + 8^3 etc etc) > > > > > > 26^8 = 208827064576 > > > > > > divide by 30 attempts a second > > > > > > 208827064576 / 30 = 6960902152.5333333333333333333333 > > > > > > convert this into years > > > > > > 6960902152.53 / 60 / 60 / 24 / 365 = 220.73 years > > > > > > Thats right, around 220 years to brute force my 8 character, all > > > lowercase, weak password. > > > > > > now, considering I tend to use a mixture of punctuation, > > > upper and lower > > > case and numerals in my passwords and have them at _least_ 8 > > > characters.. > > > > > > I really think you have more chance of being hit by a meteor > > > on the way to > > > work and not completeing your e-mail than you have of brute > > > forcing root > > > across a network via ssh. > > > > > > restricting the hosts that can ssh into the box would IMHO be > > > a far more > > > productive use of time. (as well as reading logs, > choosing non-weak > > > passwords, etc etc) > > > > > > Oh, and reading logs in this case is quite a good indicator > > > that someone > > > is trying to brute force your system (infact, you could go a > > > step further > > > and setup an alarm if a single account has a password failure > > > more than > > > say - 5 times, it would pick up an attack within the first > > > 200ms) - I dont > > > know about you but if I got 208827064576 failed logins for > > > root then I > > > would probably notice, infact, I would probably notice after > > > the first day > > > at the least. > > > > > > > > > -- > > > Steve. > > > > > > > > > > > > On Thu, 14 Apr 2005, Wayne Pinette wrote: > > > > > > > This is all true, but why not just cut off the problem at > > > the source. > > > > no root login means there is 0 chance for any kind of brute > > > > force hacking of any kind on that account. The rest are > > > very nice and > > > > important security additives. As for brute forcing non > > > root passwords > > > > first, well, first you have to know what they are. There > > > is an extra > > > > step right there. Secondly, > > > > (and I know this is a redhat list but what the heck :-) If > > > you have a > > > > infrastructure similar to that of a standard Tru64 system, > > > not all user > > > > acccounts can su. So There is yet another step in which > > > not only would > > > > you have to find an account to force, you would have to > > > find the right > > > > account to force. > > > > > > > > And reading logs only tells you have been hacked, it does > > > not stop it. > > > > > > > > In the end, you are right in that "no remote root" all by > > > itself does > > > > not make a system secure. As far as Im concerned, you can never > > > > be too secure when it comes to the root account, and > IMHO, the best > > > > security is security which nips problems in the bud. > > > > Therefore, for me, not setting no remote access to root on > > > a publicly > > > > accessible system is just silly and does open a door, however > > > > small that opening is is subject to interpretation, to > a potential > > > > issue. > > > > > > > > Of course, on my way to work today, there was a potential a > > > meteor was > > > > large enough to burn through our atmosphere, > > > > being reduced to the size of a quarter by the time it hit > > > my elevation, > > > > and ping me in the head. Thereby not allowing me to > > > > create this email. But we all have our risk levels we cope > > > with every > > > > day :-). > > > > > > > > Wayner > > > > > > > > > > -- > > > redhat-list mailing list > > > unsubscribe > mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > > > https://www.redhat.com/mailman/listinfo/redhat-list > > > > > > > -- > > redhat-list mailing list > > unsubscribe > mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > > https://www.redhat.com/mailman/listinfo/redhat-list > > -- > David Bear > phone: 480-965-8257 > fax: 480-965-9189 > College of Public Programs/ASU > Wilson Hall 232 > Tempe, AZ 85287-0803 > "Beware the IP portfolio, everyone will be suspect of trespassing" > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
