I ran 'last -i' and found out that someone has been getting into my computer.

matrix:/var/log # last -i | grep 248
jschiwal :0 248.192.3.64 Fri Feb 25 05:21 - 07:13 (01:52)
blender :0 248.192.3.64 Fri Feb 25 04:58 - 05:20 (00:22)
blender :0 248.192.3.64 Fri Feb 25 04:57 - 04:58 (00:00)
blender :0 248.192.3.64 Fri Feb 25 04:57 - 04:57 (00:00)
blender :0 248.192.3.64 Fri Feb 25 04:56 - 04:56 (00:00)
blender :0 248.192.3.64 Fri Feb 25 03:41 - 04:55 (01:14)
jschiwal :0 248.160.3.64 Sun Feb 20 08:34 - 15:15 (06:40)
jschiwal :0 248.160.3.64 Sun Feb 20 07:56 - down (00:34)
jschiwal :0 248.160.3.64 Sun Feb 20 07:50 - 07:50 (00:00)
jschiwal :0 248.160.3.64 Sun Feb 20 05:40 - 05:40 (00:00)
jschiwal :0 248.160.3.64 Sun Feb 20 05:38 - 05:39 (00:01)
jschiwal :0 248.160.3.64 Sun Feb 20 05:24 - 05:37 (00:13)
jschiwal :0 248.144.3.64 Sat Feb 19 23:43 - 05:17 (05:34)

When I checked where the address is from the addresses both reserved!

I am running SuSE 9.1. The computer is behind a linksys wrt54g cable router. The linksys firewall was enabled. The one port forwarded was ssh. I have just disabled the service.
The SuSEfirewall configuration has ssh and maybe apache enabled. Nothing is now.

I also switched to 'paranoid' security level in YaST and added 'ALL: 248.' to /etc/hosts.deny., as well as changing my passwords.

nmap run.
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2005-03-04 08:17 PST
Host 192.168.1.100 appears to be up ... good.
Initiating SYN Stealth Scan against 192.168.1.100 at 08:17
Adding open port 111/tcp
Adding open port 631/tcp
The SYN Stealth Scan took 1 second to scan 1659 ports.
Interesting ports on 192.168.1.100:
(The 1657 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
111/tcp open rpcbind
631/tcp open ipp

Nmap run completed -- 1 IP address (1 host up) scanned in 1.116 seconds

What do I need to check with PAM and X windows to make sure they are secured?
What have I forgotten?

Forgive me if I sound a bit panicked. I'm finding out that I have a lot to learn about security, and have perhaps forgotten nearly as much.

before you do anything else, it would be a good idea to make sure a rootkit hasn't been installed on your box:

http://www.rootkit.nl/

just my two cents...

jschiwal, I'm disappointed that you're not reading all the threads in the LQ-Sec forum :

http://www.linuxquestions.org/questi...hreadid=297736

It's a known bug and has nuthin' to do with someone cracking your system (though it certainly does make it look like it). Reference linkage:

http://www.linuxquestions.org/questi...573#post830573
https://bugzilla.redhat.com/bugzilla...g.cgi?id=82540
https://bugzilla.redhat.com/bugzilla...g.cgi?id=98659
http://bugs.mandrakelinux.com/query.php?bug=532

wow, that's one weird bug!! what distros are affected??

At least Redhat, Mandrake, and SuSE. But I'd imagine that alot more are as well. Don't think Debian was, but I'm not 100%.

I don't think under these circumstances you think that's a bug. You panic like hell and the most rational thing to do is ask for help, not reading forums wheteher is a bug or not.

AFAIK, the thing about not reading all the threads was just a friendly comment... didn't you notice the smiley???

nobody is saying "you should have searched to see if it was a bug instead of asking for help" or anything like that, relax...

=)

being that mandrake and suse are redhat-based, it would sound like a redhat issue... i wonder if it's fixed in the redhat enterprise linux distro, or fedora 3 for that matter...

this was posted in that bugzilla page you linked:

the last sentence sounds like the problem was fixed or something... maybe it's just a matter of waiting for the fix to propagate to the redhat-based distros??

