On Sat, Jan 05, 2013 at 11:57:10AM +, Mick wrote
>
> It will, but only partially. It seems that the list is long and it
> is getting longer and longer! Check this out:
>
> whois -h whois.radb.net -- '-i origin AS32934' | grep ^route
>
> (as advised by https://developers.facebook.com/docs/A
On Jan 4, 2013 8:33 PM, "Walter Dnes" wrote:
>
> On Fri, Jan 04, 2013 at 03:27:59PM -0500, Michael Mol wrote
> > On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes
wrote:
> > >
> > > The mere fact that you haven't manually typed in...
> > > http://www.facebook.com/blah_blah_blah does not mean you're n
On Fri, Jan 04, 2013 at 03:27:59PM -0500, Michael Mol wrote
> On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes wrote:
> >
> > The mere fact that you haven't manually typed in...
> > http://www.facebook.com/blah_blah_blah does not mean you're not
> > connecting to it.
>
> But all that's above layer 3
On Fri, Jan 4, 2013 at 3:17 PM, Walter Dnes wrote:
> On Wed, Jan 02, 2013 at 11:32:58PM -0500, Michael Orlitzky wrote
>> On 12/30/2012 10:21 PM, Walter Dnes wrote:
>> > [0:0] -A FECESBOOK -j LOG --log-prefix "FECESBOOK:" --log-level 6
>> > [0:0] -A FECESBOOK -j DROP
>> > [0:0] -A INPUT -s 192.168.
On Wed, Jan 02, 2013 at 11:32:58PM -0500, Michael Orlitzky wrote
> On 12/30/2012 10:21 PM, Walter Dnes wrote:
> > [0:0] -A FECESBOOK -j LOG --log-prefix "FECESBOOK:" --log-level 6
> > [0:0] -A FECESBOOK -j DROP
> > [0:0] -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT
> > [0:0] -A INPUT -s 169.254
On 12/30/2012 10:21 PM, Walter Dnes wrote:
> [0:0] -A FECESBOOK -j LOG --log-prefix "FECESBOOK:" --log-level 6
> [0:0] -A FECESBOOK -j DROP
> [0:0] -A INPUT -s 192.168.123.248/29 -i eth0 -j ACCEPT
> [0:0] -A INPUT -s 169.254.0.0/16 -i eth0 -j ACCEPT
> [0:0] -A INPUT -i lo -j ACCEPT
> [0:0] -A INPUT
On Jan 3, 2013 4:40 AM, "Michael Orlitzky" wrote:
>
> On 12/30/12 22:21, Walter Dnes wrote:
> > OK, here is version 2. I had "an excellent adventure" along the way.
> >
>
> I'm doing the upgrade on our servers right now, and there's another
> possible gotcha: the newer iptables (requiring connt
On 12/30/12 22:21, Walter Dnes wrote:
> OK, here is version 2. I had "an excellent adventure" along the way.
>
I'm doing the upgrade on our servers right now, and there's another
possible gotcha: the newer iptables (requiring conntrack) requires
NETFILTER_XT_MATCH_CONNTRACK support in the kern
OK, here is version 2. I had "an excellent adventure" along the way.
* At the very last line (COMMIT), iptables-restore said it failed, but
no clue whatsoever as to why.
* I copied the rules file to a scratch-file, and converted it to a bash
script that called iptables each time.
* This m
> > 2) Does a "-j LOG" return to the chain it was called from, or does it do
> > an implicit DROP?
> >
>
> It returns to spot where it was called from.
>
>
Yep, so you could create a new chain to drop and log;
/sbin/iptables -N logdrop
/sbin/iptables -A logdrop -j LOG --log-prefix 'DROP '
/sbin/ipt
On 12/29/2012 01:32 PM, Walter Dnes wrote:
> Two questions I'm not sure about.
>
> 1) I run a desktop, and use passive ftp. Is there any need for me to
> accept RELATED packets?
>
Probably not, I think the server needs it though.
> 2) Does a "-j LOG" return to the chain it was called from,
On 29-Dec-12 19:32, Walter Dnes wrote:
1) I run a desktop, and use passive ftp. Is there any need for me to
accept RELATED packets?
No, but you must take care of related connections. Even passive
ftp opens command (>1023 -> 21) and data (>1023 -> >1023) channel.
BTW, icmp-error (i.e. host unr
Two questions I'm not sure about.
1) I run a desktop, and use passive ftp. Is there any need for me to
accept RELATED packets?
2) Does a "-j LOG" return to the chain it was called from, or does it do
an implicit DROP?
--
Walter Dnes
I don't run "desktop environments"; I run useful applicati
Walter Dnes wrote:
On Fri, Dec 28, 2012 at 01:07:11AM -0500, Michael Orlitzky wrote
On 12/27/2012 10:59 PM, Walter Dnes wrote:
Here's my revised "Paranoia Plus" ruleset. Any comments? Because I'm
behind a NAT-ing ADSL router/modem, many of my rules rarely see hits.
However, I do have a bac
On Fri, Dec 28, 2012 at 01:07:11AM -0500, Michael Orlitzky wrote
> On 12/27/2012 10:59 PM, Walter Dnes wrote:
> >
> > Here's my revised "Paranoia Plus" ruleset. Any comments? Because I'm
> > behind a NAT-ing ADSL router/modem, many of my rules rarely see hits.
> > However, I do have a backup d
I'm sure I made more than one typo, but the ALLOWED_ICMP below
definitely needs a dollar sign.
>
> for ok_icmp in ALLOWED_ICMP; do
> iptables -A ICMP_IN -p icmp --icmp-type "${ok_icmp}" -j ACCEPT
> done
>
On 12/27/2012 10:59 PM, Walter Dnes wrote:
>
> Here's my revised "Paranoia Plus" ruleset. Any comments? Because I'm
> behind a NAT-ing ADSL router/modem, many of my rules rarely see hits.
> However, I do have a backup dialup connection in case of problems, so
> most of my rules don't specify t
On Thu, Dec 27, 2012 at 06:50:07PM -0500, Michael Orlitzky wrote
> Once you've upgraded, you should be able to add all of your old --state
> rules normally, albeit with a warning. The new iptables will translate
> them to conntrack rules, and you can `/etc/init.d/iptables save` the result.
>
> Th
On 12/27/2012 06:11 PM, Walter Dnes wrote:
> On Thu, Dec 27, 2012 at 11:28:15AM +, Graham Murray wrote
>
>> The problem is not really the OP's fault. The problem is that if you
>> have tables with the form "-m state --state XXX" at the point you
>> upgrade, iptables-save (quite possibly called
On Thu, Dec 27, 2012 at 11:28:15AM +, Graham Murray wrote
> The problem is not really the OP's fault. The problem is that if you
> have tables with the form "-m state --state XXX" at the point you
> upgrade, iptables-save (quite possibly called automatically by
> /etc/init.d/iptables stop) wil
On 12/27/12 12:52, Matthias Hanft wrote:
> Michael Orlitzky wrote:
>>
>> My first -m state rule is,
>>iptables -A INPUT -p ALL -m state \
>> --state ESTABLISHED,RELATED -j ACCEPT
>
> That was mine, too (you can omit -p in this case, can't you?).
Yeah, it just makes the indentation line u
Michael Orlitzky wrote:
My first -m state rule is,
iptables -A INPUT -p ALL -m state \
--state ESTABLISHED,RELATED -j ACCEPT
That was mine, too (you can omit -p in this case, can't you?).
And if what you say is true, I'd be in deep shit if it reset to,
iptables -A INPUT -p ALL -m
On 12/27/12 06:28, Graham Murray wrote:
> Michael Orlitzky writes:
>
>> The 'conntrack' module is supposed to be a superset of 'state', so most
>> things should be compatible. You really have two warnings there; the
>> first is for the state -> conntrack switch, and the second is because
>> you'r
Michael Orlitzky writes:
> The 'conntrack' module is supposed to be a superset of 'state', so most
> things should be compatible. You really have two warnings there; the
> first is for the state -> conntrack switch, and the second is because
> you're missing the --state flag in your rules.
>
> In
On 12/26/2012 07:47 PM, Walter Dnes wrote:
> Many years ago, I understood IPCHAINS, and the first versions of
> IPTABLES. However, IPTABLES has followed the example of Larry Wall's
> Practical Extraction and Reporting Language
> and turned into a pseudo-OS that I barely comprehend. Some rules
>
Many years ago, I understood IPCHAINS, and the first versions of
IPTABLES. However, IPTABLES has followed the example of Larry Wall's
Practical Extraction and Reporting Language
and turned into a pseudo-OS that I barely comprehend. Some rules
that I added many years ago were designed to reject
26 matches
Mail list logo
