What Linux tools and security??

fwor

buzbyxman wrote: »

Therefore fwor I wonder what you ment by your comment??

It wasn't intended as a dig at you, if that's what you mean. I thought there was a good chance that the "debate" had gone far too far into the detail for you to want to come back and comment.

Anyway, you've probably concluded by now that you don't need to do much other than installing updates if you intend to use your PC in a fairly basic way.

While Linux is currently far ahead of the older and still widespread versions of Windows in terms of security, Windows is getting better, and so it's likely that in relative terms there will be more interest in security attacks on Linux-based systems in future.

weegie.geek

JustPassingBy wrote: »

If these black hats are competent enough to crack ssh they'll also be well into IP spoofing. So what does your firewall (or tcp wrappers) do for you then? That's assuming these black hats are more interested in weegie.geek's machine rather than one on the Bank of England's network.

How would they know what IPs to spoof? And besides, assuming they work out the three correct IPs in a sea of 4 billion of them, spoofing is useless for exploiting. At best they could DDOS the box, but only if they KNEW the right IP, and the right port. They wouldn't receive anything back from the SSHD, since it'd send replies to the IP they're spoofing. They'd never know if what they're doing is having any effect. To the uninvited, the boxes I'm talking about are black holes.

And they're going to have a lot more luck when scanning the IP ranges of the boxes I'm talking about than trying the Bank Of England, I'd hope.

There are at least 1000,000,000 machines on the network so the odds of you not being hit are very much in your favour, especially when you factor in the plethora of different software distributions and setups, the nature of the exploit and the time it takes to spread. Some machines will succumb. 1,000? 10,000.? Who knows. Tough. The remainder will upgrade to the new version of ssh and become safe.

Perhaps there are 1,000,000,000 machines available to try, but with some educated guesses and a bit of common sense most of those can be ruled out. For example, scan the IP ranges of VPS and dedicated server providers known to give those OSes as an option. Particularly ones who provide unmanaged services, therefore relying on the people buying their services to keep the boxes secure and up to date.

Or perhaps it's a windows XP exploit, not much point scanning dedicated severs, go for residential ISPs instead, especially the bargain basement ones which tend to have less technically minded people as their customers.

Mr_Oink

JustPassingBy wrote: »

What was uppermost in my mind at the time was the rather curious idea being promoted that closed ports needed protection by using a firewall.

Let me help you with that as you appear to be struggling to accept something rather fundemental in system security in general.

We have already established - and you agree - that Ubuntu 10.4 ships with a fully permissive set of firewall rules. We have already established that Ubuntu 10.4 ships with a version of CUPS listening on port 631 (AKA a listening service). I agree that if every service was perfect, bug free and set up correctly there may be a weak case not to packet filter anything, however the reality is quite different. Software has bugs and holes just waiting to be discovered. Ubuntu 10.04 ships with a broken CUPS with a large security hole in it.

It ships with a number of broken and vulnerable items including CUPS, Transmission, TIFF library, OPIE, texlive-core and many, many more - perhaps this link will help: http://seclists.org/isn/2010/Jun/90

Good security practice - including the use of a packet filter/Firewall - helps mitigate against the the potential *unknown*.

If we adopt the 'should be OK' approach to matters of security then we can take all the locks off the doors in our homes because, by rights, nobody should try and come in if they are not supposed to. Clearly that would be a stupid thing to do because a miscreant - much like a cracker - will always *try the door* and look for low hanging fruit.

We can bat this back and forward as you troll away but it is, plain and simple, good security practice. I advocate that, you don't appear to. It's really that simple. I have a name for folk like you who *don't* advocate and practice it - 'Potential victims'.

Don't delude yourself that Linux is secure. Potentially it can be - but something like Ubuntu where a simple 'apt-get install <service>' used by someone new parrot following a tutorial can easily add a listening network service to a machine waiting to be exploited.

There are backdoors and root kits out their for Linux, along with trojans and viri. Not on the scale of Windoze - I agree - but it is reasonably trivial to add a system command to /usr/bin - or replace one of the existing commands such as ls, rm, pwd et al - with a modified version. You may need to get yourself up to speed and this will make a good starting point:

http://en.wikipedia.org/wiki/Linux_malware

I don't think there is much further point responding to you. Clearly you offer bad security advice, seem somewhat clueless to the real world risks of Linux and only want to argue. Coupled with the multiple drive by trolling posts I don't feel you are worth a further response.

If you want an argument why not try one of the many Linux mailing lists - or even 'linuxquestions.org' - it may help you to develop a wider view of the fundamentals Brian.

JustPassingBy

weegie.geek wrote: »

Perhaps there are 1,000,000,000 machines available to try, but with some educated guesses and a bit of common sense most of those can be ruled out. For example, scan the IP ranges of VPS and dedicated server providers known to give those OSes as an option. Particularly ones who provide unmanaged services, therefore relying on the people buying their services to keep the boxes secure and up to date.

