> -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx > [mailto:redhat-list-bounces@xxxxxxxxxx]On Behalf Of Tobias Speckbacher > Sent: Thursday, April 14, 2005 3:11 PM > To: General Red Hat Linux discussion list > Subject: RE: Blackhole > > > > > > -----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 of course meant limiting them to issues not known at that time. > 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 > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
