On 08/27/2010 10:32 AM, Vadim Goncharov wrote:
This is a froward message from tcpdump-workers mail list:
=== 8 8 ===
$ sudo ./tcpdump -i any -G 1 -z ./test.sh -w dump port 5
[sudo] password for user:
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
On 08/27/2010 04:27 PM, István wrote:
Well to be honest i don't see any case when i want to give sudo+tcpdump
access to any user on my box. And those who are admins/roots anyway the su
- just works perfectly and they can run tcpdump.
I simply change the permissions on /dev/bpf* so that some
Jamie Landeg Jones wrote:
However, I'd still apply the patch in case some other way to exploit
the non-checking of the unsetenv return status crops up elsewhere.
It can't do any harm.
The problem with that is, on 6.x, unsetenv() returns 'void', so there's
no return value to check on.
On
Julian wrote:
The assumption is that the userland and kernel share a memory map.
While we do implement it this way, it is not necessarily needed.
We do it for performance reasons (each user memory map includes an
identical top section that is the kernel space, so that we do not need
to switch
All,
Given the amount of NULL-pointer dereference vulnerabilities in the
FreeBSD kernel that have been discovered of late, I've started looking
at a way to generically protect against the code execution possibilities
of such bugs.
By disallowing userland to map pages at address 0x0 (and a bit
Dag-Erling Smørgrav wrote:
Given the amount of NULL-pointer dereference vulnerabilities in the
FreeBSD kernel that have been discovered of late,
Specify amount and define of late.
'amount' = 2, 'of late' is more figure of speech than anything else.
For me, amount was high enough to get
Oliver Pinter wrote:
the base system contins 0.9.8e and this PoC is affected up to 0.9.8i
not yet tested
the question is, the freebsd is affected for this error/malware/poc?
http://milw0rm.com/exploits/8873
(term1)
OpenSSL version
OpenSSL 0.9.8e 23 Feb 2007
% openssl s_server -cert
Hi Eirik,
Perform the nmap scan and look at the tcpdump output to see how your
firewall and/or server react.
nmap command:
nmap -PN -sT --scanflags SYNFIN -pport anduin.net
where port was either 80 (open) or 8585 (closed).
tcpdump command on firewall (which NATs to internal IPs):
tcpdump -i
Eirik Øverby wrote:
I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen
FreeBSD servers. Now we're required to run external security scans
(nessus++) on some of the hosts, and they constantly come back with a
high or medium severity problem: The host replies to TCP packets
Stef Walter wrote:
The chroot(2) man page describes a sysctl called
'kern.chroot_allow_open_directories' which controls whether a process
can chroot() and is already subject to the chroot() syscall.
It seems that this sysctl can be trivially changed from within a
chroot'd process (ie: if that
Scot Hetzel wrote:
However, there apparently are SSH bruteforcers that simply use one
connection to perform a brute-force attack:
Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from
83.19.113.122
Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from
83.19.113.122
Aug 18
Lyndon Nerenberg wrote:
Take a look at /usr/ports/security/bruteforceblocker. It monitors the
system log for failed ssh logins, and blocks the sites via pf. It's
reasonably configurable, and works very well. I've been running it for
months without trouble.
I've written a similar script
Constantine A. Murenin wrote:
So, my question is: Does anyone know how this particular attack works
and if there's a way to stop this? If my theory is sound and OpenSSH
does not have provisions to limit the authentication requests per TCP
session, I'd find that an inadequacy in OpenSSH, but I'm
13 matches
Mail list logo
