On Wed, Nov 11, 2015 at 10:00 AM, Per Jessen wrote:

Have you checked with rootkit hunter?

I tried chkrootkit and it found nothing. But I do not think it is a very thorough check.

Check your logs for ssh logins from unknown IP-addresses. If you allow ssh login with password, use fail2ban or firewall to squash brute force attacks.

I think I will investigate removing ssh login with password. I am pretty much the only one using ssh in to this machine, and I have exchanged keys so I do not use a password. But I have not disabled password use. There are always ssh attempts in the system log. Since I do not know from where I will use ssh, it is unclear how I could restrict the attempts. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

I might add that this is an openSUSE 10.0 system. I has been working great. It just runs and runs and runs. All it really does is redirect some ports to internal machines and provide a bit of ftp storage for clients. I have been meaning to update it to a newer openSUSE. In fact, a replacement machine sits in my room. But, if it ain't broken... Of course, our company has an external audit of the state of our internet access, and they have been complaining that they detect this machine is running too old software. Point taken. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Nov 11, 2015 at 1:45 PM, Marcus Rückert wrote:

On Wed, 11 Nov 2015 10:56:45 +0100 Roger Oberholtzer wrote:

...

I might add that this is an openSUSE 10.0 system. I has been working great.

I just stopped reading there. 10.0 is out of maintenance since *years* have it running with any kind of network connectivity is just plain negligent.

Not going to argue this point. Who knows when an exploit is exploited. A week after release? A year? Of course it never happens that exploits are added to newer systems that did not exist in older ones. That could never happen...

You should take the hint and just reinstall the whole machine from scratch and update more regularly.

I agree. Sort of... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/11/2015 04:56 AM, Roger Oberholtzer wrote:

But, if it ain't broken...

Perhaps this is evidence that it is "broken". Perhaps the fact that you are running old software that hasn't been brought up t date to the recent patches is an adequate definition of "broken"? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/11/2015 08:15 AM, Roger Oberholtzer wrote:

On Wed, Nov 11, 2015 at 2:07 PM, Anton Aylward wrote:

...

On 11/11/2015 04:56 AM, Roger Oberholtzer wrote:

...

But, if it ain't broken...

Perhaps this is evidence that it is "broken".

Perhaps the fact that you are running old software that hasn't been brought up t date to the recent patches is an adequate definition of "broken"?

I suspect that the way the Trojan got in was more to do with allowing ssh logins with passwords. This configuration would have been the same with a newer system. Installing a new version will not correct inadequate configuration. I will take blame for that. But I am not convinced about the age of the software leading to this. Especially as this specific trojan does not take advantage of any such that-is-old-and-it-has-been-fixed type of issue. It is more clever. It exploits bad configurations. For which, once again, I take the blame.

I will grant you that bad configurations (which probably includes lack of or weak authentication in its multitudinous forms) is in the top 5 security failings globally. But a walk through the CVE database will also highlight many flaws, including ones in libraries used by otherwise OK applications, that have been fond and addressed. Please note that this also includes the Linux kernel, drivers and networking code. So your "Oh I've fixed the problem with ssh logins with passwords" is good going but inadequate. Rather like saying, on the Titanic, "Oh we've new supplied to lookout with a set of binoculars...". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Nov 11, 2015 at 3:12 PM, Christopher Myers wrote:

Personally, I'm thankful that Roger passed along the information about the trojan.

Thanks for the support. But I am not so easily deterred! As a software developer, I am very much aware of what the 'update to the latest version' statement means. I also know that the latest ain't always the greatest. On the mentioned list of corrections that one can find: when were the mistakes that made the corrections necessary introduce in the first place? More often than not they were introduced in a recent previous update. Of course, software should move towards being better and better. But that ideal is not a guarantee of what happens in reality. But calm down all. I do tend to run recent things almost everywhere. The machine in question has a specific use and has been fine with 10.0. Despite the Trojan. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/11/2015 09:43 AM, Christopher Myers wrote:

That's cool. I'm glad that you're not deterred by it, but I know a lot of folks would be, especially those new to linux. And sometimes the list can get a bit harsh without much reason, which bugs me, since this is where we come to help and be helped.

Sadly, the media is all to happy to see the negative side of things like Linux, and this, I think, is more discouraging than what might happen here since things like The Washington Post already have an aura of 'respectability and hence credibility. http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-k... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2015-11-11 15:50, Anton Aylward wrote:

A long, long time ago, Fredrick P Brooks wrote in a book called "The Mythical Man Month" that each release of the OS/360 had about 200 bugs in it. As software grows we can expect that new generations of programmers, less experienced, will repeat the error of their ancestors. That's certainly been my observation and I think its backed up by the SANS top 20 list of vulnerabilities: Buffer overflow and SQL injection have been to top 2 programming errors for a long time now. You'd think the schools that teach programming would drill such basics into the heads to the students: "DON'T DO THIS", but no..... And so we get cascades of the same kind of errors, thing like mishandling of pointers in C, year after year. In many ways it's inherent in the economics of programming. To keep costs down new, inexperienced and therefore cheap programmers are brought in and older, experienced one go off to do other things. Few firms can afford the intense testing that NASA has for the deep space missions.