Still leaves a lot of machines to be scanned for particular versions of server, distribution and kernel. Meanwhile the update becomes available. And if someone doesn't update? Well, what can you say? (The answer is not "install a firewall").

Packet filtering (which is all a firewall is) is good stuff, but its use is best analysed in whatever context you want to use it in. A blanket exhortation from the Ministry for the Promotion of Fear that "you must have a firewall" fails to appreciate the significance for security of the two basic maxims:

• Update software regularily, and
• Only do essential administrative tasks with root privileges.

As an aside: There have been some 417,000 attempts to log into this machine via sshd over the past two years. They're wasting their time and it doesn't bother me. If I did become annoyed I might consider using iptables to block an IP after a couple of connections have been made.

weegie.geek

Yeah it still leaves a lot of IPs, but you're talking about a lot smaller a job than you were talking about.

A vulnerability is spotted in OVH's standard ubuntu 10 server install's ssh daemon.

I scan their IP ranges.

Discounting routers and other reserved IPs that's 300k IP addresses.

Suddenly instead of blindly scanning a billion IP addresses, I'm targeting a range specifically known to have these problems. A range with 100mbit, 1gbit or even 10gbit connections, Hundreds of GB or dozens of TB of space, and mostly unmetered bandwidth. Useful machines for ddosing, vulnerability scanning, all sorts.

Cheap boxes, unmanaged boxes, favoured by people who don't know anything about linux because they're cheap and there are tons of tutorials around the net to show them how to setup torrentflux or whatever they want to use the box for.

300,000 of them, which will take a day at most with a botnet of only 10 machines, assuming 2-3 seconds per machine to scan port 22. Most botnets are many times larger than this, so in reality you're talking a few hours at most.

So unless the vulnerability is patched within hours, and the daemon is updated within hours, I'm going to get a fair few new zombies for my botnet.

It's all very well saying update regularly and don't use root unless necessary, but the reality is that people don't do that, especially when it's a one-user box and especially when the user isn't used to linux.

The bottom line is that SSH being firewalled off to all but the necessary IPs would've kept those machines safe from this attack.

JustPassingBy

weegie.geek wrote: »

A vulnerability is spotted in OVH's standard ubuntu 10 server install's ssh daemon.

Looks good to go.

I scan their IP ranges.

Good idea.

OVH don't notice all this activity? Shame on them. I'll make a note not to become a customer of their's.

300,000 of them, which will take a day at most with a botnet of only 10 machines, assuming 2-3 seconds per machine to scan port 22. Most botnets are many times larger than this, so in reality you're talking a few hours at most.

We'll allow that. Now how about a username and password/key to log in? May I relate briefly a real-life occurance rather than work on some vague, unspecified vulnerability.

A couple of years ago a user discovered and reported that Debian's version of ssh had very small key space available. 24,000 I think The random number generator in the openssl package was predictable. But whatever the number it was serious. Fixed packages were released within three days.

Suppose the discovery had been made by a less scrupulous person who used it to attack OVH. Statistically, access to a machine would be gained after trying 12,000 keys, provided a username was known of course. And the OS had to be Debian or Ubuntu. And password logins weren't affected, but the bot wouldn't know which was which because ssh doesn't advertise a login method. So it would take a lot longer than a few seconds, even with parallel conections. Remember also - ssh is set to delay by a couple of seconds after a failed login attempt.

How long to find and penetrate a single vulnerable machine? Your guess is as good as mine. Five hours? A day? (Are you sure OVH are still asleep)? Meanwhile, update time is getting closer.

So unless the vulnerability is patched within hours, and the daemon is updated within hours, I'm going to get a fair few new zombies for my botnet.

Your vulnerability would have to be much, much worse than the one I've described but something concrete to work with is necesary to make an assessment.

It's all very well saying update regularly and don't use root unless necessary, but the reality is that people don't do that, especially when it's a one-user box and especially when the user isn't used to linux.

What's so hard about it? If they cannot do this what makes them savvy enough to manipulate iptables rules?

The bottom line is that SSH being firewalled off to all but the necessary IPs would've kept those machines safe from this attack.

Restricting access by IP is legitimate but as I've pointed out a firewall isn't necessry to do it. Also many will want to connect from any IP, which ssh is designed to do securely.

Maybe, just maybe a machine or two which restricts IPs might not fall but history shows updating software wins hands down.

weegie.geek

Even with your example, 12k possible keys, 5 second delay between each brute force attempt, 60k seconds, 1000 minutes, 16 hours on average to get into that particular machine. Fixed packages were released within 3 days, which gives you plenty of time. Scan the hosts, find out which are vulnerable, get to work on individual hosts.

