Blackhole
Tobias Speckbacher
TSpeckbacher at quova.com
Thu Apr 14 22:22:18 UTC 2005
> -----Original Message-----
> From: redhat-list-bounces at redhat.com
> [mailto:redhat-list-bounces at redhat.com]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 at redhat.com
> > [mailto:redhat-list-bounces at redhat.com]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 at redhat.com?subject=unsubscribe
> > > > https://www.redhat.com/mailman/listinfo/redhat-list
> > > >
> > >
> > > --
> > > redhat-list mailing list
> > > unsubscribe
> > mailto:redhat-list-request at redhat.com?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 at redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/redhat-list
> >
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>
More information about the redhat-list
mailing list