Mailing List Archive

"Felix Huber" <huberfelix@webtopia.de> writes:

> i just found following traceroute alternative: http://www.mainnerve.com/fft/
> possibly a nice addition to nessus (c plugin?)

The current traceroute plugin is written in NASL. We would just need to
enhance it. But is this really necessary?

> The current traceroute plugin is written in NASL. We would just need to
> enhance it. But is this really necessary?
>

Well, am I the only one who has lots of problems with the current one? as
in not outputting ANYTHING?

--
Michael Scheidell, CEO
SECNAP Network Security, LLC
Sales: 866-SECNAPNET / (1-866-732-6276)
Main: 561-368-9561 / www.secnap.net
Looking for a career in Internet security?
http://www.secnap.net/employment/

> > The current traceroute plugin is written in NASL. We would just need to
> > enhance it. But is this really necessary?
> >
>
> Well, am I the only one who has lots of problems with the current one? as
> in not outputting ANYTHING?

it works here (sometimes)

btw: this fft traceroute seems to work even through some firewalls

"goes through many configurations of packet-filter based firewalls....
Rather than launching UDP probes in an attempt to elicit ICMP
TIME_EXCEEDED, FFT accomplishes substantively the same effect using
TCP SYN or FIN probes, listening for both TIME_EXCEEDED messages or
TCP_RST from firewalls or other gateways in the path."


regards,
felix

Michael Scheidell <scheidell@secnap.net> writes:

> Well, am I the only one who has lots of problems with the current one? as
> in not outputting ANYTHING?

I have this kind of problems too.
But is this plugin so important? Most of the time, I run Nessus on the
same subnet as the targets.

>
> I have this kind of problems too.

I just get tired of forgetting to turn it off when I create a new .rc
file. And, it does show up on the report if you don't.

> But is this plugin so important? Most of the time, I run Nessus on the
> same subnet as the targets.
>

Ok, so we get a localnet() function.
this localnet() function could also be used for those silly HIGH level
warnings on the netbios plugins that scare crap out of the uninitiated.
(and, quite frankly, if they DID deal with it than we would not be able to
do ms hotfix, patch scanning on those hosts, so, our reports says "HIGH,
fix it now" we tell it guy" well, don't do that because it will break
nessus"

-- Michael Scheidell, CEO
SECNAP Network Security, LLC
Sales: 866-SECNAPNET / (1-866-732-6276)
Main: 561-368-9561 / www.secnap.net
Looking for a career in Internet security?
http://www.secnap.net/employment/

>
> btw: this fft traceroute seems to work even through some firewalls
>
> "goes through many configurations of packet-filter based firewalls....
> Rather than launching UDP probes in an attempt to elicit ICMP
> TIME_EXCEEDED, FFT accomplishes substantively the same effect using
> TCP SYN or FIN probes, listening for both TIME_EXCEEDED messages or
> TCP_RST from firewalls or other gateways in the path."

Ok, we agree that the cat needs a bell.. who is going to put the bell on
the cat?

--
Michael Scheidell, CEO
SECNAP Network Security, LLC
Sales: 866-SECNAPNET / (1-866-732-6276)
Main: 561-368-9561 / www.secnap.net
Looking for a career in Internet security?
http://www.secnap.net/employment/

Le lun 12/08/2002 à 00:53, Rich Adamson a écrit :
> I've had no problem with traceroute. I assume you know that traceroute
> will not provide any output if you don't have a layer-three box in the
> path.

Sure. But it's right that it would better if the plugin did not output
anything in the report then.

> Also note that in the above quote traceroute will not work through a
> firewall that blocks icmp's (for whatever that might be worth).

A firewall should not drop ICMP "host unreachable" replies to authorized
packets; unless it is seriously misconfigured.
So the problem is to send packets that can go throught the firewall.
Three methods:
- UDP (Unix like)
- ICMP echo (MS like)
- TCP SYN (should we try other flags?)
Note that the plugin could use the three methods in parallel.

> > > The current traceroute plugin is written in NASL. We would just need to
> > > enhance it. But is this really necessary?
> > >
> >
> > Well, am I the only one who has lots of problems with the current one? as
> > in not outputting ANYTHING?
>
> it works here (sometimes)
>
> btw: this fft traceroute seems to work even through some firewalls
>
> "goes through many configurations of packet-filter based firewalls....
> Rather than launching UDP probes in an attempt to elicit ICMP
> TIME_EXCEEDED, FFT accomplishes substantively the same effect using
> TCP SYN or FIN probes, listening for both TIME_EXCEEDED messages or
> TCP_RST from firewalls or other gateways in the path."

I've had no problem with traceroute. I assume you know that traceroute
will not provide any output if you don't have a layer-three box in the
path.

Also note that in the above quote traceroute will not work through a
firewall that blocks icmp's (for whatever that might be worth).

> Michael Scheidell <scheidell@secnap.net> writes:
>
> > Well, am I the only one who has lots of problems with the current one? as
> > in not outputting ANYTHING?
>
> I have this kind of problems too.
> But is this plugin so important? Most of the time, I run Nessus on the
> same subnet as the targets.

I hardly ever get output from the plugin except a single reported '?' on a
line by itself, however command line traceroutes (UDP and ICMP) work fine
to the targets.

Most of the tests I run are over a (slow) WAN or Internet connection and
traceroutes would useful.

James.

jnp@lilly.csoft.net writes:

> I hardly ever get output from the plugin except a single reported '?' on a
> line by itself, however command line traceroutes (UDP and ICMP) work fine
> to the targets.

Which version are you using? A NASL error was fixed ~ 10 days ago.
I just tried "nasl -t host traceroute.nasl" and it seems to work fine
now.

We still have to improve this script, e.g. to use TCP packets.

jnp@lilly.csoft.net writes:

> I hardly ever get output from the plugin except a single reported '?'

Mmmhhh... The IP ID does not change. It *might* be a problem.
Try this patch, just in case (and tell us if it is better). We may
also play with the TOS field and ask for "reliable" delivery, although
most gateways do not care.