search for: drosihn

Yo All! Well I work on a diverse number of OS's with a diverse number of clients. Some use F-Secure, SecureCRT, PuTTY, SSH.COM. OpenSSH, etc. with a wide variety of versions between each, some from source, some from rpms, etc... Basically a lot of legacy stuff that no one has the time to update. In fact I am working on a couple of OpenSSH config problems in the last few days. Sometimes we

All: I'm posting this to FreeBSD-security (rather than FreeBSD-net) because the problems I'm seeing appear to have been caused by spyware, and because they constitute a possible avenue for denial of service on FreeBSD machines with default installs of the operating system. Several of the FreeBSD machines on our network began to act strangely during the past week. Some have started to

I'm trying to get nessus setup for doing some internal security checking. I installed the ports for nessus and nessus-plugins, and everything worked as expected. I then registered for the full feed of plugins, which got me up to over 10,000 plugins. I restarted nessus, and it didn't work at all. I am running without X11, so I'm doing batch runs. I already have nmap installed, so I

I have a test 4.x-stable system that I recently rebooted into. The last time I had updated it was May 3rd. I cvsup'ed it, did the buildworld/installworlds, and everything seemed fine. I then thought I would update all the ports. When upgrading XFree86, the /usr partition ran out of disk space. Now the partition shows up as: (21) df -k Filesystem 1K-blocks Used Avail Capacity

i am invoking op from a python proggy which does an op.system() of op chmod 640 /usr/local/etc/tac_plus.conf i get "Permission denied by op" % ls -l /usr/local/etc/op.access -r-------- 1 root wheel 149 Jan 13 07:41 /usr/local/etc/op.access % cat /usr/local/etc/op.access # 2007.01.13 # #DEFAULT users=src # chown /usr/sbin/chown $* ; users=src chmod /bin/chmod $* ; users=src

Hi folks, While investigating OpenBSD's cron implementation, I found that they set the systemwide crontab (a.k.a. /etc/crontab) to be readable by the superuser only. The attached patch will bring this to FreeBSD by moving crontab out from BIN1 group and install it along with master.passwd. This change should not affect the current cron(1) behavior. Cheers, -- Xin LI <delphij frontfree

Dear FreeBSD users and system administrators, While the FreeBSD Security Team has traditionally been very good at investigating and responding to security issues in FreeBSD, this only solves half of the security problem: Unless users and administrators of FreeBSD systems apply the security patches provided, the advisories issued accomplish little beyond alerting potential attackers to the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On October 31st, FreeBSD 5.3 and FreeBSD 5.4 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Users of either of those FreeBSD releases are strongly encouraged to upgrade to FreeBSD 5.5 or FreeBSD 6.1 before that date. In addition, the FreeBSD 6.0 End of Life is presently scheduled