Re: Distributed SSH attack
On Fri, Oct 02, 2009 at 05:17:59PM -0400, Greg Larkin wrote: You could set up DenyHosts and contribute to the pool of IPs that are attempting SSH logins on the Net: http://denyhosts.sourceforge.net/faq.html#4_0 While I am well aware that a lot of people use DenyHosts or some equivalent tool, I've always been somewhat skeptical about these tools. Few issues: 1. Firewalls should generally be as static as is possible. There is a reason why high securelevel prevents modifications to firewalls. 2. Generally you do not want some parser to modify your firewall rules. Parsing log entries created by remote unauthenticated users as root is never a good idea. 3. Doing (2) increases the attack surface. 4. There have been well-documented cases where (3) has opened opportunities for both remote and local DoS. Two cents, as they say, Jukka. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
Hi, On 3 Oct 2009, at 09:13, Jukka Ruohonen wrote: While I am well aware that a lot of people use DenyHosts or some equivalent tool, I've always been somewhat skeptical about these tools. Few issues: 1. Firewalls should generally be as static as is possible. There is a reason why high securelevel prevents modifications to firewalls. 2. Generally you do not want some parser to modify your firewall rules. Parsing log entries created by remote unauthenticated users as root is never a good idea. 3. Doing (2) increases the attack surface. 4. There have been well-documented cases where (3) has opened opportunities for both remote and local DoS. Two cents, as they say, Jukka. Blackhole routes can be added as an alternative to tweaking firewall rules. The other objections (esp. 3) still apply of course, but these attacks are such a PITA (noise in the logs if nothing else) that one has to do something. -- Bob Bishop r...@gid.co.uk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
2009/10/3 Jukka Ruohonen jruoho...@iki.fi On Fri, Oct 02, 2009 at 05:17:59PM -0400, Greg Larkin wrote: You could set up DenyHosts and contribute to the pool of IPs that are attempting SSH logins on the Net: http://denyhosts.sourceforge.net/faq.html#4_0 While I am well aware that a lot of people use DenyHosts or some equivalent tool, I've always been somewhat skeptical about these tools. Few issues: 1. Firewalls should generally be as static as is possible. There is a reason why high securelevel prevents modifications to firewalls. 2. Generally you do not want some parser to modify your firewall rules. Parsing log entries created by remote unauthenticated users as root is never a good idea. 3. Doing (2) increases the attack surface. 4. There have been well-documented cases where (3) has opened opportunities for both remote and local DoS. Two cents, as they say, Jukka. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org simplest this to do is disable password auth, and use key based. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Distributed SSH attack
On Sat, 3 Oct 2009, krad wrote: simplest this to do is disable password auth, and use key based. Your logs are still full of crap though. I find sshguard works well, and I am fairly sure you couldn't spoof a valid TCP connection through pf sanitising so it would be difficult (nigh-impossible?) for someone to cause you to block a legit IP. If you can, changing the port sshd runs on is by far the simplest work around. Galling as it is to have to change stuff to work around malicious assholes.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: sx locks and memory barriers
2009/9/29 John Baldwin j...@freebsd.org:
On Tuesday 29 September 2009 4:42:13 pm Attilio Rao wrote:
2009/9/29 Max Laier m...@love2party.net:
On Tuesday 29 September 2009 17:39:37 Attilio Rao wrote:
2009/9/25 Fabio Checconi fa...@freebsd.org:
Hi all,
looking at sys/sx.h I have some troubles understanding this comment:
* A note about memory barriers. Exclusive locks need to use the same
* memory barriers as mutexes: _acq when acquiring an exclusive lock
* and _rel when releasing an exclusive lock. On the other side,
* shared lock needs to use an _acq barrier when acquiring the lock
* but, since they don't update any locked data, no memory barrier is
* needed when releasing a shared lock.
In particular, I'm not understanding what prevents the following
sequence
from happening:
CPU A CPU B
sx_slock(data-lock);
sx_sunlock(data-lock);
/* reordered after the unlock
by the cpu */
if (data-buffer)
sx_xlock(data-lock);
free(data-buffer);
data-buffer = NULL;
sx_xunlock(data-lock);
a = *data-buffer;
IOW, even if readers do not modify the data protected by the lock,
without a release barrier a memory access may leak past the unlock (as
the cpu won't notice any dependency between the unlock and the fetch,
feeling free to reorder them), thus potentially racing with an exclusive
writer accessing the data.
On architectures where atomic ops serialize memory accesses this would
never happen, otherwise the sequence above seems possible; am I missing
something?
I think your concerns are right, possibly we need this patch:
http://www.freebsd.org/~attilio/sxrw_unlockb.diff
However speaking with John we agreed possibly there is a more serious
breakage. Possibly, memory barriers would also require to ensure the
compiler to not reorder the operation, while right now, in FreeBSD, they
just take care of the reordering from the architecture perspective.
The only way I'm aware of GCC offers that is to clobber memory.
I will provide a patch that address this soon, hoping that GCC will be
smart enough to not overhead too much the memory clobbering but just
try to understand what's our purpose and servers it (I will try to
compare code generated before and after the patch at least for tier-1
architectures).
Does GCC really reorder accesses to volatile objects? The C Standard seems
to
object:
5.1.2.3 - 2
Accessing a volatile object, modifying an object, modifying a file, or
calling
a function that does any of those operations are all side effects,11) which
are changes in the state of the execution environment. Evaluation of an
expression may produce side effects. At certain specified points in the
execution sequence called sequence points, all side effects of previous
evaluations shall be complete and no side effects of subsequent evaluations
shall have taken place. (A summary of the sequence points is given in annex
C.)
Very interesting.
I was thinking about the other operating systems which basically do
'memory clobbering' for ensuring a compiler barrier, but actually they
often forsee such a barrier without the conjuction of a memory
operand.
I think I will need to speak a bit with a GCC engineer in order to see
what do they implement in regard of volatile operands.
GCC can be quite aggressive with reordering even in the face of volatile. I
was recently doing a hack to export some data from the kernel to userland
that used a spin loop to grab a snapshot of the contents of a structure
similar to the method used in the kernel with the timehands structures. It
used a volatile structure exposed from the kernel that looked something
like:
struct foo {
volatile int gen;
/* other stuff */
};
volatile struct foo *p;
do {
x = p-gen;
/* read other stuff */
y = p-gen;
} while (x != y x != 0);
GCC moved the 'y = ' up into the middle of the '/* read other stuff */'.
I eventually had to add explicit memory clobbers to force GCC to not
move the reads of 'gen' around but do them around all the other
operations, so that the working code is:
do {
x = p-gen;
asm volatile( ::: memory);
/* read other stuff */
asm volatile( ::: memory);
y = p-gen;
} while (x != y x != 0);
The situation was not so desperate as I first thought.
Actually, only ia32 and amd64 seems affected by the missing of memory
clobbering because it is already done for all the other platform when
using all the memory barriers.
On ia32 and amd64 too, the impact is more limited than what I
expected. atomic_cmpset_* already clobbers the memory and only
atomic_store_rel_* is not adeguately
How to prevent 64bit library paths being searched for 32bit binaries on amd64?
I've just been trying to get a 32bit binary to work on amd64 7.0-RELEASE, the binary had some qt4 dependencies so I set about copying these into /usr/local/lib32 but it seems that for some reason /usr/local/lib is searched first which obviously causes problems when here is a 64bit library of the same name. /etc/rc.d/ldconfig start shows:- ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/mysql /usr/local/lib/pth 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32 /usr/local/lib32/mysql /usr/local/lib32/qt4 LD_LIBARY_PATH isn't set So the question is why is /usr/local/lib searched for a 32bit binary? Is it possible the binary itself is setting it and if so how to I override it? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
