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 mo
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 si
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.
Jon Passki wrote:
> Has the FreeBSD Secteam tested setting VM_MIN_ADDRESS to some high
> number such as 65536? This does not fix the vulnerability per se, but
> one would hope it stops a user mapping code to 0x0.
>
See the FreeBSD-EN-09:05.null erratum that contains a patch that allows
you to do t
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 sw
Dag-Erling Smørgrav wrote:
'amount' => 2, 'of late' is more figure of speech than anything
else. For me, amount was high enough to get interested and 'of late'
may be because I've not been looking long enough.
A search of FreeBSD security advisories shows two in the last four
years, plus the c
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 in
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 be
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 /usr
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 -p anduin.net
where was either 80 (open) or 8585 (closed).
tcpdump command on firewall (which NATs to internal IPs):
tcpdump -i -p -vvv
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 packet
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 p
Just to put an end to this sillyness :)
A few days ago, I wrote:
For months now, we're all seeing repeated bruteforce attempts on SSH.
I've configured my pf install to ratelimit TCP connections to port 22
and to automatically add IP-addresses that connect too fast to a table
that's filtered:
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
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 which
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 00
Gang,
For months now, we're all seeing repeated bruteforce attempts on SSH.
I've configured my pf install to ratelimit TCP connections to port 22
and to automatically add IP-addresses that connect too fast to a table
that's filtered:
table { }
block quick from to any
pass in quick on $e
17 matches
Mail list logo
