headers
Max Kellermann | 1 Mar 2005 01:20

Re: new REBOOT target

On 2005/02/28 10:41, Wang Jian <lark <at> linux.net.cn> wrote:
> Beside my laziness, the --passphrase is an error-proof mechanism per
> se.  Let's assume some one wants to use -j REBOOT, but he doesn't
> specified a good enough match, just '-p icmp', then boom ;) In this
> sense, the --passphrase is not match, but part of target.

(my first reply to you didn't get to the list, maybe a mailman
failure?)

Now what about an error proof admin? ;)

Sorry, I don't think this is a good argument, don't try to find an
excuse for writing a dangerous rule (and for writing such a netfilter
"design violation"). If an admin is brave enough to compile REBOOT
into the kernel and write "-j REBOOT" somewhere, it's his own fault he
didn't implement the correct match. Someone with root access should
know better.

REBOOT should ... reboot! Not match the protocol or a certain pass
phrase.

Max
Permalink | Reply | 3 comments |
headers
Tobias DiPasquale | 1 Mar 2005 03:39
Picon

Re: new REBOOT target

On Mon, 28 Feb 2005 10:06:35 +0100, Max Kellermann <max <at> duempel.org> wrote:
> On 2005/02/26 15:30, Wang Jian <lark <at> linux.net.cn> wrote:
> > # iptables -I INPUT -p icmp -j REBOOT --passphrase pass [--offset offset]
> > [--hard (0|1)]
> 
> Ugly hack for an ugly problem ;) - still, it's an interesting idea for
> people plagued with such a problem.

I agree.

> You have implemented the "--passphrase" parameter in your REBOOT
> target, but that "--passphrase" is in fact a match, not a target
> parameter. Targets should not perform a test on the packet, it's not
> their task (it should not assume the packet is ICMP either, that drops
> a lot of flexibility). You should implement this part as a match
> module.
> 
> Maybe someone has already written such a module.. look at
> patch-o-matic.

They have; its called ipt_string. Use that in conjunction with the
attached code to implement the functionality you require.

> In contrary, "--hard" is not a match, it controls what REBOOT should
> do in detail, so this is one ok.

Agreed; --hard stuck around for this.

--

-- 
[ Tobias DiPasquale ]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wang Jian | 1 Mar 2005 06:10
Picon

Re[2]: new REBOOT target

Hi Tobias DiPasquale,

Thanks for your improvement :)

A note for sendreboot.pl's -I parameter: it is used on multihome host, so
no need to remove it.

Note for ipt_REBOOT.c: KERN_ERROR should be KERN_ERR. But I think check
() should emit KERN_WARNING as other targets do but not KERN_ERR.

With ipt_string, it has no --offset parameter, which can be hazardous
for -j REBOOT in case the passphrase is short. Adding --offset may also give
a little of performance boost to string match.

Will ipt_string go into 2.6 mainline?

PS: Is there any possibility that REBOOT target goes into POM or
mainline? Anyway this toy is trivial :D

On Mon, 28 Feb 2005 21:39:40 -0500, Tobias DiPasquale <codeslinger <at> gmail.com> wrote:

> On Mon, 28 Feb 2005 10:06:35 +0100, Max Kellermann <max <at> duempel.org> wrote:
> > On 2005/02/26 15:30, Wang Jian <lark <at> linux.net.cn> wrote:
> > > # iptables -I INPUT -p icmp -j REBOOT --passphrase pass [--offset offset]
> > > [--hard (0|1)]
> > 
> > Ugly hack for an ugly problem ;) - still, it's an interesting idea for
> > people plagued with such a problem.
> 
> I agree.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wang Jian | 1 Mar 2005 06:14
Picon

Re[2]: new REBOOT target

Hi Max Kellermann,

On Tue, 1 Mar 2005 01:20:58 +0100, Max Kellermann <max <at> duempel.org> wrote:

> On 2005/02/28 10:41, Wang Jian <lark <at> linux.net.cn> wrote:
> > Beside my laziness, the --passphrase is an error-proof mechanism per
> > se.  Let's assume some one wants to use -j REBOOT, but he doesn't
> > specified a good enough match, just '-p icmp', then boom ;) In this
> > sense, the --passphrase is not match, but part of target.
> 
> (my first reply to you didn't get to the list, maybe a mailman
> failure?)
> 
> Now what about an error proof admin? ;)
> 
> Sorry, I don't think this is a good argument, don't try to find an
> excuse for writing a dangerous rule (and for writing such a netfilter
> "design violation"). If an admin is brave enough to compile REBOOT
> into the kernel and write "-j REBOOT" somewhere, it's his own fault he
> didn't implement the correct match. Someone with root access should
> know better.
> 
> REBOOT should ... reboot! Not match the protocol or a certain pass
> phrase.

Can't agree more :)

> 
> Max
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew Kozachenko | 1 Mar 2005 09:22
Picon

Re: new REBOOT target

Wang Jian wrote:

>Hi Max Kellermann,
>
>
>On Tue, 1 Mar 2005 01:20:58 +0100, Max Kellermann <max <at> duempel.org> wrote:
>
>  
>
>>On 2005/02/28 10:41, Wang Jian <lark <at> linux.net.cn> wrote:
>>    
>>
>>>Beside my laziness, the --passphrase is an error-proof mechanism per
>>>se.  Let's assume some one wants to use -j REBOOT, but he doesn't
>>>specified a good enough match, just '-p icmp', then boom ;) In this
>>>sense, the --passphrase is not match, but part of target.
>>>      
>>>
>>(my first reply to you didn't get to the list, maybe a mailman
>>failure?)
>>
>>Now what about an error proof admin? ;)
>>
>>Sorry, I don't think this is a good argument, don't try to find an
>>excuse for writing a dangerous rule (and for writing such a netfilter
>>"design violation"). If an admin is brave enough to compile REBOOT
>>into the kernel and write "-j REBOOT" somewhere, it's his own fault he
>>didn't implement the correct match. Someone with root access should
>>know better.
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wang Jian | 1 Mar 2005 10:49
Picon