:-)

IMHO, many of those bugs, like buffer overflows, would be prevented by phasing out C, and using something else that does compile and run time time bounds checking. C is very powerful, amongst other things, because it allows to do anything you wish, even if it is a mistake. Kind of a very high level assembler. With powerful CPUs we should have the computing power to switch to other languages that do checks. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2015-11-11 16:24, Bernhard Voelker wrote:

On 11/11/2015 04:06 PM, Carlos E. R. wrote:

...

IMHO, many of those bugs, like buffer overflows, would be prevented by phasing out C, and using something else that does compile and run time time bounds checking.

I see it quite different: nowadays, the kids are teached higher level languages like Java etc. which do /much/ work for the programmer. But the effect I'm seeing is that they don't know or even think what's going on under the hood, and that they code sloppily, i.e., they don't care if some code needs 1M or 1G. Especially with Java, I've very often

Well, lets say then that programmers should learn C, and do it good, but then not use it unless really needed. :-) Anyway, I doubt that Java could be a good language. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 11/11/2015 10:24 AM, Bernhard Voelker wrote:

On 11/11/2015 04:06 PM, Carlos E. R. wrote:

...

IMHO, many of those bugs, like buffer overflows, would be prevented by phasing out C, and using something else that does compile and run time time bounds checking.

I see it quite different: nowadays, the kids are teached higher level languages like Java etc. which do /much/ work for the programmer. But the effect I'm seeing is that they don't know or even think what's going on under the hood, and that they code sloppily, i.e., they don't care if some code needs 1M or 1G. Especially with Java, I've very often been disappointed by very bad error handling and messages, i.e., the pro- grammer is tempted to only think about the positive path thru the code, and leaves anything else to an "exception" - hey the whole world is an exception! ;-)

So? Little has changed. Years ago C programmers were rarely taught to check the return codes from system calls/library calls and handle errors. Moving from avionics -- with its rigour - to commercial programming I was often criticised by peers and management for writing code that did all this checking. It slowed down the application and increased the size of the load module. And heck, errors rarely occurred! Right. A real modern language such as Ruby makes exception handling so much easier! So much more natural the Try/Catch style is so easy to use and embed in the lower layers so that the event driven/case driven upper layers can proceed in a declarative fashion. That aids specification-driven generation of code and specification-driven testing. The example of Ruby in this regard has driven other languages to adopt some of these methods, but sadly its not so natural for them, as you point out. All this said: you can screw up and gloriously !FAIL! in any language. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2015-11-11 16:29, Anton Aylward wrote:

On 11/11/2015 10:06 AM, Carlos E. R. wrote:

...

...

:-)

IMHO, many of those bugs, like buffer overflows, would be prevented by phasing out C, and using something else that does compile and run time time bounds checking.

+1

In many ways, PASCAL hid so many signs of this order that it deceived many students and never taught them other good practices; its emphasis on structured programming and scope was good ... for a teaching situation, but became highly criticised when it came down to performance.

You just had to do it right. I wrote an antivirus in turbopascal that was an order of magnitude faster than a commercial antivirus that did the same thing (30S->3S) That performance factor could be because of the runtime checks. I had it always on, except on sections that I had verified for correctness and were critical for speed. The dreaded "range check error" ;-)

When Perl came out I switched to that; realistically I ended up being much more productive and effective as a programmer. Perl is still incredibly powerful! But what the heck, Brooks wrote about the power and effectiveness of HLLs in TMMM.

These days I work mainly in shell and Ruby.

Interesting.

I forget if it was Brooks or Weinbaum who pointed out that as machines got faster, compliers and interpreters got faster as well.

Its one thing to have the low level components in a language that is close to the hardware like C, but that also demands a rigour and testing that few can afford. Sadly that is rarely met.

I cringe at seeing applications in C. Only the kernel should use C. IMHO. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Wed, Nov 11, 2015 at 4:37 PM, Carlos E. R. wrote:

I cringe at seeing applications in C. Only the kernel should use C. IMHO.

We do near real-time programming. It has to happen now. There are no backsies. We also program embedded devices with minimal resources. Once again, C. Are we careful? We certainly try to be. Being the odd guy I might be, when I want scripting, my first response is TCL. Followed by Python. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

On Wed, Nov 11, 2015 at 10:00 AM, Per Jessen wrote:

...

Have you checked with rootkit hunter?

I tried chkrootkit and it found nothing. But I do not think it is a very thorough check.

It's been a logn time since I've had reason to run a check, but it seemed pretty thorough to me: http://rkhunter.sourceforge.net/

I think I will investigate removing ssh login with password. I am pretty much the only one using ssh in to this machine, and I have exchanged keys so I do not use a password. But I have not disabled password use. There are always ssh attempts in the system log. Since I do not know from where I will use ssh, it is unclear how I could restrict the attempts.

fail2ban will help you with that. -- Per Jessen, Zürich (10.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org