These are unmanaged servers. OS is installed, root password emailed to user. You're on your own as far as security is concerned, and that's fair enough because they're bargain basement stuff. I doubt the other non-premium dedi/colo people do any more in the way of security, and it's always been this way. The old FXP scene is testament to that, the number of zombies in datacentres is testament to that. If bills get paid, the datacentre doesn't care what the box does, as long as it doesn't get any complaints.

I agree that a firewall isn't necessary to restrict access to certain ports by IP, as I agreed previously, but it's handy to have the configuration all in one place.

Keeping software up to date will of course win, assuming there IS an update available. In those 3 days boxes that aren't locked down could get compromised. Firewalled boxes wouldn't. Likewise, the backdoor in Unreal IRCD I alluded to earlier, while potentially disastrous for a machine with no restrictions, wouldn't be a problem for a box with tight security, and the fact it existed for over 6 months (in a well known and well used piece of software) shows that you can't always rely on a fix in a few days.

In ideal conditions security holes would be fixed before they're made public. This rarely happens. A properly setup firewall, for example, would keep you safe in most cases.

Mr_Oink

weegie.geek wrote: »

Even with your example, 12k possible keys, 5 second delay between each brute force attempt, 60k seconds, 1000 minutes, 16 hours on average to get into that particular machine. Fixed packages were released within 3 days, which gives you plenty of time. Scan the hosts, find out which are vulnerable, get to work on individual hosts.

These are unmanaged servers. OS is installed, root password emailed to user. You're on your own as far as security is concerned, and that's fair enough because they're bargain basement stuff. I doubt the other non-premium dedi/colo people do any more in the way of security, and it's always been this way. The old FXP scene is testament to that, the number of zombies in datacentres is testament to that. If bills get paid, the datacentre doesn't care what the box does, as long as it doesn't get any complaints.

I agree that a firewall isn't necessary to restrict access to certain ports by IP, as I agreed previously, but it's handy to have the configuration all in one place.

Keeping software up to date will of course win, assuming there IS an update available. In those 3 days boxes that aren't locked down could get compromised. Firewalled boxes wouldn't. Likewise, the backdoor in Unreal IRCD I alluded to earlier, while potentially disastrous for a machine with no restrictions, wouldn't be a problem for a box with tight security, and the fact it existed for over 6 months (in a well known and well used piece of software) shows that you can't always rely on a fix in a few days.

In ideal conditions security holes would be fixed before they're made public. This rarely happens. A properly setup firewall, for example, would keep you safe in most cases.

Now that, Mr Weggie Geek, is a very good and perceptive post - and a pleasure to read.

S0litaire

weegie.geek wrote: »

Even with your example, 12k possible keys, 5 second delay between each brute force attempt, 60k seconds, 1000 minutes, 16 hours on average to get into that particular machine. Fixed packages were released within 3 days, which gives you plenty of time. Scan the hosts, find out which are vulnerable, get to work on individual hosts.

These are unmanaged servers. OS is installed, root password emailed to user. You're on your own as far as security is concerned, and that's fair enough because they're bargain basement stuff. I doubt the other non-premium dedi/colo people do any more in the way of security, and it's always been this way. The old FXP scene is testament to that, the number of zombies in datacentres is testament to that. If bills get paid, the datacentre doesn't care what the box does, as long as it doesn't get any complaints.

I agree that a firewall isn't necessary to restrict access to certain ports by IP, as I agreed previously, but it's handy to have the configuration all in one place.

Keeping software up to date will of course win, assuming there IS an update available. In those 3 days boxes that aren't locked down could get compromised. Firewalled boxes wouldn't. Likewise, the backdoor in Unreal IRCD I alluded to earlier, while potentially disastrous for a machine with no restrictions, wouldn't be a problem for a box with tight security, and the fact it existed for over 6 months (in a well known and well used piece of software) shows that you can't always rely on a fix in a few days.

In ideal conditions security holes would be fixed before they're made public. This rarely happens. A properly setup firewall, for example, would keep you safe in most cases.

Good reply.

That's why I suggested "fail2ban" since it will block an attacking IP address after 2 failed logins. It gives you an added layer of defense till patches are sent out and systems updated.

weegie.geek

Yeah, if you must have it open to any IP, or a big range of IPs then something like fail2ban would help a lot. You'd need a lot of compromised machines to brute force 12k attempts if you're only allowed 2 failures per IP.

Having said that,

Damballa says its top three botnets are Storm, with 230,000 active members per 24 hour period; Rbot, an IRC-based botnet with 40,000 active members per 24 hour period; and Bobax, an HTTP-based botnet with 24,000 active members per 24 hour period, according to the company.

Even the small one there has enough hosts to manage it. Of course, there are probably easier targets so in reality they probably wouldn't devote so much time to getting into one box.