Hi!
On Tuesday 05 July 2005 14:00, Daniel Pittman wrote:
> /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535
> --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
> /sbin/iptables -t filter -A out_world_http_s1 -p tcp --sport 80 --dport
> 1024:65535 -m state --state ESTABL
On Tuesday, 5 de July de 2005 14:11, Michael Stone wrote:
> On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote:
> >/sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535
> > --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables -t
> > filter -A out_world_h
Michael Stone wrote:
On Tue, Jul 05, 2005 at 11:57:37PM +1000, Daniel Pittman wrote:
As to trusting the firewall, or not, there has been at least one bug
where attackers could manipulate the content of the conntrack expect
table remotely. Other bugs, local or remote, are not out of the
questi
On Tue, Jul 05, 2005 at 11:57:37PM +1000, Daniel Pittman wrote:
As to trusting the firewall, or not, there has been at least one bug
where attackers could manipulate the content of the conntrack expect
table remotely. Other bugs, local or remote, are not out of the
question.
No they're not. Bu
On 5 Jul 2005, Michael Stone wrote:
> On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote:
>> /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535
>> --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables
>> -t filter -A out_world_http_s1 -p tcp --sport 80
On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote:
/sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
/sbin/iptables -t filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m state --state ESTABLIS
On 5 Jul 2005, Paul Gear wrote:
> Daniel Pittman wrote:
>> ...
>>> So, probably, the best way to go is allowing the R/E packets alongside their
>>> "new state" counterparts. It also clarifies where the packets are accepted
>>> and WHY. Also, "iptables -v" should be a lot more useful than before.
>
Daniel Pittman wrote:
> ...
>>So, probably, the best way to go is allowing the R/E packets alongside their
>>"new state" counterparts. It also clarifies where the packets are accepted
>>and WHY. Also, "iptables -v" should be a lot more useful than before.
>
>
> That was my point, basically. Than
On 5 Jul 2005, Eloi Granado wrote:
> On Sunday, 3 de July de 2005 23:24, Paul Gear wrote:
>> Daniel Pittman wrote:
>>> It also tends to encourage "shortcuts" in the firewall, like accepting
>>> any RELATED/ESTABLISHED packets,
>>
>> Am i right in understanding that you consider accepting
>> RELATED
On Sunday, 3 de July de 2005 23:24, Paul Gear wrote:
> Daniel Pittman wrote:
> > It also tends to encourage "shortcuts" in the firewall, like accepting
> > any RELATED/ESTABLISHED packets,
>
> Am i right in understanding that you consider accepting
> RELATED/ESTABLISHED packets a bad thing?
It sim
Michael Stone wrote:
> On Mon, Jul 04, 2005 at 07:45:47PM +1000, Paul Gear wrote:
>
>> I mustn't be understanding you here. Isn't the very definition of
>> RELATED/ESTABLISHED that the packet is part of an established connection
>> to a service actually used?
>
>
> RELATED and ESTABLISHED are t
On 4 Jul 2005, Paul Gear wrote:
> Daniel Pittman wrote:
>> ...
>>> Am i right in understanding that you consider accepting
>>> RELATED/ESTABLISHED packets a bad thing?
>>
>>
>> No. Accepting *any* RELATED/ESTABLISHED packets is, though, if someone
>> finds an attack to generate entries in the connt
On Mon, Jul 04, 2005 at 07:45:47PM +1000, Paul Gear wrote:
I mustn't be understanding you here. Isn't the very definition of
RELATED/ESTABLISHED that the packet is part of an established connection
to a service actually used?
RELATED and ESTABLISHED are two different things. You've defined
EST
Daniel Pittman wrote:
> ...
>>Am i right in understanding that you consider accepting
>>RELATED/ESTABLISHED packets a bad thing?
>
>
> No. Accepting *any* RELATED/ESTABLISHED packets is, though, if someone
> finds an attack to generate entries in the conntrack table. Like, say,
> the active FTP
On 4 Jul 2005, KC wrote:
[...]
> *nat
> :PREROUTING DROP [0:0]
> :POSTROUTING DROP [0:0]
> :OUTPUT DROP [0:0]
> COMMIT
I thought that using a policy of DROP in the nat tables would result in
anything that wasn't NAT-ed being prevented from passing through by
iptables.
I can't find any documenta
Hi,
My firewall script doesn't have a problem with it's rules it is just
missing something important because when firehol tries it it doesn't give
any significant errors. When I turn on my previous firewall it works fine.
The place I am working in is a remote place where I am just setting up a
ne
On 4 Jul 2005, Paul Gear wrote:
> Daniel Pittman wrote:
>> ...
>> Shorewall, like many firewall packages, gives you[1] a whole bunch of
>> configuration options, which turn on or off features in the pre-packaged
>> firewall you have.
>>
>> This tends to make it hard to do strange things like playin
Daniel Pittman wrote:
> ...
> Shorewall, like many firewall packages, gives you[1] a whole bunch of
> configuration options, which turn on or off features in the pre-packaged
> firewall you have.
>
> This tends to make it hard to do strange things like playing with DSCP
> tagging of packets, or de
On Sun, 03 Jul 2005 12:23:13 +0200, Daniel Pittman <[EMAIL PROTECTED]>
wrote:
Thanks a lot! It was really comprehensive!
And according to what you wrote - I'll stick with shorewall since it does
everything I need and it's easy to manage. On the other hand - I'll start
to learn iptables beca
On 3 Jul 2005, Jakub Sporek wrote:
> On Sun, 03 Jul 2005 05:07:02 +0200, Daniel Pittman <[EMAIL PROTECTED]>
> wrote:
>
>> I found that 'firehol' was quite a surprise to me -- not only didn't it
>> suck, it actually improved my hand-written firewall somewhat.
>
>> Unlike everything else, it doesn't
Daniel Pittman wrote:
> ...
>>>Finally, that is a pretty complex firewall script, and obviously
>>>somewhat hard to maintain. Maybe you would get better value for your
>>>time by using an existing firewall helper like 'firehol', or something,
>>>than re-doing the work that went into the existing t
On Sun, 03 Jul 2005 05:07:02 +0200, Daniel Pittman <[EMAIL PROTECTED]>
wrote:
I found that 'firehol' was quite a surprise to me -- not only didn't it
suck, it actually improved my hand-written firewall somewhat.
Unlike everything else, it doesn't tell you to fill in three values in a
config
Daniel Pittman <[EMAIL PROTECTED]> wrote:
> Sure, a lot of them suck. In fact, most of them *really* suck, in my
> opinion.
>
> I found that 'firehol' was quite a surprise to me -- not only didn't it
> suck, it actually improved my hand-written firewall somewhat.
Firehol still sucks: It's ba
Hi,
I am tring out firehol right now on a fresh optimized version of this
firewall that I decided to make from scratch. The damn thing still won't
work. I know I am missing something important in both these scripts because
in both cases it drops everything and my rules are not functioning at all.
On 3 Jul 2005, KC wrote:
> Daniel Pittman wrote:
>> On 3 Jul 2005, KC wrote:
>>
>>> I need help understanding what goes wrong in this script. I cannot ping
>>> anyone and cannot resolve as well. In fact I believe the only thing I can
>>> get is an ip address from my isp's dhcp server.
[...]
>> I
Hi,
Yes the script is kind of long and tedious in its respects. My initial
purpose was to set this up at a remote facility with around 20 systems. I
have also tried to get info from iptables -L chian, but noticed that the
rules seem to be ok. If people want I can put the output for iptables -L
ch
On 3 Jul 2005, Steve Kemp wrote:
> On Sat, Jul 02, 2005 at 04:46:29PM -0400, KC wrote:
[...]
> One thing did stand out though, you don't allow outgoing connections
> generally. These lines:
>
>> iptables --policy OUTPUT DROP
>> iptables -t nat --policy OUTPUT DROP
>> iptables -t mangle --policy
On 3 Jul 2005, KC wrote:
> I need help understanding what goes wrong in this script. I cannot ping
> anyone and cannot resolve as well. In fact I believe the only thing I can
> get is an ip address from my isp's dhcp server.
With sufficiently modern kernels, the DHCP client uses raw sockets, so
it
On Sat, Jul 02, 2005 at 04:46:29PM -0400, KC wrote:
> I need help understanding what goes wrong in this script. I cannot ping
> anyone and cannot resolve as well. In fact I believe the only thing I can
> get is an ip address from my isp's dhcp server.
There's no way I'm going to read through al
Hi
I need help understanding what goes wrong in this script. I cannot ping
anyone and cannot resolve as well. In fact I believe the only thing I can
get is an ip address from my isp's dhcp server.
Best Regards
kc
## FIREWALL ##
## Symbolic Constants
CONNECTION_TRACKING="1"
LOCAL="eth0"
INTERN
30 matches
Mail list logo
