I copied the binary from a friend's woody box, and ran
f-prot against it, and didn't find anything. I've
included the md5 of hs binary as well.
$ f-prot ./ssh-copy-id
Virus scanning report - 15 January 2004 @ 12:08
F-PROT ANTIVIRUS
Program version: 4.2.1
Engine version: 3.13.4
VIRUS SIGNATURE
I copied the binary from a friend's woody box, and ran
f-prot against it, and didn't find anything. I've
included the md5 of hs binary as well.
$ f-prot ./ssh-copy-id
Virus scanning report - 15 January 2004 @ 12:08
F-PROT ANTIVIRUS
Program version: 4.2.1
Engine version: 3.13.4
VIRUS SIGNATURE
One solution is to use spamassassin, and in your
~/.spamassassin/user_prefs, do the following:
score MICROSOFT_EXECUTABLE 6
Or whatever number you need to get over the default threshold.
Effectively any mail with an identified .exe attachment would gain a
bonus of +6 in spamassasin (in my case I
One solution is to use spamassassin, and in your
~/.spamassassin/user_prefs, do the following:
score MICROSOFT_EXECUTABLE 6
Or whatever number you need to get over the default threshold.
Effectively any mail with an identified .exe attachment would gain a
bonus of +6 in spamassasin (in my case I
Backup /etc and any other data you have, and you can reference your configuration
files later
during your re-install.
At this point, re-installation is a must. Never delude yourself into thinking you can
'recover'
from being rooted. Sure, you might be able to do so after a lot of effort/etc,
Backup /etc and any other data you have, and you can reference your
configuration files later
during your re-install.
At this point, re-installation is a must. Never delude yourself into thinking
you can 'recover'
from being rooted. Sure, you might be able to do so after a lot of effort/etc,
Actually, people have reported that there is an exploit, and in fact even OpenBSD is
vulnerable.
I would still patch ASAP. Best not to risk it.
It's probably a matter of time before a widely available exploit is released. Right
now it seems
it's in the hands of a select few, but that will
Actually, people have reported that there is an exploit, and in fact even
OpenBSD is vulnerable.
I would still patch ASAP. Best not to risk it.
It's probably a matter of time before a widely available exploit is released.
Right now it seems
it's in the hands of a select few, but that will
It may be slightly unpure, but what's wrong with:
chkrootkit -q | grep -vE '(eth[0-9]+:*[0-9]* *is not
promisc)'
That would at least avoid triggering the mail from the
cron job.
Regards,
Josh
--- Kay-Michael Voit [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
DCE
If you compiled and ran the resulting binary before
upgrading your kernel, the isec-ptrace-kmod-exploit
binary may already be set[ug]id, which is a side
effect of running it. Make sure it's not +s and/or
g+s, or better yet just remove it and recompile it.
--- LeVA [EMAIL PROTECTED] wrote:
Hello!
If you compiled and ran the resulting binary before
upgrading your kernel, the isec-ptrace-kmod-exploit
binary may already be set[ug]id, which is a side
effect of running it. Make sure it's not +s and/or
g+s, or better yet just remove it and recompile it.
--- LeVA [EMAIL PROTECTED] wrote:
Hello!
There are a couple of reasons why I use -j DROP
instead of -J REJECT. Firstly, sending responses to
packets your dropping can be bad, given a relatively
small upstream link. In theory, one could DoS you
sufficiently with an upstream equal or slightly better
than yours. That is not to say that the
There are a couple of reasons why I use -j DROP
instead of -J REJECT. Firstly, sending responses to
packets your dropping can be bad, given a relatively
small upstream link. In theory, one could DoS you
sufficiently with an upstream equal or slightly better
than yours. That is not to say that the
Actually, the previous post's usage of netmask would
probably do the trick:
[EMAIL PROTECTED]:~$ netmask -c 1.2.3.1:1.2.3.4
1.2.3.1/32
1.2.3.2/31
1.2.3.4/32
so, e.g.:
for hostmask in `netmask -c 1.2.3.1:1.2.3.4`; do
iptables -A INPUT -s $hostmask -d `ifconfig eth0 |
grep
Actually, the previous post's usage of netmask would
probably do the trick:
[EMAIL PROTECTED]:~$ netmask -c 1.2.3.1:1.2.3.4
1.2.3.1/32
1.2.3.2/31
1.2.3.4/32
so, e.g.:
for hostmask in `netmask -c 1.2.3.1:1.2.3.4`; do
iptables -A INPUT -s $hostmask -d `ifconfig eth0 |
grep
It would be useful to have something that would take
an IP address range and return the minimum coverage
CIDR for that block (for use in feeding to iptables).
For example, if I want to allow access for hosts
1.2.3.1 - 1.2.3.4, I currently can allow them
individually or just allow the entire /24.
It would be useful to have something that would take
an IP address range and return the minimum coverage
CIDR for that block (for use in feeding to iptables).
For example, if I want to allow access for hosts
1.2.3.1 - 1.2.3.4, I currently can allow them
individually or just allow the entire /24.
Having failed to find any information about TCP port 6352 via google or /etc/services,
I
figured I'd ask here. I'm seeing an awful lot of dropped packets on this port recently,
and I'm curious if anyone else has seen this. If so, what purpose does TCP port 6352
serve
(either in the *nix domain
Having failed to find any information about TCP port 6352 via google or
/etc/services, I
figured I'd ask here. I'm seeing an awful lot of dropped packets on this port
recently,
and I'm curious if anyone else has seen this. If so, what purpose does TCP
port 6352 serve
(either in the *nix domain
19 matches
Mail list logo