It was definitely meant as a joke to bring some humor to what is usually a gut-wrenching experience. Jschiwal is a really active member of our community and answers a lot of threads in the Security forum, so it was meant as more of a friendly ribbing. Hopefully no offence was taken.

the last sentence sounds like the problem was fixed or something... maybe it's just a matter of waiting for the fix to propagate to the redhat-based distros??
It's fixed in Fedora Core 3 and I believe in all the Fedora releases, but it might have just been a backported sysvinit patch or something.

Sorry for misunderstanding your sentence in your post above.

Win32..,

Sounds like good advice (post #2). However, since I just purchased SuSE 9.2 for my laptop, I think I'll not take a chance and do a fresh install. I think that my breach may have to do with the wireless router. What is strange is that the incoming table is empty on the router. I wonder if after reinstalling, I should take an old computer and set up a proper dedicated firewall. amd use that as a buffer.

Also, I wasn't sure whether I had the apache server blocked or not, however I just checked now, and the server isn't even running!
---
Update: I ran chkrootkit and installed rkhunter. Thank's for that link. It pointed out a couple warnings about the ssh setup. Some of the checksums were different, so I think a fresh SuSE 9.2 install would be easiest approach.

Hammet, I read through those threads before posting after reading this one http://www.linuxquestions.org/questi...readid=297736.

That seems to pertain to someone using run level 5, and has to do with a bug in xdm if I read those properly. I use run level 3 and use start x. Now perhaps during startx this bug may show up. Also, I don't believe that I was logged in as the 'blender' user when the log indicates.

I thank you for having such faith in me however. The truth is I was more disappointed in myself rather than panicked, because I thought I had a better understanding about security on Linux. With only the ssh service being exposed, and the Sysco firewall, I thought that I was better protected. However, in some areas, I found that I really need to bone up. For example, the PAM setup. Is the reason that xinetd isn't setup by default as of late because PAM_service does the work now. By enabling xinetd to handle incoming requests, did I add another layer of security, or revert to a slightly inferior method.

You can test this rather easily. Disconnect the system from any network connection, reboot and startx. If you see another odd X session appear then you can be pretty sure it's that bug. It's also highly coincidental that one of the dates that the 'IP' appears to change (Feb 25) also happens to be the same date as the most recent kernel update.

I'll give that a try. I've noticed that Feb 25 is the last time it has happened, so your hunch about a kernel upgrade may be correct. I think that if there was an entry point that it is due to wireless. My laptop has both XP and had Mandrake. I had tried changing from WPA w/TKIP to WEP, and that may have left the barndoor wide open. I haven't had time to get back to trying to get the wireless working on the laptop, so I may replace the router in the meantime with my old one.

Since it hasn't happened in the last 8 days, the experiment may not produce a result. A security update in the meantime may of fixed the problem, or the hacker is on vacation.

I'm curious about the IP address however. Does that indicate that the hacker (if there is one) is a local wireless user, and this is his Local IP address. Since 240. -> 254 are reserved IP addresses, would an internet router drop any packets from such an address?

Since I purchased SuSE 9.2 for my laptop, I think I'll perform a fresh install on my desktop just to be safe. I'm just afraid I've done something in the past that I haven't found yet. At one time I was looking at Xwin32 on my laptop, but I didn't find a configuration file for xauth.

Thank you for your help.

The IP isn't routable, so an attacker would need to enter over the LAN side (likely via the wireless). WEP is basically only good for discouraging the casual wardriver and a determined attacker could gain accesss to your LAN rather quickly. That being said, the likelihood of someone living within signal range of your 802.11 AP and being capable of cracking both WEP and your firewalled SuSE box is pretty low. On top of that, then seeing them establish a remote desktop session that pukes their IP all over the place would be pretty surprising. Though it is possible and would be even more so if the logs have been forged. Though I still don't think that's the case.

Obviously reinstalling is always going to be the safest option if you choose to go that way. You might want to keep it off the network for a little while after the install and see if you see IPs showing up in the last -i output again.

As a personal note, if you took the comment I made earlier in any way but humorous, I sincerely apologize.

Out of curiousity, what does last -d produce?