[Nagiosplug-help] check_udp suitable to mimic traceroute?

[Andreas Ericsson]

Ralph.Grothe at itdz-berlin.de wrote:
> Hi Andreas et al.,
> 
>> -----Original Message-----
>> From: Andreas Ericsson [mailto:ae at op5.se]
>> Sent: Wednesday, January 17, 2007 1:54 PM
>> To: Grothe, Ralph
>> Cc: nagiosplug-help at lists.sourceforge.net
>> Subject: Re: [Nagiosplug-help] check_udp suitable to mimic
> traceroute?
> 
> 
> meanwhile I was informed by a network admin whom I asked
> that the suspecious packet dropping gateway is a firewall.
> 
> Searching the Net for tools I came accross tcptraceroute
> whose authors claim that it can better cope with packet sinks
> such as firewalls by using TCP packets targeted to a known
> unfiltered port instead of ICMP or UDP packets as traditional 
> traceroute.
> I will give it a try...
> 

It won't matter for your case, as the firewall responds properly with 
ICMP_TIMXCEED. I've got a feeling it will do exactly the same thing for 
tcp and udp packets.

> 
>>> So to avoid the hassle could one use check_udp, or any other
> of
>>> the vanilla plug-ins,
>>> to this end?
>>>
>> I'm afraid not. What you would have to do is modify an 
>> existing plugin 
>> capable of handling icmp, send a ping to a host behind the
> device you 
>> really want to ping, and then read the ICMP_TIMXCEED as normal 
>> ICMP_ECHOREPLY packets. The only difference between the two are
> in 
>> icmphdr.type and icmphdr.code. The original packet is still 
>> duplicated 
>> on return.
> 
> That's a pitty.
> I have hoped for an easy (to me) solution.
> But it sounds as if this is more involved.
> 
> I will see if I can make use of CPAN's Net::PcapUtils and related
> because I am lousy C coder, and a Perl API would alleviate the
> task
> tremendously for me.
> 
> I think I will be able to strip the relevant parts of the ICMP
> header
> with the Perl wrapper around libpcap.
> 
>>From the figure of an ICMP packet as presented in the RFC
> the Type field must be the 1st octet and the Code field the 2nd.
> 

True, although you need to identify the packet exclusively to
a) Belong to the your process
b) Being one of several sent
so you also need to parse the data being sent back. Note that the id and 
all other fields larger than 8 bits must be translated to network byte 
order if they have any meaning to the host on the remote end.

> 
>>> All I know is that such a UDP datagram would probably require
> the
>>> TTL set to 1
>>> to have the checked gateway decrement it by one and send an
> ICMP
>>> expiration
>>> notification packet back to the sender, much like traceroute.
>>>
>> The value of the TTL on any outgoing packet would have to be 
>> the same as 
>> the number of hops required to reach the gateway, including the
> 
>> gateway-hop itself, so for this setup:
>>
>> Nagios -> gw1 -> gw2 -> address-to-ping
>>
>> you'd have to use TTL=1 to check gw1, TTL=2 to check gw2. 
>> You'd probably 
>> be best off by submitting the TTL as an argument, as it's a 
>> bit tricky 
>> to calculate without doing a semi-full traceroute.
> 
> Yes, I neglected that every hop is decrementing the TTL.
> 
> 
> Besides, I think to remember having once read about a tool called
> htping
> that could be used to rather easily craft up all sorts of
> packets?
> 
> This sadly reminds me of plans by the Ministry of Justice
> overhere 
> to amend our Criminal Law by making the use of so called "hacker
> tools" punible
> en route to "EU law harmonization".
> 
> Apart from that the politicians don't seem to understand the
> difference between
> hackers and crackers, I fear that such valuable admin tools may
> soon be banned.
> 

Well, it's only a "hacker tool" if a hacker uses it. Otherwise you would 
have to argue the same for ping, cat, grep, sed, ls, awk, perl, python, 
ruby, ... I'm sure the "knives and crowbars are lethal weapons" 
discussion has already been ignored by whatever law-writing authority 
you're ruled by in Germany.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231