On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote:
>Confirmed - synproxy works great if the synproxy machine is the
> default gateway for the end host.
Yes, PF has to handle every packet of a synproxy'd connection.
> Sadly this means scalability (adding multiple synproxy boxes) is not
Confirmed - synproxy works great if the synproxy machine is the
default gateway for the end host. Sadly this means scalability (adding
multiple synproxy boxes) is not possible, nor is it possible to filter a
specific IP out of the end machines ranges.
Perhaps I'm shooting for the moon
On 28 July 2010 20:39, Greg Hennessy wrote:
>
> > What disadvantages does it have in term of security in comparison with
> > "block all"? In other words, how bad it is to have all outgoing ports
> always
> > opened and whether someone can use this to hack the sysem?
> >
>
> It's the principle of
(forgot to cc freebsd-pf sorry)
Ahh. That explains it then. I was operating under the assumption that
the machine doing the synproxy would forge the reply such that the
TARGET host would reply to the synproxy box, not its default gateway.
As in 1.2.3.4 request to client 5.5.5.5 via -> 2.3.4
Logged to files and dumped;
Outside:
19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF],
proto TCP
(6), length 52)
REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0xb15f
(correct), se
q 3641874856, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK],
length 0
On 7/28/10 2:55 PM, Spenst, Aleksej wrote:
Hi All,
I have to provide for my system better security and I guess it would be better to start pf.conf
with the "block all" rule opening afterwards only those incoming and outcoming ports that
are supposed to be used by the system on external interfa
On Wed, Jul 28, 2010 at 01:04:42PM -0700, Justin wrote:
> Logged to files and dumped;
>
> Outside:
> 19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF],
> proto TCP
> (6), length 52)
> REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0xb15f
> (correct), se
> q 364187
Logged to files and dumped;
Outside:
19:58:09.571810 IP (tos 0x0, ttl 118, id 12726, offset 0, flags [DF],
proto TCP
(6), length 52)
REMOTE_CLIENT.56270 > TARGET_HOST.80: Flags [S], cksum 0xb15f
(correct), se
q 3641874856, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK],
length 0
> What disadvantages does it have in term of security in comparison with
> "block all"? In other words, how bad it is to have all outgoing ports always
> opened and whether someone can use this to hack the sysem?
>
It's the principle of 'least privilege'. Explicitly allow what is permitted,
de
It's all about layers of defense, and whether the reduced convenience is
worthwhile.
Limiting outbound traffic from your system is a hassle, but I like to
think about this scenario:
Suppose an attacker did manage to find an exploitable method on your
system, and was able to open up a shell. What
On Wed, Jul 28, 2010 at 2:55 PM, Spenst, Aleksej
wrote:
> Hi All,
>
> I have to provide for my system better security and I guess it would be
> better to start pf.conf with the "block all" rule opening afterwards only
> those incoming and outcoming ports that are supposed to be used by the syste
Hi All,
I have to provide for my system better security and I guess it would be better
to start pf.conf with the "block all" rule opening afterwards only those
incoming and outcoming ports that are supposed to be used by the system on
external interfaces. However, it would be easier for me to w
On Wed, Jul 28, 2010 at 03:23:57AM +0200, Kristian Kræmmer Nielsen wrote:
> As of time being, we still include pf as of OpenBSD 4.1 (released May 2007).
>
> Recently syntax has changed a lot in the releases of pf in OpenBSD 4.7,
> just notice that "nat-to" and "rtr-to" are now part of the
> pass
On Tue, Jul 27, 2010 at 07:24:56PM -0700, Justin wrote:
> - tcpdumps showing the initial connect attempt (logs below were
> furhter along the process);
>
> external:
> 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF],
> proto TCP
> (6), length 52)
> REMOTE_VIEWING_HOST
14 matches
Mail list logo