Re[2]: new REBOOT target

Hi Andrew Kozachenko,

On Tue, 01 Mar 2005 10:22:54 +0200, Andrew Kozachenko <andrew <at> entri.com.ua> wrote:

> >>    
> >>
> Why don't you use snmp trap for this purpose. You can send special snmp 
> trap from wherever to machine needs rebooting and running snmptrapd and 
> reboots it in a traphandle script.
> Consider using net-snmp for this not netfilter.
> 
> >

Because, in this case, user space programs have no chance to run
correctly, only kernel space has chance to do something, for example,
calling machine_restart();

I suspect that some program is hogging the memory system, and system is
busy swapping to death, but I can't make sure that because the console
is locked in this situation. Before I find the culpit, I have to reboot
it when the system is stuck.

--

-- 
  lark
Permalink | Reply | 0 comments |
headers
Harald Welte | 1 Mar 2005 10:56
Favicon

Re: [PATCH] pptp_conntrack-nat: Fix compile errors DEBUGP() macro in ip_nat_proto_gre.c and ip_nat_pptp.c, fix typo in ip_conntrack_pptp.h

On Sat, Feb 26, 2005 at 12:23:05AM +0100, Sander Eikelenboom wrote:
> 3 small fixes:
> - Fixed compile errors in 2.6 DEBUGP() macro of  ip_nat_proto_gre.c and ip_nat_pptp.c
> - Fixed typo in ip_conntrack_pptp.h

thanks, applied.
--

-- 
- Harald Welte <laforge <at> netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
Permalink | Reply | 0 comments |
headers
Harald Welte | 1 Mar 2005 11:02
Favicon

Re: Preliminary NetBIOS datagram NAT filter

On Wed, Feb 23, 2005 at 08:38:43PM -0800, Constantine Sapuntzakis wrote:
> http://suif.stanford.edu/~csapuntz/ip_nat_netbios.c
> 
> Using this, I was able to join a Windows NT domain and login into the
> domain from behind a NAT.
> 
> I had a hard time understanding all the parameters to the various
> methods, so I probably got it wrong for anything except for source NAT
> (which I tested). I'd appreciate any help from more experienced
> developers.
> 
> Here's the problem with NetBIOS. NetBIOS datagrams contain the source
> IP address and
> source port as bytes 4-9 of the UDP payload. These need to be
> rewritten while traversing a NAT.

so how do you determine that what you are modyfying is really a netbios
packet?  just using the port number is too little.  maybe you can do
some plausibility checks on the whole packet, and also verify that bytes
4-9 are the same as the ip (source?) address in the packet.

> - the HOWTO seems to indicate you want to override
> hlpr->tuple.dst.u.udp.port but all the examples override
> hlpr->tuple.src.u.udp.port  to filter all traffic to a port. Which is
> right?

src.

> - will this NAT helper work with two computers with different IP
> addresses behind a NAT? i.e. if both computers send packets with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick McHardy | 1 Mar 2005 21:32
Favicon

Re: [1/1] ipt_osf: fix ipt_osf compilation on some distros.

Evgeniy Polyakov wrote:
> On Sun, 27 Feb 2005 18:03:02 +0100
> Patrick McHardy <kaber <at> trash.net> wrote:
>>
>>Thanks. I'm having trouble accessing svn, I'll commit them when
>>it is working again.
> 
> Please inform me, so I could commit it into my trees.

I've applied both patches to trunk and the 2.6.11 branch.

Regards
Patrick
Permalink | Reply | 0 comments |
headers
mukesh agrawal | 2 Mar 2005 02:41
Picon
Favicon

[PATCH 2.6.10 1/1] netfilter: fix crash on nat+icmp packets


This patch fixes a kernel crashing bug when using NAT. The crash occurs in 
the case when we send out a UDP packet to a closed port on another host, 
with the UDP packet being SNATed. The remote host replies with an ICMP 
port unreachable (type 3, code 3). We need to adjust the ICMP packet, 
because the UDP packet was SNATed.

The cause of the crash is that udp_manip_pkt reads *pskb into iph before 
calling skb_ip_make_writable, and fails to update iph after the call. 
Since skb_ip_make_writable may delete the original skb when it makes a 
copy, a page fault may occur when udp_manip_pkt later dereferences iph.

I suspect that normally, the relevant skbuff holds a UDP packet, and 
either the skbuff is unshared (so no copy is made, and the skbuff 
remains valid), or is shared, but remains so while udp_manip_pkt is 
running (and hence, the old reference to the skbuff is still okay).

When we get an ICMP reply for a SNATed UDP packet, ip_nat_proto_udp is 
asked to modify the UDP header inside the payload of the ICMP packet. (The 
call chain is ip_nat_fn -> icmp_reply_translation -> ip_nat_manip_pkt -> 
udp_manip_pkt.)

Since the UDP header is beyond the ICMP header, skb_ip_make_writable 
copies the skbuff, and deletes the original. Then udp_manip_pkt's iph is 
invalid, and dereferencing it causes a page fault.

Glancing at the code for tcp_manip_pkt, I think it would have the same 
problem, but I haven't tested that case. The patch below fixes the UDP 
case only.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane