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... > > 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. 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. 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. yes, we could look a vlans as well. but the point of the internet is connectedness. > > > > 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
