[00:14] <jdstrand> ScottK: big thanks for taking care of 0.95.1 :)
[00:14] <ScottK> jdstrand: Thanks.  Glad I could find the time to squeeze it in.
[00:14] <jdstrand> ScottK: I actually added the CVEs to our tracker when they came through last week, and updated the USN
[00:15] <jdstrand> (but yeah, not in the changelog)
[00:15] <ScottK> jdstrand: OK.  There's one or two more from 0.95.1.
[00:16]  * jdstrand nods
[00:17] <jdstrand> I'll get to those next week
[00:18] <ScottK> jdstrand: One of the Debian guys is going to have a look at it tomorrow, so I may have something before then.
[00:34] <jdstrand> ah, great :)
[02:50] <Polk`> !hammertime
[06:15] <cemc> is there a way to install exim without removing postfix ?
[06:15] <cemc> 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] <lamont> cemc: that is according to policy.  you get at most one MTA
[06:17] <cemc> I see. no way around that?
[06:17] <lamont> it would violate policy if you could.  so that'd be a "no, you can't do that"
[06:17] <lamont> 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] <cemc> got it
[06:23] <ScottK> The one true answer is you really want to keep postfix.
[06:23] <ScottK> ;-)
[06:25] <cemc> I know that :)
[06:25] <cemc> just wanted to do some exim testing, without removing postfix
[06:25] <cemc> but I guess it only removes the package, not the config, so it's good
[06:26] <cemc> 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] <lamont> 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] <ScottK> Multiple IPs could solve the port 25 problem, but not sendmail.
[06:28] <lamont> yeah
[06:29] <cemc> you have sendmail.postfix and sendmail.exim, and you have sendmail pointing to one or the other, like with alternatives ?
[06:30] <lamont> cemc: yeah - except for the part where debian policy says that the MTA will provides/conflicts/replaces: mail-transport-agent
[06:30] <cemc> ehe :)
[06:31] <cemc> too bad, but no biggie ;)
[06:35] <cemc> 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] <twb> That would be called setting up a routing table
[08:56] <twb> Yes, you an do it.
[08:57] <twb> *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?
[10:39] <twb> Can I remotely drop a machine into single user mode and straight back out again?
[10:39] <twb> 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] <bootsandall> 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?
[11:21] <twb> bootsandall: assuming that atd/crond aren't stopped as part of the single-user shutdown :-)
[11:21] <twb> As it happens, "telinit 1" is ignored just like shutdown (which amounts to telinit 0).
[11:22] <twb> 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] <twb> *innards
[19:27] <ZipmaO^> Hi
[19:27] <ZipmaO^> Is there some way to track a user accounts shell command history?
[19:28] <ZipmaO^> 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] <ropetin> ZipmaO^: they probably covered their tracks, but what about the .bash_history file in their home directory?
[19:35] <ZipmaO^> the account had /bin/sh shell at the moment
[19:35] <ZipmaO^> non-
[19:35] <ropetin> So as far as I know, no, there is no way to get a list of their commands
[19:35] <ZipmaO^> and was not admin
[19:35] <ZipmaO^> ok
[19:36] <ZipmaO^> can i search for files with a specific ownership?
[19:36] <ZipmaO^> I found files that I think they created in /var/tmp/.www/
[19:36] <cemc> ZipmaO^: try 'man find', and search for -uid, -user
[19:36] <ropetin> yup, find would be good, combined with grep
[19:37] <ZipmaO^> ok, really thanks for the help
[19:37] <cemc> 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] <cemc> well this actually will find directories too, see -type
[19:38] <ZipmaO^> I didn't mind much when I noticed that someone logged in as the account when I ran "lastlog"
[19:38] <ZipmaO^> so I changed the shell then to /bin/false to prevent it again
[19:38] <ZipmaO^> But earlier today I noticed in syslog that somekind of cron-job was running every minute
[19:39] <cemc> oops :) sounds like you got hacked, or something ;0
[19:39] <ZipmaO^> found it in the hacked accounts crontab and it led me to /var/tmp/.www/
[19:39] <ZipmaO^> yep..
[19:39] <ZipmaO^> well the accound had the same name as passwd
[19:42] <ZipmaO^> Kinda scary but I guess I don't have to worry that much since the acc isn't in the sudoers list?
[19:45] <cemc> weell...
[19:45] <cemc> you _really_ want to check everything, you never know
[19:47] <yann2> ZipmaO^ > check /tmp, often stuff in there :)
[19:50] <ZipmaO^> ok, will do :)
[19:50] <ZipmaO^> Thanks for the help guys
[20:23] <cjwatson> 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] <ZipmaO> Cjwatson, I don't really understand the term "local root escalation" ?
[21:11] <andol> 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] <ZipmaO> how would that be possible?
[21:13] <ZipmaO> Or more important: what to check?
[21:13] <ZipmaO> admin group, sudoers list, user shells?
[21:13] <ZipmaO> running daemons processes?
[21:49] <ZipmaO> noone?
[21:51] <mattt> hello
[21:52] <mattt> what's the question
[21:53] <cemc> 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] <ZipmaO> ok.
[21:54] <ZipmaO> I see
[21:54] <cemc> the smartest thing to do is probably a clean install,
[21:54] <cemc> but if not... you have check everything
[21:54] <ZipmaO> probably less efficient
[21:54] <ZipmaO> I don't have that much configuration on the server
[21:54] <cemc> not sure how is it done on ubuntu, but on redhat I did a rpm -Va, that checked every rpm installed,
[21:55] <cemc> every package for changes, then I went over the list of changes etc
[21:55] <cemc> check crontab, check stuff in /etc, users, change passwords, firewall ssh, let nobody in ;)
[21:55] <ZipmaO>  I just ran "sudo find / -ignore_readdir_race -user *****"
[21:56] <ZipmaO> just the files that I talked about earlier /var/tmp/.www/
[21:56] <ZipmaO> seemed like a script hack that installed an IRC-bot
[21:57] <cemc> mhm
[21:57] <mattt> ZipmaO: what was the file ownership of those files?
[21:57] <cemc> probably apache
[21:57] <cemc> ;)
[21:57] <mattt> yeah :)  check for mambo/phpbb/etc.
[21:57] <ZipmaO> all the files in that folder matched ownership of the username
[22:25] <ZipmaO> found some more files now..
[22:25] <ZipmaO> /proc/5303
[22:25] <ZipmaO> what are those folders used for?
[22:27] <cemc> proc/<pid>/ contains info about that process which is running and has that process ID
[22:27] <cemc> do a ps ax |grep 5303
[22:27] <cemc> and you'll see what process that is
[22:28] <cemc> better yet, do 'ps axu |grep 5303', so you can see the user the process is running as
[22:49] <ZipmaO> ok
[22:49] <ZipmaO> thanks cmec
[22:49] <ZipmaO> the hacked user owns that catalouge
[22:50] <ZipmaO> root      5303  3.0  0.2  13680  4860 ?        S    22:19   2:43 /usr/sbin/smbd -D
[22:50] <ZipmaO> Doesn't seem weird since it's a samba user
[22:50] <ZipmaO> ?
[22:51] <cemc> what did you find in /proc/5303 exactly
[22:51] <ZipmaO> sec..
[22:54] <ZipmaO> well.. quite many folders and files
[22:54] <ZipmaO> weird thing though, ran the find command again
[22:54] <ZipmaO> and didn't report any files under /proc this time
[23:01] <ZipmaO> Well well..
[23:01] <ZipmaO> Guess I'll do an reinstall asap
[23:02] <ZipmaO> just to be sure..
[23:03] <cemc> yep, that's probably the best thing