Yeah, switching back to standard US Locale&Keyboard settings lets xdmcp deamon disappear
That's a new one to me, but I'm glad we can cross that off the list of weird things now.

I ran chkrootkit several times after thant, and no such or warning alike was to seen anymore, so according to your assumption, this should be just a false alarm.
Short lived files and processes can cause false positives with chrootkit. One of the tests that it performs compares the list of currently running processes to the entries in /proc . If a process is short lived, then it can terminate in between the two parts of the test. This is actually rather normal.

Is the modification and the state of the resolv.conf file a *normal* state?
Modification of /etc/resolve.conf is very normal, as the system will modify the nameservers on boot. Though to my knowledge this file is supposed to be human readable, so to be honest I'm not sure why you would have something like a md5sum or encrypted hash. You might want to check the modification time on the file (use stat /etc/resolv.conf) and see if that coincides with a recent startup time.

The second modification was detected in the directory /etc/certs/cups/, therein the directory /etc/certs/cups/certs and the certificate file /etc/certs/cups/certs/0 were modified.
Again, the cups certifications are created on the fly at startup, so modification is not abnormal. Although versions of CUPS prior 1.1.18 were vulnerable to a race condition where an attacker could use it to overwrite files with root privileges. However, you'd expect to see more file modifications if that had been the case. You can also repeat the check you did with /etc/resolv.conf to see if it was modified at boot.

Also to say it again - all the checks from the chkrootkit, including ifpromisc tell me that nothing is wrong.
Cool. Again, none of these checks can really guarantee that your system is clean, but it certainly starting to sound like the problem was on the windows end of the scan.

Hi ya,
thanks for the helpful posts Capt_Caveman!

Okay, the path looks very *non-standard*, but I'll find it this time.

I've keeping eye on the reports of my Samhain guard so I now know it was a false alarm. Nothing goes sent out without an explicit order (either by start of an application by myself, or by request from some already running application). For about 4 days I won knowledge of what folders and files my SuSE box uses, in which way and in which issue it does so.
I'd say this Samhain system is very, very reliable, very stable and provides great way of knowledge of what goes on in underneath your Linux box.

I run chkrootkit at least once per day, but I trust now my Samhain guard to tell me immediately if something on the system goes off the security rules. I know there's no 100% security, but at least I feel my box safe now...

Further I discovered, that my ADSL provider "provides virtually" the LDAP and the NetMeeting ports (389, 1002 and 1720) to each connection I make through the line, although my iptables settings show that these ports are blocked.

Furthermore I've done little bit *creative* research and have programed a small application that listens on these ports (the app runs on my Linux machine), another small application runs on my work machine and tests these opened ports by sending random packets much more like a hacker would test for exploits. The result was, that no packet has ever reached my listening applications, but all packets sent, were dropped according the iptables security rules (I found the dropped packets in the iptables log files). The conclusion: the ports are really closed, and the reason that I see opened ports is the fact that the ADSL line *fakes* the port scanner (at least these I've tested with - IP Tools, nmap for M$ and nmap for Linux).

Many thanks Capt_Caveman for your help and for your information - the investigation in this issue helped me to learn so many things about the security the Linux box has/should have and some ways to provide it. I also have learned how to avoid security compromises and how to reduce the risk of getting hacked. There's never 100% security of that, but avoiding security compromises help to keep the box healthy over long, long period.

Kind regards,
sbogus