Re: sysadmin in training
Michael Lazin writes: > SInce Ossec HIDS is GNU Public licensed I think this is not a bad idea to > include this in the documentation. The referenced article does describe > securing Debian with open source tools and I honestly have seen this > documentation for the first time tonight and I think it is very high > quality. The thing that caught my eye is disabling execution for /tmp. I I don't know about the current state, but I did disable execution for /tmp at some point, only to discover that installing some packages failed because of this. Although I don't remember, if it was the package or apt-get/dpkg needing an executable /tmp. > managed thousands of Debian servers at one time and I often found hacker > scripts in ./tmp because of a Wordpress exploit. This is because /tmp is > world writable and presumably people who don't know better are unlikely to > look for bad scripts there.
Re: crontab failure for daylight savings
Billy Naylor [EMAIL PROTECTED] writes: It appears that cronjobs running between 2am and 3am sunday morning seem to not have been run, i'm in New Zealand which went into summer daylight savings over the weekend. If you go to daylight savings, the clock jumps from 2am to 3am. So, there's no way how these jobs can run, because for example 2:37am doesn't exist. The reverse happens, when you go back from daylight savings to regular time: the clock jumps from 3am to 2am. This means, all jobs between 2am and 3am run twice. I don't know, wether some cron implementation compensates for daylight savings. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: crontab failure for daylight savings
Billy Naylor [EMAIL PROTECTED] writes: It appears that cronjobs running between 2am and 3am sunday morning seem to not have been run, i'm in New Zealand which went into summer daylight savings over the weekend. If you go to daylight savings, the clock jumps from 2am to 3am. So, there's no way how these jobs can run, because for example 2:37am doesn't exist. The reverse happens, when you go back from daylight savings to regular time: the clock jumps from 3am to 2am. This means, all jobs between 2am and 3am run twice. I don't know, wether some cron implementation compensates for daylight savings. Regards, Olaf.
Re: Simple e-mail virus scanner
Hi, [EMAIL PROTECTED] writes: Does the same approach could be use with sendmail ? Any examples? I guess, you could integrate this in http://www.spamassassin.org. SpamAssassin already scans the email body for signs of spam, so it shouldn't be too hard, to add another regex. Although, I never did this myself. I just use SpamAssassin out of the box with procmail. There's already a sendmail milter at http://savannah.nongnu.org/projects/spamass-milt/ http://www.mimedefang.org/ is another milter for sendmail, which uses SpamAssassin. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Simple e-mail virus scanner
Hi, Игорь Ляпин [EMAIL PROTECTED] writes: Does the same approach could be use with sendmail ? Any examples? I guess, you could integrate this in http://www.spamassassin.org. SpamAssassin already scans the email body for signs of spam, so it shouldn't be too hard, to add another regex. Although, I never did this myself. I just use SpamAssassin out of the box with procmail. There's already a sendmail milter at http://savannah.nongnu.org/projects/spamass-milt/ http://www.mimedefang.org/ is another milter for sendmail, which uses SpamAssassin. Regards, Olaf.
Re: snmp packets
ulrich berthold [EMAIL PROTECTED] writes: SCAN Proxy (8080) attempt the next outstanding alarm message was a SNMP public access udp. i looked into it and to my surprise found out, that these packages are originating on the server's external interface and going to two (nonexistent) privat ip addresses 10.0.1.80 and 10.1.0.80, about every other hour. i ngrepped the packages and [...] any hint on how i can find out which process is sending these out? might it be the hardware (networkcard) itself? If it's about every hour, I would look into the crontabs, wether there's an entry around that time. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: snmp packets
ulrich berthold [EMAIL PROTECTED] writes: SCAN Proxy (8080) attempt the next outstanding alarm message was a SNMP public access udp. i looked into it and to my surprise found out, that these packages are originating on the server's external interface and going to two (nonexistent) privat ip addresses 10.0.1.80 and 10.1.0.80, about every other hour. i ngrepped the packages and [...] any hint on how i can find out which process is sending these out? might it be the hardware (networkcard) itself? If it's about every hour, I would look into the crontabs, wether there's an entry around that time. Regards, Olaf.
Re: capabilities
Adam ENDRODI [EMAIL PROTECTED] writes: -- Problem 3: I'd like to grant or revoke capabilities to/from a running process. This seems to be the easiest, except that the kernel in the default configuration doesn't permit this (cap_bound doesn't contain CAP_SETPCAP which is requirement of a succesful capset() where the target is not the current process. The simplies workaround would be to set CAP_SETPCAT in cap_bound (requires to recompile the kernel, for cap_bset cannot be extended by anyone except pid == 1 (init)). However, I don't see clearly the implications this modification would cause, and I don't really want to risk it. I did this some time ago with a simple wrapper script around init: ---8--cut here--- #! /bin/sh if test $$ -eq 1; then mount /proc echo -1 /proc/sys/kernel/cap-bound fi exec /sbin/init.bin $@ ---cut here--8--- Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: capabilities
Adam ENDRODI [EMAIL PROTECTED] writes: -- Problem 3: I'd like to grant or revoke capabilities to/from a running process. This seems to be the easiest, except that the kernel in the default configuration doesn't permit this (cap_bound doesn't contain CAP_SETPCAP which is requirement of a succesful capset() where the target is not the current process. The simplies workaround would be to set CAP_SETPCAT in cap_bound (requires to recompile the kernel, for cap_bset cannot be extended by anyone except pid == 1 (init)). However, I don't see clearly the implications this modification would cause, and I don't really want to risk it. I did this some time ago with a simple wrapper script around init: ---8--cut here--- #! /bin/sh if test $$ -eq 1; then mount /proc echo -1 /proc/sys/kernel/cap-bound fi exec /sbin/init.bin $@ ---cut here--8--- Regards, Olaf.
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
Robert Ebright [EMAIL PROTECTED] writes: I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the Nearly every MTA out there has a - more or less compatible - sendmail interface. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: odd process running /usr/sbin/sendmail -i -CronDaemon -odi -oem root
Robert Ebright [EMAIL PROTECTED] writes: I have had some problems with attempted hacks on my box and posted here the last few days. So I've been checking the processing running on my box and I see this. PID TTY STAT TIME COMMAND 28406 ?S 0:00 /usr/sbin/sendmail -i -FCronDaemon -odi -oem root I have postfix installed, and I'm not sure if this is a normal thing, or else a rogue process, or just a cron job that got stuck. As around the Nearly every MTA out there has a - more or less compatible - sendmail interface. Regards, Olaf.
Re: Advice Needed On Recent Rootings
Jayson Vantuyl [EMAIL PROTECTED] writes: Thankfully, we don't have root passwords. In our space, we find root to more of a concept than a user, so we disable the password and set up a group that can su to root. That way we have a good handle on things. Root never logs in, so we know somethings up if we see that. Also, if it is hacked from a su-able user, we get a log of that too. I highly recommend this set up (although it wasn't enough in our case :). Just curious, how do you su to root, if root's password is disabled? Do you have a modified su replacement? Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice Needed On Recent Rootings
Jayson Vantuyl [EMAIL PROTECTED] writes: Thankfully, we don't have root passwords. In our space, we find root to more of a concept than a user, so we disable the password and set up a group that can su to root. That way we have a good handle on things. Root never logs in, so we know somethings up if we see that. Also, if it is hacked from a su-able user, we get a log of that too. I highly recommend this set up (although it wasn't enough in our case :). Just curious, how do you su to root, if root's password is disabled? Do you have a modified su replacement? Regards, Olaf.
Re: Disabling netstat
Brian McGroarty [EMAIL PROTECTED] writes: So far as I can tell, there's no non-hackish way to accomplish what I'd like. I have to either hold a file open to make chmod changes stay in effect in /proc, or I have to patch the kernel. This sure seems kind of silly... why add all these things into Big Giant Namespace and not honor all of the conventions of the same? I think /proc/* not supporting chmod changes for the duration of a system's uptime could be classified as a bug or a major design flaw. :/ I guess it was just an oversight. Nobody needed it and nobody complained. But I did a patch against 2.5 to honor chmod and chown in procfs. Maybe you can adapt it to 2.4. The patch is available at: http://groups.google.com/groups?selm=87zntm8cq8.fsf%40goat.bogus.local Regards, Olaf.
Re: smtp auth
Arnold J. Fischer [EMAIL PROTECTED] writes: I'm trying to set up my dial-up system for mail relaying via mx.freenet.de and they are using smtp-auth to accept every mail from someone who has an email-account on their system. I read a couple of articles about the configuration of postfix and set up /etc/postfix/main.cf with all mentioned parameters and options. Postfix is seat up to reconfigure via the pon/poff scripts. I have no idea why, but when I'm examing the mail-relay with telnet mx.freenet.de 25 and an EHLO linux.example.com it seems to me, as in the log file excerpt that they are using smtp-auth. But I the only thing I'm seeing is No mechs available and no connection. The box is a Debian 3.0r1. The attachment is a piece of from /var/log/mail.log Any ideas?! I don't know about postfix, but with sendmail I had a similar message. It went away after installing libsasl-digestmd5-plain and/or libsasl-modules-plain. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: smtp auth
Arnold J. Fischer [EMAIL PROTECTED] writes: I'm trying to set up my dial-up system for mail relaying via mx.freenet.de and they are using smtp-auth to accept every mail from someone who has an email-account on their system. I read a couple of articles about the configuration of postfix and set up /etc/postfix/main.cf with all mentioned parameters and options. Postfix is seat up to reconfigure via the pon/poff scripts. I have no idea why, but when I'm examing the mail-relay with telnet mx.freenet.de 25 and an EHLO linux.example.com it seems to me, as in the log file excerpt that they are using smtp-auth. But I the only thing I'm seeing is No mechs available and no connection. The box is a Debian 3.0r1. The attachment is a piece of from /var/log/mail.log Any ideas?! I don't know about postfix, but with sendmail I had a similar message. It went away after installing libsasl-digestmd5-plain and/or libsasl-modules-plain. Regards, Olaf.
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: At 23:29 Uhr +0100 08.03.2003, Olaf Dietsche wrote: Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? No, this is still a directory generally used for local tar.gz installs. And sbin is for admins, bin for users, right?. Yup, I misinterpreted, what you mean with /local-admin's-software/bin. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? Regards, Olaf.
Re: Permissions on /root/
Christian Jaeger [EMAIL PROTECTED] writes: At 23:29 Uhr +0100 08.03.2003, Olaf Dietsche wrote: Christian Jaeger [EMAIL PROTECTED] writes: I began working with (unix/)linux.) And as written in my other reply I'm still missing a better alternative to /root/bin. /local-admin's-software/bin maybe? AFAIK, the FHS does not provide any. Maybe /usr/local/sbin is, what you're looking for? No, this is still a directory generally used for local tar.gz installs. And sbin is for admins, bin for users, right?. Yup, I misinterpreted, what you mean with /local-admin's-software/bin. Regards, Olaf.
Re: X Security Issues?
Edward Guldemond [EMAIL PROTECTED] writes: Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ ) Interesting ports on (removed) (XX.XX.XXX.XX): (The 1552 ports scanned but not shown below are in state: closed) Port State Service 22/tcp openssh 1024/tcp openkdm [...] Port State Service 22/tcp openssh [...] Port State Service 22/tcp openssh 6000/tcp openX11 You can see open ports with netstat -atuw, too. Now, is there any security implications of having this port open? (I am nmap'ing this box's external Internet interface as it is my ipmasq box.) If so, what files do I have to edit to get rid of it? I don't need X listening on this interface. This depends on the startup method (and maybe distribution), as you already noticed. With xdm (and debian) it is /etc/X11/xdm/Xservers. With xinit it is /etc/X11/xinit/xserverrc. Look at man xinit and man Xserver. There you will find an option -nolisten. When this is your firewall, you might consider stopping X11 and not using this as a desktop machine at all. Every program running and every tool installed, might be used by an attacker against you. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Security Issues?
Edward Guldemond [EMAIL PROTECTED] writes: On Wed, Nov 20, 2002 at 12:53:27AM +0100, Olaf Dietsche wrote: Look at man xinit and man Xserver. There you will find an option -nolisten. In /etc/X11/xinit/xserverrc, I have the following line: exec /usr/bin/X11/X -dpi 100 -nolisten tcp So why is X still listening on TCP? Well, it seems I should heed my own advice ;-). man xinit doesn't mention xserverrc, maybe this is a debian thing. But it does mention $HOME/.xserverrc; try to link or copy /etc/X11/xinit/xserverrc to your home dir as .xserverrc and start xinit again. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X Security Issues?
Edward Guldemond [EMAIL PROTECTED] writes: Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ ) Interesting ports on (removed) (XX.XX.XXX.XX): (The 1552 ports scanned but not shown below are in state: closed) Port State Service 22/tcp openssh 1024/tcp openkdm [...] Port State Service 22/tcp openssh [...] Port State Service 22/tcp openssh 6000/tcp openX11 You can see open ports with netstat -atuw, too. Now, is there any security implications of having this port open? (I am nmap'ing this box's external Internet interface as it is my ipmasq box.) If so, what files do I have to edit to get rid of it? I don't need X listening on this interface. This depends on the startup method (and maybe distribution), as you already noticed. With xdm (and debian) it is /etc/X11/xdm/Xservers. With xinit it is /etc/X11/xinit/xserverrc. Look at man xinit and man Xserver. There you will find an option -nolisten. When this is your firewall, you might consider stopping X11 and not using this as a desktop machine at all. Every program running and every tool installed, might be used by an attacker against you. Regards, Olaf.
Re: X Security Issues?
Edward Guldemond [EMAIL PROTECTED] writes: On Wed, Nov 20, 2002 at 12:53:27AM +0100, Olaf Dietsche wrote: Look at man xinit and man Xserver. There you will find an option -nolisten. In /etc/X11/xinit/xserverrc, I have the following line: exec /usr/bin/X11/X -dpi 100 -nolisten tcp So why is X still listening on TCP? Well, it seems I should heed my own advice ;-). man xinit doesn't mention xserverrc, maybe this is a debian thing. But it does mention $HOME/.xserverrc; try to link or copy /etc/X11/xinit/xserverrc to your home dir as .xserverrc and start xinit again. Regards, Olaf.
Re: port 16001 and 111
Jussi Ekholm [EMAIL PROTECTED] writes: Olaf Dietsche olaf.dietsche#[EMAIL PROTECTED] wrote: Jussi Ekholm [EMAIL PROTECTED] writes: So, what would try to connect to my system's port 16001 and 111 from within my own system? Should I be concerned? Should I expect the worst? Any insight on this issue would calm me down... Port 111 is used by portmap. If you don't use RPC services, you can stop it. I don't use it on my desktop machine. Try rpcinfo -p to see, wether there's anything running on your computer. Well, at least knowingly I don't use any RPC services. :-) And this is what 'rpcinfo -p' gives me: rpcinfo: can't contact portmapper: RPC: Remote system error \ - Connection refused (I split it in two lines) The same answer as a luser and as a root. What should I deduct from this? It's just so weird as I'm not running NFS, NIS or any other thingie that should use this port... This means portmap isn't running. Connection refused means nothing listens on port 111. So, whatever is trying to contact port 111, there's no reason to be concerned. This could be valid requests from programs trying to contact NIS before DNS, however. Look at /etc/nsswitch.conf, wether NIS is mentioned. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
Jussi Ekholm [EMAIL PROTECTED] writes: Olaf Dietsche [EMAIL PROTECTED] wrote: Jussi Ekholm [EMAIL PROTECTED] writes: So, what would try to connect to my system's port 16001 and 111 from within my own system? Should I be concerned? Should I expect the worst? Any insight on this issue would calm me down... Port 111 is used by portmap. If you don't use RPC services, you can stop it. I don't use it on my desktop machine. Try rpcinfo -p to see, wether there's anything running on your computer. Well, at least knowingly I don't use any RPC services. :-) And this is what 'rpcinfo -p' gives me: rpcinfo: can't contact portmapper: RPC: Remote system error \ - Connection refused (I split it in two lines) The same answer as a luser and as a root. What should I deduct from this? It's just so weird as I'm not running NFS, NIS or any other thingie that should use this port... This means portmap isn't running. Connection refused means nothing listens on port 111. So, whatever is trying to contact port 111, there's no reason to be concerned. This could be valid requests from programs trying to contact NIS before DNS, however. Look at /etc/nsswitch.conf, wether NIS is mentioned. Regards, Olaf.
Re: port 16001 and 111
Hi there (from Germany), Jussi Ekholm [EMAIL PROTECTED] writes: So, what would try to connect to my system's port 16001 and 111 from within my own system? Should I be concerned? Should I expect the worst? Any insight on this issue would calm me down... Port 111 is used by portmap. If you don't use RPC services, you can stop it. I don't use it on my desktop machine. Try rpcinfo -p to see, wether there's anything running on your computer. Regards, Olaf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
Hi there (from Germany), Jussi Ekholm [EMAIL PROTECTED] writes: So, what would try to connect to my system's port 16001 and 111 from within my own system? Should I be concerned? Should I expect the worst? Any insight on this issue would calm me down... Port 111 is used by portmap. If you don't use RPC services, you can stop it. I don't use it on my desktop machine. Try rpcinfo -p to see, wether there's anything running on your computer. Regards, Olaf.
Re: Named daemon and port 32770? (and port 32985 on restart)
Javier Fernández-Sanguino Peña [EMAIL PROTECTED] writes: Is the first open port reasonable? I wonder why named is listening on UDP port 32770 which, after a brief google search, comes up as a port usually used by Solaris' rpcbind (which used to be vulnerable). IIRC, this port (could be any 32xxx) is for replies from other name servers. Regards, Olaf.
