Re: how to know scan is correct?

[Enrico Demarin <mccoy () smc smc it>]

I think the problem is caused by the daemon iplogger that ships with corel
linux and is enabled by default. It literally goes berserk when the
machine is scanned and starts writing logs like mad . disabling it seemed
to solve the problem...

On Thu, 10 Feb 2000, $eeweed wrote:

> I noticed that Corel Linux version 1.0 has some major work that needs to
> be done because of it structure it hangs when you decide to run nmap
> against, Corel really thought this one out,ehh.... Time to bring in the
> real OS's ....just thought I'd let you guys know that if you decide to
> build an operating system..dont let it be as shitty as Corel...(which is
> what my work has)
>
> On Wed, 9 Feb 2000, Marcy Abene wrote:
>
> > You can't avoid a syn scan - what do you think you are
> > talking about?  Here, look. :->
> >
> > syn scan: (nmap -sS)
> >  haxor       target
> >       syn ->
> >          <- syn ack
> >       rst ->
> >
> > tcp connect full: (nmap -sT)
> >  hax0r      target
> >      syn ->
> >         <- syn ack
> >      ack ->
> >   finack ->
> >         <- ack
> >         <- finack
> >      ack ->
> >
> > notice that the first two packets exchanged DO NOT
> > CHANGE.  You send an SYN to a port - if it is open
> > then you get a SYN-ACK.  Your kernel mods can't change
> > this behavior or you lose TCP connectivity.
> >
> > If you meant something else, then you made a typo
> > ("..but it eliminates all of the TCP scans from
> > finding open ports except TCP connect..").
> > --
> >
> > On Wed, 9 Feb 2000, Simple Nomad wrote:
> > > Well, I think that if all networked systems used
> > state tables you would
> > > eliminate almost everything. Unfortunately pretty
> > much all systems do not
> > > use the built in state tables. This is actually one
> > of the first
> > > modifications I make on a new system via kernel
> > patching -- so it really
> > > only applies to open sourced operating systems --
> > but it eliminates all of
> > > the TCP scans from finding open ports except TCP
> > connect, which can be
> > > controlled any number of ways.
> > >
> > > -         Simple Nomad          -  No rest for the
> > Wicca'd  -
> > > -      thegnome () nmrc org        -       
> > www.nmrc.org       -
> > > -  thegnome () razor bindview com  -     
> > www.bindview.com     -
> > > On Wed, 9 Feb 2000, Reinoud Koornstra wrote:
> > >
> > > > Nice issue.
> > > > And..... are there any suggestions for this:
> > > >
> > > > Assume i have a machine running ipf which deals
> > with the traffic from
> > > > outside.
> > > > Behind that machine is an entire netwerk using
> > ipnat.
> > > > Now some one uses nmap on me to see what is open
> > and what isnt.
> > > > Now, ipf notices a packet... (fyn scan) does
> > nothing with it but redirects
> > > > it to another machine on the network on which the
> > port is closed.
> > > > Then nmap will think the port on the firewalled
> > machine is closed while
> > > > nmap really got the results from another machine
> > without knowing it.
> > > > A friend of mine deals this way with this kind of
> > scans and fooling nmap
> > > > completly.
> > > >
> > > >
> > > > Bye,
> > > >
> > > > Reinoud.
> > __________________________________________________
> > Do You Yahoo!?
> > Talk to your friends online with Yahoo! Messenger.
> > http://im.yahoo.com