[00:14] ScottK: big thanks for taking care of 0.95.1 :) [00:14] jdstrand: Thanks. Glad I could find the time to squeeze it in. [00:14] ScottK: I actually added the CVEs to our tracker when they came through last week, and updated the USN [00:15] (but yeah, not in the changelog) [00:15] jdstrand: OK. There's one or two more from 0.95.1. [00:16] * jdstrand nods [00:17] I'll get to those next week [00:18] jdstrand: One of the Debian guys is going to have a look at it tomorrow, so I may have something before then. [00:34] ah, great :) [02:50] !hammertime [02:50] Sorry, I don't know anything about hammertime === kraut_ is now known as kraut === tonyyaru1so is now known as tonyyarusso === ScottK2 is now known as ScottK === twb` is now known as twb [06:15] is there a way to install exim without removing postfix ? [06:15] when I do an apt-get install exim, it automatically wants to remove postfix, but I'd like to keep postfix on too [06:16] cemc: that is according to policy. you get at most one MTA [06:17] I see. no way around that? [06:17] it would violate policy if you could. so that'd be a "no, you can't do that" [06:17] of course, you could run the other inside of a VM or even a chroot, but then you get to decide which one listens on port 25, and which one fails [06:19] got it [06:23] The one true answer is you really want to keep postfix. [06:23] ;-) [06:25] I know that :) [06:25] just wanted to do some exim testing, without removing postfix [06:25] but I guess it only removes the package, not the config, so it's good [06:26] policy is kinda strange tho :) why can't I have more than one MTAs if I can handle the conf, or I have multiple IPs, or whatever [06:28] cemc: tell me how you'll have more than one daemon listening on port 25, and I'll tell you how to have policy allow multiple MTAs (oh, and make /usr/sbin/sendmail point to both MTAs while you're at it) [06:28] Multiple IPs could solve the port 25 problem, but not sendmail. [06:28] yeah [06:29] you have sendmail.postfix and sendmail.exim, and you have sendmail pointing to one or the other, like with alternatives ? [06:30] cemc: yeah - except for the part where debian policy says that the MTA will provides/conflicts/replaces: mail-transport-agent [06:30] ehe :) [06:31] too bad, but no biggie ;) [06:35] did I say something wrong? :)) [08:42] * |Sigma| waves [08:45] <|Sigma|> is there any way to setup a VPN server so only a certain subnet gets routed through it, and everything else gets routed to a DNS server? [08:56] That would be called setting up a routing table [08:56] Yes, you an do it. [08:57] *can [08:58] <|Sigma|> great, routing table, thanks for the key word, I've been trying to figure this out for a while [09:00] <|Sigma|> so in this case, I could get away with setting up the table on the vpn server and then setting up the clients to send all traffic through the VPN, correct? === asac_ is now known as asac [10:39] Can I remotely drop a machine into single user mode and straight back out again? [10:39] ls /proc/NNNN/ hangs, and similar problems with the process table, but I don't want to drive out there and do a hard reboot. A soft reboot doesn't work, it just ignored my "shutdown -r now" [10:52] I'm a bit new to linux, but I guess you could set up a cron job to bring it back to multi user mode in 5 minutes? === maxb_ is now known as maxb [11:21] bootsandall: assuming that atd/crond aren't stopped as part of the single-user shutdown :-) [11:21] As it happens, "telinit 1" is ignored just like shutdown (which amounts to telinit 0). [11:22] I would like to blame upstart for this, but honestly it's more likely to be the mangling that openvz has done to the kernel's innars. [11:22] *innards === apachelogger_ is now known as apachelogger === MenZa_ is now known as MenZa === jdstrand_ is now known as jdstrand [19:27] Hi [19:27] Is there some way to track a user accounts shell command history? [19:28] I have e useracc that I used for samba and therefore had a trivial password. The account was hacked from ssh and now I want to know what they did [19:34] ZipmaO^: they probably covered their tracks, but what about the .bash_history file in their home directory? [19:35] the account had /bin/sh shell at the moment [19:35] non- [19:35] So as far as I know, no, there is no way to get a list of their commands [19:35] and was not admin [19:35] ok [19:36] can i search for files with a specific ownership? [19:36] I found files that I think they created in /var/tmp/.www/ [19:36] ZipmaO^: try 'man find', and search for -uid, -user [19:36] yup, find would be good, combined with grep [19:37] ok, really thanks for the help [19:37] something along the lines of: find . -user 'foo' (find all the files with owner foo in the current directory and below, aka recursive) [19:38] well this actually will find directories too, see -type [19:38] I didn't mind much when I noticed that someone logged in as the account when I ran "lastlog" [19:38] so I changed the shell then to /bin/false to prevent it again [19:38] But earlier today I noticed in syslog that somekind of cron-job was running every minute [19:39] oops :) sounds like you got hacked, or something ;0 [19:39] found it in the hacked accounts crontab and it led me to /var/tmp/.www/ [19:39] yep.. [19:39] well the accound had the same name as passwd [19:42] Kinda scary but I guess I don't have to worry that much since the acc isn't in the sudoers list? [19:45] weell... [19:45] you _really_ want to check everything, you never know [19:47] ZipmaO^ > check /tmp, often stuff in there :) [19:50] ok, will do :) [19:50] Thanks for the help guys [20:23] ZipmaO^: unfortunately, local root escalation is one of the more common categories of vulnerabilities, so I'd second the suggestion to check everything very carefully indeed [21:07] Cjwatson, I don't really understand the term "local root escalation" ? [21:11] ZipmaO: Basically a vulnerability which allows a local non-root user to gain root status. It doesn't have to be a regular user, it can also be a system user, running one of your daemons. [21:12] how would that be possible? [21:13] Or more important: what to check? === MianoSM1 is now known as mianosm1 === mianosm1 is now known as MianoSM1 [21:13] admin group, sudoers list, user shells? [21:13] running daemons processes? === jussi01 is now known as android === android is now known as jussi01 [21:49] noone? [21:51] hello [21:52] what's the question [21:53] ZipmaO: that's the problem... what to check... if there was an exploit and the hacker gained root access, he could've hid a backdoor, or something bad like anywhere... [21:54] ok. [21:54] I see [21:54] the smartest thing to do is probably a clean install, [21:54] but if not... you have check everything [21:54] probably less efficient [21:54] I don't have that much configuration on the server [21:54] not sure how is it done on ubuntu, but on redhat I did a rpm -Va, that checked every rpm installed, [21:55] every package for changes, then I went over the list of changes etc [21:55] check crontab, check stuff in /etc, users, change passwords, firewall ssh, let nobody in ;) [21:55] I just ran "sudo find / -ignore_readdir_race -user *****" [21:56] just the files that I talked about earlier /var/tmp/.www/ [21:56] seemed like a script hack that installed an IRC-bot [21:57] mhm [21:57] ZipmaO: what was the file ownership of those files? [21:57] probably apache [21:57] ;) [21:57] yeah :) check for mambo/phpbb/etc. [21:57] all the files in that folder matched ownership of the username [22:25] found some more files now.. [22:25] /proc/5303 [22:25] what are those folders used for? [22:27] proc// contains info about that process which is running and has that process ID [22:27] do a ps ax |grep 5303 [22:27] and you'll see what process that is [22:28] better yet, do 'ps axu |grep 5303', so you can see the user the process is running as === andresmujica2 is now known as andresmujica [22:49] ok [22:49] thanks cmec [22:49] the hacked user owns that catalouge [22:50] root 5303 3.0 0.2 13680 4860 ? S 22:19 2:43 /usr/sbin/smbd -D [22:50] Doesn't seem weird since it's a samba user [22:50] ? [22:51] what did you find in /proc/5303 exactly [22:51] sec.. [22:54] well.. quite many folders and files [22:54] weird thing though, ran the find command again [22:54] and didn't report any files under /proc this time [23:01] Well well.. [23:01] Guess I'll do an reinstall asap [23:02] just to be sure.. [23:03] yep, that's probably the best thing === asac_ is now known as asac