Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Well, to start off, I've been using linux for about three months now, so yes I'm a noob. But anywhoo, on to my concern...I ususally run the chkrootkit once a week, and after running it today, I noticed a strange entry for 'wted':
Code:
Checking `sniffer'... Checking `wted'... 3 deletion(s) between Sat Oct 18 06:41:41 2003 and Sat Aug 24 23:27:31 1968
nothing deleted
As you can see, the deletions were from 2003 and 1968?
Then I checked entering last -aix (btw, this was from googling):
Code:
$ last -aix
roner pts/2 Sun Oct 19 21:59 still logged in 0.0.0.0
roner pts/2 Sun Oct 19 21:55 - 21:58 (00:02) 0.0.0.0
roner pts/0 Sun Oct 19 21:13 still logged in 0.0.0.0
roner :0 Sun Oct 19 21:12 gone - no logout 16.55.1.64
roner pts/0 Sun Oct 19 18:02 - 21:13 (03:10) 0.0.0.0
roner :0 Sun Oct 19 18:02 - 21:12 (03:10) 16.55.1.64
tour pts/0 Sun Oct 19 12:53 - 18:01 (05:08) 0.0.0.0
tour :0 Sun Oct 19 12:53 - 18:01 (05:08) 16.55.1.64
runlevel (to lvl 5) Sun Oct 19 12:52 - 21:59 (09:07) 0.0.0.0
reboot system boot Sun Oct 19 12:52 (09:07) 0.0.0.0
shutdown system down Sun Oct 19 01:05 - 21:59 (20:54) 0.0.0.0
runlevel (to lvl 0) Sun Oct 19 01:05 - 01:05 (00:00) 0.0.0.0
tour pts/0 Sun Oct 19 00:23 - 01:05 (00:41) 0.0.0.0
tour :0 Sun Oct 19 00:23 - 01:05 (00:41) 16.55.1.64
runlevel (to lvl 5) Sun Oct 19 00:21 - 01:05 (00:43) 0.0.0.0
reboot system boot Sun Oct 19 00:21 (00:43) 0.0.0.0
shutdown system down Sat Oct 18 07:46 - 01:05 (17:18) 0.0.0.0
runlevel (to lvl 0) Sat Oct 18 07:46 - 07:46 (00:00) 0.0.0.0
roner pts/0 Sat Oct 18 07:38 - 07:46 (00:07) 0.0.0.0
roner :0 Sat Oct 18 07:38 - 07:46 (00:07) 16.55.1.64
tour pts/0 Sat Oct 18 07:21 - 07:37 (00:16) 0.0.0.0
tour :0 Sat Oct 18 07:21 - 07:37 (00:16) 16.55.1.64
runlevel (to lvl 5) Sat Oct 18 07:20 - 07:46 (00:25) 0.0.0.0
reboot system boot Sat Oct 18 07:20 (00:25) 0.0.0.0
shutdown system down Sat Oct 18 07:19 - 07:46 (00:26) 0.0.0.0
runlevel (to lvl 6) Sat Oct 18 07:19 - 07:19 (00:00) 0.0.0.0
tour pts/0 Sat Oct 18 07:15 - 07:19 (00:03) 0.0.0.0
tour :0 Sat Oct 18 07:14 - 07:19 (00:04) 16.55.1.64
roner pts/1 Sat Oct 18 07:03 - 07:03 (00:00) 0.0.0.0
roner pts/1 Sat Oct 18 06:47 - 07:03 (00:15) 0.0.0.0
roner pts/1 Sat Oct 18 06:45 - 06:45 (00:00) 0.0.0.0
roner pts/0 Sat Oct 18 06:45 - 07:14 (00:29) 0.0.0.0
roner :0 Sat Oct 18 06:44 - 07:14 (00:29) 16.55.1.64
runlevel (to lvl 5) Sat Oct 18 06:43 - 07:19 (00:35) 0.0.0.0
reboot system boot Sat Oct 18 06:43 (00:35) 0.0.0.0
******** **~*C**=nN*S Tue May 21 19:07 - crash (-24723+-18: 39.201.43.166
****[*[8 *.*<***}*<u* Fri Jul 31 00:01 - crash (-13106+00:- 115.122.166.243
**&***W* y*X*+|***'** Tue Apr 18 11:33 - crash (9313+18:10) 67.229.217.185
****`<** **x~***6**8* Fri Dec 18 07:06 - crash (14182+22:37 252.48.148.87
b*HQ***1 *0***#{***9* Mon May 24 08:02 - crash (14025+22:40 51.52.249.247
******qk *G*2w*6*c2*L Thu Jan 21 10:44 - crash (-8496+-5:00 215.237.206.202
G****"** 1*** Thu Nov 15 06:16 - crash (-9525+00:-3 181.109.71.196
****v**Y C7|*5a*}*1** Sun Aug 27 04:12 - crash (19410+02:31 102.117.198.211
******8q U******]*'^" Mon Apr 28 15:44 - crash (-18856+-15: 88.158.165.81
*V*B!*.h ***********i Sun Apr 15 07:01 - crash (-24322+-7:- 161.191.133.224
"*****7* ;****Nu***/P Wed Apr 5 19:43 - crash (-900+-12:-5 212.4.104.122
9**G**9* ***)m*f*Q*** Mon Nov 21 05:36 - crash (-2955+-23:- 15.171.75.226
PRKX*dH* j****[*,"*** Thu Nov 23 10:52 - crash (11285+18:51 156.49.35.249
(3**h**V *****I****** Mon May 10 09:26 - crash (18057+21:17 49.51.154.73
**p*pW** ***,T*b/@*** Sun Aug 30 13:17 - crash (5892+17:26) 4.99.157.30
*l*s*z** H**0^i*V**t* Thu Sep 18 08:16 - crash (29+22:27) 49.75.129.113
**p****6 N*R***H*[*** Thu Jun 21 04:08 - crash (17285+02:35 16.220.40.143
**R|&#@f **=**4w**U*0 Mon Mar 22 11:52 - crash (10070+17:51 155.197.116.48
?**_**)* *r)***!aG*** Wed Apr 12 18:04 - crash (-4925+-11:- 85.140.50.71
******** "***>*&***:) Thu Jul 7 04:03 - crash (9599+02:40) 120.232.6.17
**Jh**** &*C***rD*/*
Mon Nov 27 20:54 - crash (-16147+-21: 169.169.25.79
*@*$**>* **3T**NeM*** Thu Mar 30 13:18 - crash (9332+16:25) 49.162.130.150
**A**v** H*g****9**** Mon Feb 17 08:27 - crash (-3775+-2:-4 79.174.38.26
*/o<C*I* *H**Sj O(*8* Sun Sep 23 05:51 - crash (8791+00:52) 47.9.23.9
***ui*<* q*****8**r** Tue Jul 18 15:24 - crash (5204+15:18) 111.85.253.187
e*2*s*4* gM***.*****a Sun Apr 29 16:54 - crash (-1289+-10:- 181.212.151.113
**y**zF] ***V4*K**%i* Thu Jun 23 09:52 - crash (17648+20:51 230.195.227.136
~*fUi,*5 dY**I**|**S* Tue Jul 29 15:26 - crash (-22966+-15: 140.234.160.164
^**]W**{ v***~;?***** Mon Mar 23 06:34 - crash (-14803+-7:- 67.67.231.42
roner pts/1 Sat Oct 18 06:26 - crash (00:16) 0.0.0.0
roner pts/1 Sat Oct 18 06:25 - 06:26 (00:00) 0.0.0.0
roner pts/1 Sat Oct 18 06:22 - 06:22 (00:00) 0.0.0.0
roner pts/1 Sat Oct 18 06:15 - 06:16 (00:01) 0.0.0.0
I'm not too savey with security, yet, but how can I decipher this? I'm guessing that this has to do something with the file system (reiserfs) or something more simple than that.
I'm not too savey with security, yet, but how can I decipher this?
You can't. It's a binary log of all logins, and the structure isn't, hmm, well, it isn't that rugged, I've seen corruption like this in earlier posts.
BTW, you forgot to mention tho if your box crashed a few times during the period shown, that would help a lot to know.
Call me paranoid, but need I worry?
IMHO paranoia isn't as bad as carelessness. The best thing to do when in doubt is to verify information from other sources and look for things out of the ordinary.
As root, if you run a filesystem integrity scanner, use it to determine the state of /bin and /sbin. Else run your package manager in verify mode against the packages from the install cd's, containing /bin/login (util-linux), ls (fileutils), ps (procps) and netstat (net-tools).
If MD5sums do not match, reboot a rescue cd (don't boot the kernel from disk) and remount the disks read-only before proceeding.
If you've got /var/log/btmp, you could run "lastb -aix" and see recorded bad logins over a period. If you've got /var/log/lastlog, you could run "lastlog" and see a record of users that are/aren't supposed to log in. These two logs could give indications of unwanted activity. Now you should check the system logs and those of networked daemons to see if there are anomalies. Round that off inspecting the contents of your passwd/group/shadow files, configuration files and running package manager in verify mode.
Most likely you'll find nothing at all, and you could then say that doing all of this was a waste of time. On the other hand you know a bit more about you system, nfo that could come in handy later. Time to reboot the box back to "normal" and rotate wtmp, lastlog and btmp logfiles.
Originally posted by unSpawn
You can't. It's a binary log of all logins, and the structure isn't, hmm, well, it isn't that rugged, I've seen corruption like this in earlier posts.
BTW, you forgot to mention tho if your box crashed a few times during the period shown, that would help a lot to know.
From what I can remember, I was trying to copy some files from a burnt CD to my home folder and the dvd-rom was hanging up when accessing it. I did have to kill the file manager, tried to unmount the cd with no success, and ending up rebooting.
Quote:
Originally posted by unSpawn
IMHO paranoia isn't as bad as carelessness. The best thing to do when in doubt is to verify information from other sources and look for things out of the ordinary.
As root, if you run a filesystem integrity scanner, use it to determine the state of /bin and /sbin. Else run your package manager in verify mode against the packages from the install cd's, containing /bin/login (util-linux), ls (fileutils), ps (procps) and netstat (net-tools).
If MD5sums do not match, reboot a rescue cd (don't boot the kernel from disk) and remount the disks read-only before proceeding.
I neglected installing any filesystem scanner during the initial install . Having a look at some filesystem scanners, such as tripwire, it is mentioned that I should install the package immediately after the OS install. So, I'm wondering if it would be feasible to install one now? This is just my "test" box that I play with and learn/make disasters with .
Quote:
Originally posted by unSpawn
If you've got /var/log/btmp, you could run "lastb -aix" and see recorded bad logins over a period. If you've got /var/log/lastlog, you could run "lastlog" and see a record of users that are/aren't supposed to log in. These two logs could give indications of unwanted activity. Now you should check the system logs and those of networked daemons to see if there are anomalies. Round that off inspecting the contents of your passwd/group/shadow files, configuration files and running package manager in verify mode.
Most likely you'll find nothing at all, and you could then say that doing all of this was a waste of time. On the other hand you know a bit more about you system, nfo that could come in handy later. Time to reboot the box back to "normal" and rotate wtmp, lastlog and btmp logfiles.
Sure enough, you were right. I didn't find anything out of the ordinary...no unauthorized logins or discrepancies. The only thing that I have found that might have cause my concern is in the syslog. As mentioned above, it seems like the dvd-rom hanging caused this strange crash log(?).
Oh, this was definitely a good learn/ discovery. I didn't know where all the "nooks and crannies" to start probing. Thanks again for the lesson
I did have to kill the file manager, tried to unmount the cd with no success, and ending up rebooting.
OT, but if your kernel is Sysreq enabled and your box is left in an unusable state, next time try the "ALT+PRNTSCRN+" keycombo: S to sync, U to umount and then B to reboot.
it is mentioned that I should install the package immediately after the OS install. So, I'm wondering if it would be feasible to install one now?
No, it would not. If you still want to install it I'd do this, but it's not a "best practices" thing and I would not recommend it:
- reboot a recue cdr to make sure you're working from a sane system,
- verify all files installed with your package manager against the original packages (not the rpm database) for md5sum differences,
- visually inspect files not in the database wrt their contents and purpose,
and then install and run a filesystem integrity checker and save a copy of the binary and databases to read-only media.
"Then I checked entering last -aix (btw, this was from googling):
code:--------------------------------------------------------------------------------$ last -aix
roner pts/2 Sun Oct 19 21:59 still logged in 0.0.0.0
roner pts/2 Sun Oct 19 21:55 - 21:58 (00:02) 0.0.0.0
roner pts/0 Sun Oct 19 21:13 still logged in 0.0.0.0
roner :0 Sun Oct 19 21:12 gone - no logout 16.55.1.64
roner pts/0 Sun Oct 19 18:02 - 21:13 (03:10) 0.0.0.0
roner :0 Sun Oct 19 18:02 - 21:12 (03:10) 16.55.1.64
tour pts/0 Sun Oct 19 12:53 - 18:01 (05:08) 0.0.0.0
tour :0 Sun Oct 19 12:53 - 18:01 (05:08) 16.55.1.64"
Hello- I just googled the above IP address (16.55.1.64) because it shows up as output of the "last" command on my system (just like the quote from the OP above) and found this thread. When I run:
last -i | grep -F "still logged in"
I get:
mchugh24 pts/2 x.x.x.x Fri Mar 19 08:48 still logged in
mchugh24 :0 16.55.1.64 Thu Mar 18 23:17 still logged in
The 1st entry is correct--it is me sshing into my computer (I took out the real address)--the second is not my IP address, but the time listed is the last time I rebooted and logged back on. The commands "who" "w" and "users" show nothing odd. Neither does chkrootkit.
A whois from the IP address (16.55.1.64) shows that it is from HP. Why is this showing up as me in "last" and why did it show up as well for the guy who started this thread. Very odd.
Interesting. There is/was a similar bug in Redhat where xdm would log a pseudo-random IP address as having logged in when an X session was started. You can checkout the Redhat bugzilla here:
It sounds highly similar to that and would explain why you see it only when the system is rebooted and not during remote ssh sessions. With the Redhat bug, the IP address could vary from system to system, though it was not entirely random and had nothing to do with people trying to crack your box. I was unaware that it was cross-distro and I don't see anything in the Mandrake bugzilla about it. Can someone else running Mandrake 9.1 reproduce this? If not, I might put Mandrake on a spare box over the weekend and see if I can observe the same effect. If i can replicate it, you can probably put a bug report in with Mandrake if you are interested.
I looked at the link and it seems to be identical to what is happening on my machine. I just found out about the "last" command recently so this could have been going on for a year as far as I know.
I rebooted into graphical mode 3 times last night to check and the results were the same. It seemed unlikely that someone could logged into my machine that quickly after each boot, but seeing the strange IP address freaked me out.
Thanks a lot for the information. I will take a shot at reporting this to Mandrake if you find it can be reproduced.
Installed Mandrake 9.2 Download Edition with default settings on a stand-alone system (no network/internet connection). Logged in with system at runlevel 5 (graphical). Affects system regardless of desktop used (occurred with Gnome/KDE/IceWM). Entries do not appear if system is booted into runlevel 3 and X is started manually with startx. Here is the output I get:
Code:
[root@localhost root]# last -aix
<SNIP>
test_user :0 Sun Mar 21 09:04 - down (00:02) 8.71.1.64
runlevel (to lvl 5) Sun Mar 21 09:02 - 09:07 (00:04) 0.0.0.0
reboot system boot Sun Mar 21 09:02 (00:04) 0.0.0.0
shutdown system down Sun Mar 21 09:01 - 09:07 (00:05) 0.0.0.0
test_user :0 Sun Mar 21 08:59 - down (00:02) 8.71.1.64
runlevel (to lvl 5) Sun Mar 21 08:57 - 09:01 (00:03) 0.0.0.0
reboot system boot Sun Mar 21 08:57 (00:03) 0.0.0.0
Note that the format X.X.1.64 seems to be common among the log entries (including the ones in the Redhat bug). If you are interested, go ahead and submit a bug entry with Mandrake here:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
. Having a look at some filesystem scanners, such as tripwire, it is mentioned that I should install the package immediately after the OS install. So, I'm wondering if it would be feasible to install one now? This is just my "test" box that I play with and learn/make disasters with 
.
