Port 113?

Should I stealth my Port 113 or keep it closed and report it to the world at large as such?

--
Posted via a free Usenet account from http://www.teranews.com

Re: Port 113?

Cuckoo wrote:
> Should I stealth my Port 113 or keep it closed and report it to the world at large as such?
>

You should look up what port 113 means. Do you have an email server
running on your machine where client machines are looking to retrieve
emails?

What's stealth? Well, it's Gibson BS is what it is about. The main thing
is that the port is *closed* -- that's any port.

Duane :)

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Cuckoo wrote:
> Should I stealth my Port 113 or keep it closed and report it to the world at large as such?
>
> --
> Posted via a free Usenet account from http://www.teranews.com

The latter.

I notice that you don't say you need it open. IRC uses it but I've
found it works fine without it.

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Sebastian Gottschalk wrote:
> q_q_anonymous@yahoo.co.uk wrote:
>
> > Cuckoo wrote:
> >> Should I stealth my Port 113 or keep it closed and report it to the world at large as such?
> >>
> >> --
> >> Posted via a free Usenet account from http://www.teranews.com
> >
> > The latter.
> >
> > I notice that you don't say you need it open. IRC uses it but I've
> > found it works fine without it.
>
> What about reading the protocol documentation? This would safe you some
> useless trials, and would also show when it's good to use it even if
> unnecessary.

Good idea...

You have me a little concerned. If your posts start disappearing from
the archives then it is a loss.

Re: Port 113?

Cuckoo wrote:
> Should I stealth my Port 113 or keep it closed

Close it. "Stealthing" is nonsense.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Sebastian Gottschalk wrote:
> Volker Birk wrote:
> > Cuckoo wrote:
> >> Should I stealth my Port 113 or keep it closed
> > Close it. "Stealthing" is nonsense.
> IBTD. I've never seen any use for sending a reply to the incoming garbage
> on Port 135/TCP.

So you don't think, that being RFC conforming is sensible. But I do.

> However, what you meant is that, unreflected "stealthing" of any ports is
> at least O(nonsense²*ln(nonsense)).

I cannot see, that horseplay is a problem, which scales dependent on
nonsense ;-)

BTW: I cannot get your PoC code for exploiting .NET to work. Can you
help with a working example?

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

I would recommend you "stealth" all of your ports (65535 TCP
+ 65535 UDP). What this actually means is disabling the ICMP
protocol. ICMP has many uses and can be handy to have around
when you need it , but I personally wouldn't recommend using
it routinely unless you actually need to.

My reasons would include:

1) There are a plethora of known attacks using ICMP.

2) There is no doubt that there will be new attacks using
the ICMP protocol in the future.

3) "Unstealthing" your ports (enabling ICMP) means that
your computer's resources can be drained by external
attackers. With ICMP enabled your computer is required to
process and reply to anything that anyone sends to it.
It would be similar to being required to read and send replies
to everyone who sends you spam or conventional "junk mail".
Why bother?

4) Enabling ICMP allows others to receive data packets from
your computer. The way your computer responds to ICMP requests
and what your computer responds with can be analyzed with a view
to "fingerprinting" your operating system. Knowing what operating
system you use is a valuable piece of information to a would-be
attacker. They can then use known-vulnerabilities for your
specific OS and version (especially if there are any "unpatched"
vulnerabilities) in attacks directed towards your computer.

5) Many ISP's disable ICMP in their routers , if your computer
also has ICMP disabled , you are effectively "invisible" to many
would-be attackers. Not using ICMP at the least makes you
far less visible than those who do.

6) Using a "Default Drop" policy for INBOUND and OUTBOUND
firewall-traffic is the most secure default firewall configuration
you can use. With this policy your computer "drops" packets (does
not acknowledge or reply to any packets by default) unless
you have intentionally and specifically allowed traffic in
or out of your firewall. If you were to use a Default Drop policy
why would you specifically allow ICMP in or out if you did
not need it? The whole point of this type of security-stance
is to allow in and out ONLY that which is ESSENTIAL. Please
note that with a Default Drop policy , especially with regard
to the OUTBOUND rules , you need to be careful to place any
essential firewall-rules ALLOWING traffic in-place before you enable
your Default Drop policy. It is always best to have print-outs
and back-up copies of all configurations before proceeding.


There are those who disagree with disabling ICMP and "stealthing"
ports. These people seem to believe that it is "impolite" not
to reply to ICMP pings and the like. Perhaps these same people
believe that the Internet is inherently a "friendly place" and
not a hostile environment. It would be nice if this were true ,
but I don't feel this has been the case for a very long time.
As long as there are many people expending much effort to
subvert the ICMP protocol for both malicious and financially-
motivated attacks , I personally will not be using it , "routinely".

Re: Port 113?

Anonymous via the Cypherpunks Tonga Remailer wrote:
> I would recommend you "stealth" all of your ports

Why? This just violates IP and is of no use.

> What this actually means is disabling the ICMP
> protocol.

Then IP will not work very good.

> 1) There are a plethora of known attacks using ICMP.

Maybe you should have a closer look onto IP and ICMP.

> 3) "Unstealthing" your ports (enabling ICMP)

Not "stealthing" does not mean "enabling ICMP". Mostly there are TCP RST
packets to send.

> There are those who disagree with disabling ICMP and "stealthing"
> ports. These people seem to believe that it is "impolite" not
> to reply to ICMP pings and the like.

Perhaps you really should read STD 5 / RFC 791 and 792 first, before
arguing. You seem not to have a clue what you're writing here. You can
find the RFCs at http://www.rfc-editor.org

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

Volker Birk wrote:
> Anonymous via the Cypherpunks Tonga Remailer wrote:
> > I would recommend you "stealth" all of your ports
>
> Why? This just violates IP and is of no use.
>
> > What this actually means is disabling the ICMP
> > protocol.
>
> Then IP will not work very good.
>
> > 1) There are a plethora of known attacks using ICMP.
>
> Maybe you should have a closer look onto IP and ICMP.
>
> > 3) "Unstealthing" your ports (enabling ICMP)
>
> Not "stealthing" does not mean "enabling ICMP". Mostly there are TCP RST
> packets to send.
>
> > There are those who disagree with disabling ICMP and "stealthing"
> > ports. These people seem to believe that it is "impolite" not
> > to reply to ICMP pings and the like.
>
> Perhaps you really should read STD 5 / RFC 791 and 792 first, before
> arguing. You seem not to have a clue what you're writing here. You can
> find the RFCs at http://www.rfc-editor.org
>
> Yours,
> VB.
> --

the poster has confused "stealth" with blocking ping. You can use
"stealth" and allow ping. Or be "unstealthed"(open/closed) and
disallow ping.

Re: Port 113?

Anonymous via the Cypherpunks Tonga Remailer wrote:

> I would recommend you "stealth" all of your ports (65535 TCP
> + 65535 UDP). [more nonsense deleted]

Before *you* recommend something, you should definitely read some books
about TCP/IP. You are clueless.

Wolfgang

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Simply insert "TCP RST" packets into my previous post's reasons.

IMO silently dropping all ICMP and TCP RST packets is the more
secure thing to do.

If anyone is actually claiming that allowing ICMP and TCP RST
is more secure , please elaborate. Apart from some saying
"...it breaks this..." or "...it violates RFCxxx..." , no-one
seems to be able to articulate why their stance would actually
be more secure.

I assumed the original poster wanted to know which policy
is more secure. I would never claim to be an expert , I
learn new things constantly , but I do stand by my
conclusions. I have not allowed ICMP and TCP RST packets for
years and have had no problems whatsoever.

Perhaps some who post here who do consider themselves to be
experts , hold their views religiously. Religiously-held
beliefs cannot be articulated rationally. My recommendation
is more secure because... Your recommendation is less secure
because...

Choosing NOT to allow things that are optional , not required
nor essential , could be the difference between having your
computer successfully attacked at some point in the future
or being ignored as a target. The concept of OS-hardening
and of computer security in general is a trade-off between
convenience and security , usually the more secure you make
something , the less convenient it is to use. Sometimes
things "break" and aren't as easy to use again in the exact
way you once used them. I don't think this present instance
breaks anything , I have had no adverse effects at all.
I would be willing to break some things to achieve a more
secure system , I personally give priority to security over
convenience when any trade-off needs to occur. Others may
prefer convenience. To each his own. I believe I made my
post to comp.security.firewalls and not to
"comp.convenient.firewalls".

I disagree with the person who thinks that they can receive
ping-requests , have their system send ping-replies and
still have these ports "stealthed". If any of your ports cause
the generation of a ping-reply , these ports are visible externally
and are not "stealthed".

ICMP is far more than just ping-requests and ping-replies.
I consider it dangerous to use routinely. If you have a large
network , you may wish to use it more regularly. The range
of ICMP-based attacks available supports my conclusion.

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

On 28 Aug 2006 17:59:29 +0200, Cyberiade.it Anonymous Remailer
wrote:

>IMO silently dropping all ICMP and TCP RST packets is the more
>secure thing to do.
>
>If anyone is actually claiming that allowing ICMP and TCP RST
>is more secure , please elaborate. Apart from some saying
>"...it breaks this..." or "...it violates RFCxxx..." , no-one
>seems to be able to articulate why their stance would actually
>be more secure.

Could I kindly ask you to also elaborate why you think stealth is more
secure?

Is there for example something you can do to a closed port that you
cannot do to a stealthed port?

I'm not challenging you. I'm just interrested in both opinions in this
everlasting discussion.

>Religiously-held beliefs cannot be articulated rationally.

Agreed. Therefore we also need an explanation to your own
recommendation.

>If any of your ports cause the generation of a ping-reply , these ports
>are visible externally and are not "stealthed".

Are you saying that stealthing would make them invisible or
unreachable?

Re: Port 113?

"B. Nice" wrote in message
news:ptl7f29ve72mg68hp6aii2ae51hqqpsece@4ax.com...
> On 28 Aug 2006 17:59:29 +0200, Cyberiade.it Anonymous Remailer
> wrote:
>
>>IMO silently dropping all ICMP and TCP RST packets is the more
>>secure thing to do.
>>
>>If anyone is actually claiming that allowing ICMP and TCP RST
>>is more secure , please elaborate. Apart from some saying
>>"...it breaks this..." or "...it violates RFCxxx..." , no-one
>>seems to be able to articulate why their stance would actually
>>be more secure.
>
> Could I kindly ask you to also elaborate why you think stealth is more
> secure?
>
> Is there for example something you can do to a closed port that you
> cannot do to a stealthed port?
>
> I'm not challenging you. I'm just interrested in both opinions in this
> everlasting discussion.
>
>>Religiously-held beliefs cannot be articulated rationally.
>
> Agreed. Therefore we also need an explanation to your own
> recommendation.
>
>>If any of your ports cause the generation of a ping-reply , these ports
>>are visible externally and are not "stealthed".
>
> Are you saying that stealthing would make them invisible or
> unreachable?


Your last question answers your main question.

Stealth means that somebody attempting to make contact will not
see anything. There is nothing at this address.

Closed means that somebody attempting to make contact will get
a confirmation that the address is OK but that his attempt is rejected.

The difference (for "the bad guy") is that he will normally not bother
with further attempts to get into a computer that is not there while he
might very well try various ways of getting into the "closed" computer
because that is a challenge to him.

regards Sven

Re: Port 113?

On Tue, 29 Aug 2006 10:29:36 +0200, "Sven Pran"
wrote:

>Your last question answers your main question.
>
>Stealth means that somebody attempting to make contact will not
>see anything. There is nothing at this address.

But that's not true. Something is there - it is just not replying. And
since your stealthness depends, among other things, on the
infrastructure you are connected to you have to take also that into
consideration. Just to take my own machine as an example, it is childs
play for someone out there to figure out of if I'm really not there or
if I'm there but just "stealthed".

It can slow down a port scan - but since a bad guy can do numerous
scans in parrallel I don't think the effect of that is really
significant.

I also wonder what the -P0 option of the nmap utility is for.

>Closed means that somebody attempting to make contact will get
>a confirmation that the address is OK but that his attempt is rejected.

Others look at that as a prompt rejection like "there is nothing here
for you - move on". Who is right?

>The difference (for "the bad guy") is that he will normally not bother
>with further attempts to get into a computer that is not there while he
>might very well try various ways of getting into the "closed" computer
>because that is a challenge to him.

He may well know it's there. But anyway, how do you get through a
closed port? And if that is possible, why is there a difference to it
being stealthed?

And how do we know what "the bad guys" are thinking after all? Maybe
it's a bigger challenge to get into the stealthed one?

>
>regards Sven
>

/B. Nice

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Cyberiade.it Anonymous Remailer wrote:
> IMO silently dropping all ICMP and TCP RST packets is the more
> secure thing to do.

Why? Please substantiate.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

Sven Pran wrote:
> Stealth means that somebody attempting to make contact will not
> see anything.

Yes.

> There is nothing at this address.

The opposite is true. There is something at this address, because if
there would be nothing, then the router before would send ICMP host
unreachable.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

Hello B. Nice and all.

I disagree fundamentally with Mr. Gottschalk's
recommendation to use what amounts to "Default Allow"
firewall policies.

Mr. Gottschalk wrote "You should never "stealth" any port
until you have explicit reason to do so." This is an
example of a "Default Allow" policy.

I believe in using "Default Drop" policies for all of my
firewalls. As far as I am aware using INBOUND and OUTBOUND
Default Drop policies are the Most Secure default firewall
configurations. One has to know what traffic they wish to
allow , and add deliberate and specific firewall-rules to
allow it. It's a very educational process , because you
cannot use any facet of the Internet until you know exactly
which protocols and/or (TCP/UDP) ports you wish to use.

Imagine a door-lock for a house or an apartment , under
what would be similar to a "Default Allow" policy , everyone
would be able to unlock your door EXCEPT those persons whom
you have specifically listed and barred from entry. Who would wish
to have to list the 6-Billion odd people extant on the planet
just to be able to prevent their entry? Under a similar
scenario with a "Default Drop" policy ALL (those 6-Billion+)
are denied entry UNLESS they have been specifically added
to a list to be given entry (to be given a key lets say).

Mr. Gottschalk's recommendation to the original poster was
to allow the traffic to and from the poster's computer to
the extent that his ports would be "unstealthed". Later Mr.
Gottschalk mentioned that:

"I've got a box that runs Windows from time to time. By default it would
only react to ICMP codes 0,3,4,5,8,11,12,17 and 18. I configured it to not
react to code 5, 17 or 18. The other ones aren't dangerous in any way. ..."

Maybe I missed it somewhere , but I don't recall Mr. Gottschalk
warning the original poster that (perhaps especially under
Windows environments) ICMP codes 5 , 17 , and 18 are
dangerous. Did he make it clear to the original poster?

With Default Allow all is allowed (unless you know exactly
what you wish to Disallow and then add the appropriate
firewall-rule).

My advice wouldn't have left the original poster open to
problems related to ICMP codes 5 , 17 , and 18.

Perhaps today there are dangers using ICMP codes 3 , 8 ,
and 12?

Perhaps tomorrow there will be attacks using 0 , 4 , 8 ,
and 11?

Things change constantly , new attacks are formulated
constantly.

I'm quite content using a Default Drop stance.

My advice (again) is to do similarly , add rules to allow
the traffic you absolutely must have , then add other traffic
when and only when you FULLY UNDERSTAND what you are allowing.
To do otherwise you truly must be an expert , and I mean having
the ability to know of all possible attacks that are available
instantly (and being able to change your firewall configurations
instantly). I personally feel that having a secure firewall
is NOT possible using defaults that blindly allow traffic.

Perhaps Mr. Gottschalk or some others are even more omnipotent
than they could imagine. One would have to be to be able to
track and respond to varying attack-methodologies second-by-second.
Does anyone know what the dangerous ICMP codes are for today? Some
find philately or numismatic-pursuits to be more relaxing hobbies.
To each his (or her) own.

N.B. I assume that any who actually have a need to use ICMP or TCP RST
or anything else will take the time and perhaps the Great Effort to be able
to use these things securely. I elect not to use them. Some things can be Mastered.
Some other things are perhaps best Not to master (nor to use).
Cost-benefit and risk-reward analyses are your friends.

P.S. RE: Volker Birk (x2)

1) Many ISP's disable or curtail ICMP in their routers.
If you are near to such routers (as I believe I am) there
will be no forthcoming ICMP Host Unreachable messages. Even
for those routers that do give these messages , would-be
attackers would have no idea whether you were a home PC or
some networked refrigerator or toaster. OS-fingerprinting
relies on being able to receive packets (probably preferably
TCP SYN packets) from potential targets , I choose not to
emit ANY packet to anywhere without a valid reason.

2) Substantiate which? I advocate a Default Drop firewall
stance. Those using Default Drop policies will be
"stealthed" by default , they will be emitting packets only
according to the specific firewall-rules that they write ,
rather than to anyone or anything on the planet that wishes
to scan or probe them.

You and some others advocate sending packets out to
anyone for no articulated security or other advantage. It
is always less secure to allow traffic blindly. It is indeed
bizarre to allow traffic for absolutely no advantage or
reason.

My systems and my Internet connection are highly-stable. I
can leave my machines on and my connection up for days at a
time with nothing but a steady and reliable exchange of
data. Perhaps any performance-degradation when not allowing
certain types of traffic is idiosyncratic to your particular
equipment or configuration.

I am a home user , but a number of reports both here and
elsewhere seem to indicate that many larger networks
also do not require that which you and others are advocating.

Re: Port 113?

Nomen Nescio wrote:
> Mr. Gottschalk wrote "You should never "stealth" any port
> until you have explicit reason to do so." This is an
> example of a "Default Allow" policy.

It is not. There is no security gain by this "stealthing" nonsense at
all, and there is no security loss by not doing so.

> I believe in using "Default Drop" policies for all of my
> firewalls.

Maybe you really should try to learn. Perhaps it would be a good idea
for you to read the RFCs about IP, ICMP and TCP first.

> My advice (again) is to do similarly , add rules to allow
> the traffic you absolutely must have , then add other traffic
> when and only when you FULLY UNDERSTAND what you are allowing.

Yes. Just try to understand what you're doing or recommending,
_afterwards_ do or recommend, please.

> Does anyone know what the dangerous ICMP codes are for today?

Please, *PLEAZE* read the corresponding RFCs now and try to understand.
Afterwards it will be very clear for you, which ICMP messages you want
to let through at all events. Beside that "stealthing" also requires to
violate TCP and not only ICMP, of course.

Just try to understand. Believe me, it's not too hard, you don't need to
be "omnipotent" or something like that, and you really will learn
interesting and useful things.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

On 29 Aug 2006 18:16:42 +0200, Volker Birk wrote:

>Nomen Nescio wrote:
>> Mr. Gottschalk wrote "You should never "stealth" any port
>> until you have explicit reason to do so." This is an
>> example of a "Default Allow" policy.
>
>It is not. There is no security gain by this "stealthing" nonsense at
>all, and there is no security loss by not doing so.
>
>> I believe in using "Default Drop" policies for all of my
>> firewalls.
>
>Maybe you really should try to learn. Perhaps it would be a good idea
>for you to read the RFCs about IP, ICMP and TCP first.

I don't know if you work in the business or not so I will tell you
what is actually done by my company which has several hundred
Checkpoint firewalls, and Juniper IPS devices and multiple DS3 links
to the Internet.

We silently DROP all packets where there is not a server listening on
that port. There are no ICMPs sent back or any resets. Regardless of
if it violates any RFCs or not, if there is no server on a port,
nothing at all is sent back. We run our own edge routers, we don't
trust our service providers to do this. We have our own class A block
and several class B blocks. If you have a class A block, you have
been around for a bit.

This is how every person I know who works at any large company has
configured their sites. By large I am talking billion dollar size
company. I have had all the Checkpoint training classes, Juniper
Netscreen classes and Secure Computing Sidewinder G2 classes. This is
how they all teach you to configure the firewalls, drop anything not
matching a policy, NEVER use reset.

I don't want to argue about if it's correct or not, it's what is done
and taught.

>
>> My advice (again) is to do similarly , add rules to allow
>> the traffic you absolutely must have , then add other traffic
>> when and only when you FULLY UNDERSTAND what you are allowing.
>
>Yes. Just try to understand what you're doing or recommending,
>_afterwards_ do or recommend, please.
>
>> Does anyone know what the dangerous ICMP codes are for today?
>
>Please, *PLEAZE* read the corresponding RFCs now and try to understand.
>Afterwards it will be very clear for you, which ICMP messages you want
>to let through at all events. Beside that "stealthing" also requires to
>violate TCP and not only ICMP, of course.
>
>Just try to understand. Believe me, it's not too hard, you don't need to
>be "omnipotent" or something like that, and you really will learn
>interesting and useful things.
>
>Yours,
>VB.

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

On Tue, 29 Aug 2006 21:17:23 GMT, Leythos wrote:

>In article <63a9f2pqvo8kbbn3ik06v9hfa2n6oaf5rc@4ax.com>, spam@spam.org
>says...
>> This is how every person I know who works at any large company has
>> configured their sites. By large I am talking billion dollar size
>> company. I have had all the Checkpoint training classes, Juniper
>> Netscreen classes and Secure Computing Sidewinder G2 classes. This is
>> how they all teach you to configure the firewalls, drop anything not
>> matching a policy, NEVER use reset.
>>
>> I don't want to argue about if it's correct or not, it's what is done
>> and taught.
>
>We've done the same method for a decade and it's worked perfectly for
>our clients.
>
>Some people don't get into the real world much, if you linger long
>enough in this group you will learn who they are.

So I have gathered. My impression is that some here give out advice
without actually working in the field. It's not my intent to get
involved in some flame war, been there already and it's better to just
forget it. I just had to say however that to silently drop packets is
the industry standard and has been for the 10 years I have been doing
commercial firewall work.

Re: Port 113?

On 08/29/06 07:22, Volker Birk wrote:
>> There is nothing at this address.
>
> The opposite is true. There is something at this address, because if
> there would be nothing, then the router before would send ICMP host
> unreachable.

Indeed!

Now consider this: If you controlled the router in front of a host and had
a way (i.e. IPTables (and the likes)) to make the router send an "ICMP Host
Unreachable" message on behalf of the host that it is protecting, it will
be much harder to determine if the host is really there or not.

I would think that it would be very easy to configure the edge firewalling
router to watch for "ICMP Host Unreachable" messages from specific hosts
and SNAT the packet appear to be from the firewalling router its self.
This would allow the protected host to manage it's own firewall yet still
have the "ICMP Host Unreachable" messages appear as if they were from the
router.

Or at least this is what I think. Any thought's / opinions?



Grant. . . .

Re: Port 113?

crypto wrote:
> On Tue, 29 Aug 2006 21:17:23 GMT, Leythos wrote:
>
> >In article <63a9f2pqvo8kbbn3ik06v9hfa2n6oaf5rc@4ax.com>, spam@spam.org
> >says...
> >> This is how every person I know who works at any large company has
> >> configured their sites. By large I am talking billion dollar size
> >> company. I have had all the Checkpoint training classes, Juniper
> >> Netscreen classes and Secure Computing Sidewinder G2 classes. This is
> >> how they all teach you to configure the firewalls, drop anything not
> >> matching a policy, NEVER use reset.
> >>
> >> I don't want to argue about if it's correct or not, it's what is done
> >> and taught.
> >
> >We've done the same method for a decade and it's worked perfectly for
> >our clients.
> >
> >Some people don't get into the real world much, if you linger long
> >enough in this group you will learn who they are.
>
> So I have gathered. My impression is that some here give out advice
> without actually working in the field. It's not my intent to get
> involved in some flame war, been there already and it's better to just
> forget it. I just had to say however that to silently drop packets is
> the industry standard and has been for the 10 years I have been doing
> commercial firewall work.

Do consider that people that can program firewalls(perhaps some here
can) , and really know how they work. Those people will have a
different , and more technically correct understanding than people
whose experience of firewalls are $800 appliances.
Those people won't have to go on "courses".

I think it's important to have both perspectives. But to say to a
technical geek expert 'you don't know, you're not a "professional",
because you're not 'in the industry' of setting up fireawlls for
businesses, is just stupid.

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Leythos wrote:
> In article <1157026267.212305.286630@i3g2000cwc.googlegroups.com>,
> q_q_anonymous@yahoo.co.uk says...
> > I think it's important to have both perspectives. But to say to a
> > technical geek expert 'you don't know, you're not a "professional",
> > because you're not 'in the industry' of setting up fireawlls for
> > businesses, is just stupid.
>
> Many people that teach and are not in the field have problems with this
> statement: There is the right way, the wrong way, and the way it really
> works.
>
> Many people that don't have experience in multiple cases only see a
> small scope of situations, or actually never see more than a couple
> situations. Some of those people are ignorant enough to believe that
> their scope and what they read is the definitive word in how it should
> always be.
>
> Many people that have built solutions in the real world, that have
> proven to work, without a failure, without a breach, that keep
> corporations all over the world up and running, feel they know it all.
>
> There are a few people, and mostly a minority, that have enough
> experience, have enough QA/Development time, have experienced many
> solutions and products/platforms, that they get tired of the kiddies
> claiming that they know the only right answer to everything.
>
> I've seen hundreds of installations were a "technical" type setup a
> firewall, you can pick the firewall platform/appliance, where they just
> went by some training or document they found on the web, where there
> were so many holes that it might as well not have been installed. I've
> seen security instructors give bad information and methodology to
> students. I've seen instructors to the one really bad example "We're
> going to do it this way in class so that I can show you how it works,
> but you should never do this in a clients network" - and then the kids
> go out and all they remember is how it was done in class.
>
> I have the impression that there are people in here that claim a lot of
> things, that like to appear as authorities by spouting what the RFC's
> suggest, that say nothing except their way is the right way, but, I also
> get the idea that those same people have either never been in the real
> world or are so far removed from it that the scope of what is real and
> what they know is very small.
>
> You can take what I've written and throw it away, but it won't change
> the fact that you can do many things, even things that the RFC's would
> rather you not do, and life will still go on, your network will still
> work, your client won't experience any problems, and your designs will
> be safe.
>
> An expert is only an expert if his peers believe he's an expert. Any
> expert that believes he's an expert is only fooling himself.
>
> --
>
> spam999free@rrohio.com
> remove 999 in order to email me

I agree, that was very well put.. The other guy also provided some
advantages of the industry guy over the only technical guy. As if
that was all that counted. I was just showing that the technical guy
hasm any advatnages over the industry guy.

Ideally you want both. But typically the best technical or best
industry guy is going to be weighted to one side.

I did see a thread involving you where somebody mentioned an
application that would fail. It would be worth me searching through the
archives if your posts were still there. Is there any way that I can
read your old posts? Any searchable archive? preferably free.

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Leythos wrote:
> In article <1157054004.996490.288300@i3g2000cwc.googlegroups.com>,
> q_q_anonymous@yahoo.co.uk says...
> >
> > Leythos wrote:
> > > In article <1157026267.212305.286630@i3g2000cwc.googlegroups.com>,
> > > q_q_anonymous@yahoo.co.uk says...
> > > > I think it's important to have both perspectives. But to say to a
> > > > technical geek expert 'you don't know, you're not a "professional",
> > > > because you're not 'in the industry' of setting up fireawlls for
> > > > businesses, is just stupid.
> > >
> > > Many people that teach and are not in the field have problems with this
> > > statement: There is the right way, the wrong way, and the way it really
> > > works.
> > >
> > > Many people that don't have experience in multiple cases only see a
> > > small scope of situations, or actually never see more than a couple
> > > situations. Some of those people are ignorant enough to believe that
> > > their scope and what they read is the definitive word in how it should
> > > always be.
> > >
> > > Many people that have built solutions in the real world, that have
> > > proven to work, without a failure, without a breach, that keep
> > > corporations all over the world up and running, feel they know it all.
> > >
> > > There are a few people, and mostly a minority, that have enough
> > > experience, have enough QA/Development time, have experienced many
> > > solutions and products/platforms, that they get tired of the kiddies
> > > claiming that they know the only right answer to everything.
> > >
> > > I've seen hundreds of installations were a "technical" type setup a
> > > firewall, you can pick the firewall platform/appliance, where they just
> > > went by some training or document they found on the web, where there
> > > were so many holes that it might as well not have been installed. I've
> > > seen security instructors give bad information and methodology to
> > > students. I've seen instructors to the one really bad example "We're
> > > going to do it this way in class so that I can show you how it works,
> > > but you should never do this in a clients network" - and then the kids
> > > go out and all they remember is how it was done in class.
> > >
> > > I have the impression that there are people in here that claim a lot of
> > > things, that like to appear as authorities by spouting what the RFC's
> > > suggest, that say nothing except their way is the right way, but, I also
> > > get the idea that those same people have either never been in the real
> > > world or are so far removed from it that the scope of what is real and
> > > what they know is very small.
> > >
> > > You can take what I've written and throw it away, but it won't change
> > > the fact that you can do many things, even things that the RFC's would
> > > rather you not do, and life will still go on, your network will still
> > > work, your client won't experience any problems, and your designs will
> > > be safe.
> > >
> > > An expert is only an expert if his peers believe he's an expert. Any
> > > expert that believes he's an expert is only fooling himself.
> > >
> > > --
> > >
> > > spam999free@rrohio.com
> > > remove 999 in order to email me
> >
> > I agree, that was very well put.. The other guy also provided some
> > advantages of the industry guy over the only technical guy. As if
> > that was all that counted. I was just showing that the technical guy
> > hasm any advatnages over the industry guy.
>
> I don't see the definition as "Technical" as the field guy is normally
> technical to the max, but a field guy may be green, as the same is true
> with your technical guy.
>
> What I like to break them do into is:
>
> 1) People that have real experience in a LOT of real world solutions and
> a lot of technical background.
>
> 2) People that have limited real world/none experience but have a lot of
> technical training.
>
> 3) People that believe they are #1, are not really #2, and just can't
> cut it in either group.
>
> > Ideally you want both. But typically the best technical or best
> > industry guy is going to be weighted to one side.
>
> I never hire the #2 or #3 types, I only hire people with lots of real
> world experience and good technical backgrounds, people that are
> book/limited scope are worthless when it comes to the real world.
>


ok


> > I did see a thread involving you where somebody mentioned an
> > application that would fail. It would be worth me searching through the
> > archives if your posts were still there. Is there any way that I can
> > read your old posts? Any searchable archive? preferably free.
>
> LOL, this is Usenet, you can search for anything you want and I don't
> have anything to say about it.
>
> --

You misunderstood what I was asking.

To put it differently, what I meant was, suppose you make a good
contribution to a thread, if I want to see that contribution, to
search for the thread and see your contributions as well as those of
others, Is there any searchable archive (preferably free) that'll
contain your posts?

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Just to add a few points for clarification.

I tend to be very conservative when I configure things
for security , as I mentioned previously I am not an
expert. An "expert" might conceivably be more vulnerable
to attack in using something complex that a non-expert
might have DISABLED.

I tend to define many things very literally , to me
a "Default Drop" policy is ONLY a firewall stance that
allows no packets to travel in either direction unless
specific rules have been added to specifically allow packets
to pass. To me a "Default Deny" policy (that would include
sending TCP RST packets) is another form of Default Allow
policy. Though by definition only a Default Allow policy
allows complete connections to be formed by default , Default
Deny policies allow PACKETS to travel in either direction by
default and I personally view these as being "lesser" Default
Allow policies.

To have any computer "unstealthed" one needs to be using
a firewall that is allowing packets to move in and out in
what I personally consider to be an unsafe fashion.

I admit I do need to spend a great deal of time researching
many Internet protocols. It is possible that I might find
some compelling reasons to use TCP RST and ICMP , but I don't
believe I will find that any such possibilities would increase
my level of security.

I value my privacy and security highly , I fervently believe
that allowing the likes of TCP RST and ICMP will only act
to undermine my online privacy and security.

I also believe that using ICMP will leave my systems open
to future and as yet unknown attacks. As I have not used
ICMP and have perfectly stable and responsive systems I
see absolutely no reason to make myself vulnerable to
the plethora of ICMP-based attacks. I do not use ICMP , thus
I am not vulnerable to most attack-forms that utilize it.

I prefer to keep things as simple as is possible. I use two
firewalls at present and in addition to STRICTLY LITERAL
Default Drop policies , my firewall-rules are highly-specific
to the packets they allow. Very Strict.

Though Mr. Gottschalk may very well be an expert on say ICMP ,
I believe his decision to use ICMP will make his systems more
vulnerable to ICMP attacks (including new attack-methodologies
in the future). More vulnerable than my own systems are that
are "stealthed".

Stealthing is a good thing , it can help to protect your
privacy and your security. I'm not saying that there is
security through obscurity , but with adequate and tangible
computer defenses in place , I see the tool of "stealthing"
to be useful.

If anyone is curious I use OpenBSD's PF firewall and also
the Linux Netfilter firewall. Neither have ever failed me.
I prefer OpenBSD's PF as I am more used to it , I find it
to be more configurable , and it seems to be quite a bit
more sophisticated (perhaps more so than I require).

I do value the comments of Mr. Gottschalk and many others ,
should I ever decide to use TCP RST and ICMP for some
non-security-related reason , their posts and the RFC's may
very well come in handy. If I were not a home computer-user ,
if I actually wished to allow connections originating from the
Internet to my systems , I might configure things differently.
Possibly.

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Leythos wrote:
> In article <63493f8f4a2342e582e6c095a0823440@dizum.com>,
> nobody@dizum.com says...
>
>>If I were not a home computer-user ,
>>if I actually wished to allow connections originating from the
>>Internet to my systems , I might configure things differently.
>>Possibly.
>
>
> We block all ICMP and have never had a problem with inbound connections
> for services we provide.
>

Same here, I block all ICMP with the WatchGuard for my home network. I
also have Blackice block all ICMP with this laptop while in the hotel
room using dial up. I have never had a problem blocking all ICMP.

Duane :)

Re: Port 113?

Leythos wrote:
> In article <1157061118.632635.80740@m73g2000cwd.googlegroups.com>,
> jameshanley39@yahoo.co.uk says...
> > To put it differently, what I meant was, suppose you make a good
> > contribution to a thread, if I want to see that contribution, to
> > search for the thread and see your contributions as well as those of
> > others, Is there any searchable archive (preferably free) that'll
> > contain your posts?
>
> I use something called "X-No-archive: yes" in almost every post, have
> for years, and under every nickname I've used since the early 80's.
>
> So, unless you find an archive or a usenet web mirror that ignores XNA,
> you won't see my direct posts archived.
>
> Google has taken over the archiving of Usenet, but they honor XNA
> requests.
>
> --

I do realise that. I was hoping you might know of one ?

Re: Port 113?

On Tue, 29 Aug 2006 21:17:23 GMT, Leythos spoketh

>
>We've done the same method for a decade and it's worked perfectly for
>our clients.
>
>Some people don't get into the real world much, if you linger long
>enough in this group you will learn who they are.

Although I rarely disagree with you, there's a difference between "what
works" and "what works", and I will elaborate.

Simply dropping unsolicited connections works. It may not break anything
for you and many other, and everything may seem just fine and dandy. And
that's ok

"Stealth" does not work. Dropping packets (tcp/udp/icmp) for the purpose
of being "invisible on the internet", as per Gibsons definition, does
not work.

So, if you want to drop connections, that's your choice. It doesn't make
you more secure, it doesn't make you invisible, but it works.

Lars M. Hansen
http://www.hansenonline.net
(replace 'badnews' with 'news' in e-mail address)

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

On Thu, 31 Aug 2006 13:31:40 GMT, Leythos wrote:

>In article <1157026267.212305.286630@i3g2000cwc.googlegroups.com>,
>q_q_anonymous@yahoo.co.uk says...
>> I think it's important to have both perspectives. But to say to a
>> technical geek expert 'you don't know, you're not a "professional",
>> because you're not 'in the industry' of setting up fireawlls for
>> businesses, is just stupid.
>
>Many people that teach and are not in the field have problems with this
>statement: There is the right way, the wrong way, and the way it really
>works.
>
>Many people that don't have experience in multiple cases only see a
>small scope of situations, or actually never see more than a couple
>situations. Some of those people are ignorant enough to believe that
>their scope and what they read is the definitive word in how it should
>always be.
>
>Many people that have built solutions in the real world, that have
>proven to work, without a failure, without a breach, that keep
>corporations all over the world up and running, feel they know it all.
>
>There are a few people, and mostly a minority, that have enough
>experience, have enough QA/Development time, have experienced many
>solutions and products/platforms, that they get tired of the kiddies
>claiming that they know the only right answer to everything.
>
>I've seen hundreds of installations were a "technical" type setup a
>firewall, you can pick the firewall platform/appliance, where they just
>went by some training or document they found on the web, where there
>were so many holes that it might as well not have been installed. I've
>seen security instructors give bad information and methodology to
>students. I've seen instructors to the one really bad example "We're
>going to do it this way in class so that I can show you how it works,
>but you should never do this in a clients network" - and then the kids
>go out and all they remember is how it was done in class.
>

Been there already.

I don't claim to know everything but I have been doing this for a
really long time and I have seen all sorts claiming all sorts.

Last year I was in a CISSP class and the instructor who I originally
thought was OK turned out to be a moron. He and I got into an email
debate about encryption key lengths and it became clear to me he
really had no idea what he was talking about. I told our corporate
people to never ever hire this guy for a class again

>I have the impression that there are people in here that claim a lot of
>things, that like to appear as authorities by spouting what the RFC's
>suggest, that say nothing except their way is the right way, but, I also
>get the idea that those same people have either never been in the real
>world or are so far removed from it that the scope of what is real and
>what they know is very small.

I read RFC's I know some people who have their names on RFC's. Big
deal, vendors often do not adhere to the RFC's at all. My specialty
is IPSec and this was a nightmare of incompatibility several years
back (been to IPSec bake offs) because of companies not doing what the
RFC said and mostly, they didn't care.
>
>You can take what I've written and throw it away, but it won't change
>the fact that you can do many things, even things that the RFC's would
>rather you not do, and life will still go on, your network will still
>work, your client won't experience any problems, and your designs will
>be safe.

I agree, ignore my comments, I really don't care. I was only trying
to point out how things are done in the corporate world of big
firewalls and big networks. My home net is designed just like our
corporate net. There is no good reason to respond to unsolicited
packets, do so if you want, I don't.
>
>An expert is only an expert if his peers believe he's an expert. Any
>expert that believes he's an expert is only fooling himself.

Agree 100%.

Re: Port 113?

Nomen Nescio wrote:
> To me a "Default Deny" policy (that would include
> sending TCP RST packets) is another form of Default Allow
> policy.

You just don't understand TCP, and you seem not to understand IP and
ICMP at all. This seems to be the reason for your opinion. "Nomen",
really, please read the mentioned RFCs and try to understand. It's not
too difficult, you probably will manage to understand.

> I value my privacy and security highly , I fervently believe
> that allowing the likes of TCP RST and ICMP will only act
> to undermine my online privacy and security.

This is wrong. And: don't "believe", we're talking about facts, please
have a look at them after all now.

> Stealthing is a good thing

It's useless nonsense, and it just violates protocols without having any
advantage.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

Post removed (X-No-Archive: yes)

Re: Port 113?

Volker Birk wrote:
> Nomen Nescio wrote:
> > To me a "Default Deny" policy (that would include
> > sending TCP RST packets) is another form of Default Allow
> > policy.
>



>
> > Stealthing is a good thing
>
> It's useless nonsense, and it just violates protocols without having any
> advantage.
>
> Yours,
> VB.
> --
> Viel schlimmer als die Implementation von PHP ist jedoch das Design.
>
> Rudolf Polzer in de.comp.security.misc


To briefly summarize the argument:

What INFORMATION do you want the potential intruder to have? Response
or none-response both provide information because the default
configuration is TO respond. The absence of a response itself implies
the existence of a protected service.

What about misinformation instead?

I've considered writing a tool to provide bogus responses to port scans
for some time. If broadly implimented it could make the public Internet
a significantly more dangerous place for crackers. Network scans are
like tracer bullets: they point both ways.

So it would be easy to respond to a SYN on an unused port with an ACK
bogusly sourced from a network owned by... a three lettered agency for
example. The assumption being that most scanning tools are just
crafting packets, not actually building sockets, so they are just
creating a list of exposed ports with no native ability to correlate
sent and recieved packets.

Such a system if broadly adopted could easily be expanded to provide
investigators a whole variety of information. You could even
coordinate responses by doing a DNS lookup before crafting the reply
packets.

Evil -> Server -> DNS
Evil <- Spoof <- IPAddress

In this fashion a modified DNS server passes back dynamic IP's that all
route back to a Honeypot run by the fore-mentioned three lettered
agency. Of course Dr. evil could solve it by slowing down the scans are
correlating every sent packet to every recieved packet. But slowing
down the scan rate is also an effective deterrent.

You could coordinate TCP proxies the same way. There should only be a
few honeypots on the Internet. Everyone else should run proxies to
redirect traffic to those honeypots. One well publicised case of
someone getting jailed with such a system would drastically improve
all security managers odds.

You could also do passive redirection, just like stealthing but instead
of dropping the packet, encapsulate in a public key signed message and
forwarded to a centralized honeypot for statistical analysis with other
scan recipients.

The client part isn't much code. The server system would be, and
frankly I haven't the cycles available for it. But it is interesting.


Politics is the process of exploiting the exuberantly niave.
Psy

Re: Port 113?

shrike@cyberspace.org wrote:
> I've considered writing a tool to provide bogus responses to port scans
> for some time.

Please don't do so. The net is b0rken enough, we don't need more
protocol violations.

There is no harm from port scanning.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

Volker Birk wrote:
> shrike@cyberspace.org wrote:
> > I've considered writing a tool to provide bogus responses to port scans
> > for some time.
>
> Please don't do so. The net is b0rken enough, we don't need more
> protocol violations.
>

Yep the Internet is busted. Such is the nature of distributed
development. As long as things work at the consumer level, the money
flows and only geeks notice that everything is broken.

RFC's are based on the assumption that users _want_ interoperability.
Their authority is based completely on that assumption. A scanner is
not compliant with the protocol specifications it scans to detect, so
whats the harm in the response being non-rfc-compliant as well?

Of course most RFC's are damned loose anyway. Using an RFC as a
development guide in _no_ way guarantees reliability or
interoperability. It might get you close, but only testing will make
your bugs get along with their bugs correctly. I've submitted a draft
to the IETF for an unrelated protocol, and If I remember correctly all
you need for a draft to become an RFC is TWO interoperable code bases,
and I doubt even that is substantially verified. Protocol
compatability is not neccessarily the same as RFC compliance. It could
just mean the RFC sucked to begin with.

> There is no harm from port scanning.
>
> Yours,
> VB.
> --
> Viel schlimmer als die Implementation von PHP ist jedoch das Design.
>
> Rudolf Polzer in de.comp.security.misc

I have to disagree. Scans make my firewall logs bigger, which means it
takes more time to audit them. If there were less hackers, there would
be less scans, and less of my time would be spent chasing anomolies.
That is a quantifyable budgetary expense incured by me, because of
them.

While I may be protected, a scan often indicates that _somebody_ is
going to get attacked. Consequently it is my duty to report it to the
authorities. (Whether they can hear while their head is in their ass is
another argument)

I could walk down a street knocking on every door to sell vacume
cleaners. If I turn every doorknob to see which are unlocked, the
neighbors should call the cops. Scanning a foreign class C for open
file shares is the equivilant.

Throw a hundred hackers in jail, vs. audit a billion lines of source
code. The economics of the situation are fairly obvious IMHO. Make
hacking more expensive, and less people will do it. I am confident the
spammers that are currently in jail would agree.

-Or something...
-Psy

Re: Port 113?

shrike@cyberspace.org wrote:
> RFC's are based on the assumption that users _want_ interoperability.
> Their authority is based completely on that assumption. A scanner is
> not compliant with the protocol specifications it scans to detect, so
> whats the harm in the response being non-rfc-compliant as well?
> Of course most RFC's are damned loose anyway.

Unfortunately, people are forgetting, that without respecting RFCs there
would be no communication and no Internet at all.

Very sad.

Yours,
VB.
--
Viel schlimmer als die Implementation von PHP ist jedoch das Design.

Rudolf Polzer in de.comp.security.misc

Re: Port 113?

On 09/06/06 09:56, Sebastian Gottschalk wrote:
> Well, do you think you can manipulate your ISP's router like this remotely,
> or get a technican to do so? Well, only with blatantly misconfigured
> routers like at AOL's...

No, I do not think that I can get my ISP to do this. However, seeing as how I have a globally routable subnet at my house behind a router that I control that is the uplink to the ISP, I think I can.

Consider:

--- ---

In this case, I control "Rtr A" and any thing behind it. Thus if one of the Hosts issues an "ICMP Host Unreachable" message, "Rtr A" can modify it to look like the packet is coming from it (Rtr A), not the host in question.



Grant. . . .

Re: Port 113?

Shrike:

Ok , i'll bite , assume you're a cracker and wish to learn
where my computer is and what it runs. Assume that many of
my ISP's routers are not using ICMP. Assume that my system
will not send any packets to you. Assume that
I will not initiate connections to your host. Assume that
I have altered my TCP/IP stack and clients' settings to give
as little usable information to a would-be attacker as is
feasible. Just how will my configuration help you , what
useful information do you think you will be able to acquire
from me? There are far softer targets to be found.

I personally see no point in allowing Active OS-fingerprinting
attempts. Your computer has the right to remain silent.

I agree with you that those who commit definable "suspicious"
behavior online and do so to a certain extreme , should be
sought and penalized. There are many social , legal ,
technological and financial hurdles to overcome.

Have you considered the benefits of trying to mislead/defeat
Passive OS-fingerprinting techniques?



[http://lcamtuf.coredump.cx/p0f-help/]


[http://www.showipaddress.com/]


[http://www.dnsstuff.com/tools/aboutyou.ch]



I wouldn't recommend altering your TCP/IP settings and/or
your client settings (ie. , Web-browser "User Agent" and etc.)
just to avoid OS identification. If however you wish to
change some settings anyway , for other reasons , you may
want to consider how varying changes can alter how your
computer appears to the Internet hosts you connect to.

Why would you want to "Throw a hundred hackers in jail..."?

...perhaps a hundred Microsoft hackers , anyone responsible
for such bad software can't be safe to have around... ;)

Re: Port 113?

On 7 Sep 2006, in the Usenet newsgroup comp.security.firewalls, in article
<1157645458.653547.99360@p79g2000cwp.googlegroups.com>, shrike@cyberspace.org
wrote:

>A scanner is not compliant with the protocol specifications it scans to
>detect, so whats the harm in the response being non-rfc-compliant as well?

Personally, I have better things to do with my bandwidth than to have two
robots playing games with each other. REJect the connection attempt and
get on with your life.

>I have to disagree. Scans make my firewall logs bigger, which means it
>takes more time to audit them.

Why are you logging crap that is blocked?

>If there were less hackers, there would be less scans, and less of my time
>would be spent chasing anomolies. That is a quantifyable budgetary expense
>incured by me, because of them.

Oh? And how many criminal complaints have you filed? How many convictions?
Or are you just wasting time and effort to look as if you are doing something?

>While I may be protected, a scan often indicates that _somebody_ is
>going to get attacked. Consequently it is my duty to report it to the
>authorities. (Whether they can hear while their head is in their ass is
>another argument)

How many criminal complaints have you filed? How many convictions? Sending
abuse complaints to ISP Ignore-bots doesn't count.

>Scanning a foreign class C for open file shares is the equivilant.

Spend an hour or two looking at the newsgroup archives at groups.google.com
and you see millions of articles debating whether it's the equivalent or not.
And while they are debating, they are doing absolutely nothing useful.

Oh, and classful networking is just a tad obsolete.

RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September
1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338) (Obsoleted by
RFC4632) (Status: PROPOSED STANDARD)

RFC2050 ("Internet Registry IP Allocation Guidelines" November 1996) mention
network classes in past tense - and that's ten _years_ ago. RFC4632 was
released last month if you don't feel you have time to read all of the history.

>Throw a hundred hackers in jail, vs. audit a billion lines of source
>code.

Why should closed source be audited? The sheep still buy the crap with all
of the holes unannounced - mainly because no one writing such code needs to
worry about anyone seeing their juvenile coding errors. Also you seem to
think that every country has the same laws identifying the same crimes. That
is _FAR_ from the case in fact.

>Make hacking more expensive, and less people will do it. I am confident the
>spammers that are currently in jail would agree.

Make up your mind - are you referring to assholes who crack into unsecured
systems, or the klowns sending you those offers for pills, loans, and who
cares what else?

Old guy

Re: Port 113?

Moe Trin wrote:
> On 7 Sep 2006, in the Usenet newsgroup comp.security.firewalls, in article
> <1157645458.653547.99360@p79g2000cwp.googlegroups.com>, shrike@cyberspace.org
> wrote:
>
> >A scanner is not compliant with the protocol specifications it scans to
> >detect, so whats the harm in the response being non-rfc-compliant as well?
>
> Personally, I have better things to do with my bandwidth than to have two
> robots playing games with each other. REJect the connection attempt and
> get on with your life.
>
> >I have to disagree. Scans make my firewall logs bigger, which means it
> >takes more time to audit them.
>
> Why are you logging crap that is blocked?
>
> >If there were less hackers, there would be less scans, and less of my time
> >would be spent chasing anomolies. That is a quantifyable budgetary expense
> >incured by me, because of them.
>
> Oh? And how many criminal complaints have you filed? How many convictions?
> Or are you just wasting time and effort to look as if you are doing something?
>
> >While I may be protected, a scan often indicates that _somebody_ is
> >going to get attacked. Consequently it is my duty to report it to the
> >authorities. (Whether they can hear while their head is in their ass is
> >another argument)
>
> How many criminal complaints have you filed? How many convictions? Sending
> abuse complaints to ISP Ignore-bots doesn't count.
>
> >Scanning a foreign class C for open file shares is the equivilant.
>
> Spend an hour or two looking at the newsgroup archives at groups.google.com
> and you see millions of articles debating whether it's the equivalent or not.
> And while they are debating, they are doing absolutely nothing useful.
>
> Oh, and classful networking is just a tad obsolete.
>
> RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and
> Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September
> 1993. (Format: TXT=59998 bytes) (Obsoletes RFC1338) (Obsoleted by
> RFC4632) (Status: PROPOSED STANDARD)
>
> RFC2050 ("Internet Registry IP Allocation Guidelines" November 1996) mention
> network classes in past tense - and that's ten _years_ ago. RFC4632 was
> released last month if you don't feel you have time to read all of the history.
>
> >Throw a hundred hackers in jail, vs. audit a billion lines of source
> >code.
>
> Why should closed source be audited? The sheep still buy the crap with all
> of the holes unannounced - mainly because no one writing such code needs to
> worry about anyone seeing their juvenile coding errors. Also you seem to
> think that every country has the same laws identifying the same crimes. That
> is _FAR_ from the case in fact.
>
> >Make hacking more expensive, and less people will do it. I am confident the
> >spammers that are currently in jail would agree.
>
> Make up your mind - are you referring to assholes who crack into unsecured
> systems, or the klowns sending you those offers for pills, loans, and who
> cares what else?
>
> Old guy

All would be clear if you'd read my post from the 6th. If you are
unable to put together the two messages in a coherent fashion, your
attempt at enlightenment is futile.

-Psy

Re: Port 113?

On 8 Sep 2006, in the Usenet newsgroup comp.security.firewalls, in article
<1157753471.193775.202190@e3g2000cwe.googlegroups.com>, shrike@cyberspace.org
wrote:

>All would be clear if you'd read my post from the 6th.

If by that, you mean <1157753471.193775.202190@e3g2000cwe.googlegroups.com>,
I'm afraid that proves nothing. Would you like to spoof some stupid spammer
into believing 162.45.67.89 is wide open for the taking, I think you're
missing a few points. Actually, I've already seen idiots using that /16
as a purported source of windoze messenger spam. Contrary to your wildest
dreams, three letter agencies, whether the BIA, FBI, NSA or a few others,
really have more important things on their tables.

Of the systems I've bothered to trace (relatively easy with TCP, very hard
with UDP), most are the usual windoze lusers whose systems are running
sluggishly because they are infested with mal-ware. If you think those boxes
have even the slightest clue where the controller is hiding, you really
ought to spend some time reading at Bugtraq where Matthias Leisi posted
some interesting material, or read news.admin.net-abuse.misc and see the
posts yesterday from "Spamhuntress". She mentions finding a spam site
unwittingly hosted by a church. I'm so sure the FBI would want to arrest
those criminals.

By the way, did you ever get your 11000 executables down to something
reasonable (I know you posted that you had made substantial headway), or is
that why you are posting with windoze?

Old guy

Re: Port 113?

Moe Trin wrote:
> On 8 Sep 2006, in the Usenet newsgroup comp.security.firewalls, in article
> <1157753471.193775.202190@e3g2000cwe.googlegroups.com>, shrike@cyberspace.org
> wrote:
>
> >All would be clear if you'd read my post from the 6th.
>
> If by that, you mean <1157753471.193775.202190@e3g2000cwe.googlegroups.com>,
> I'm afraid that proves nothing.

Which would be a good point had I any interest in proving anything.

>Would you like to spoof some stupid spammer
> into believing 162.45.67.89 is wide open for the taking, I think you're
> missing a few points. Actually, I've already seen idiots using that /16
> as a purported source of windoze messenger spam. Contrary to your wildest
> dreams, three letter agencies, whether the BIA, FBI, NSA or a few others,
> really have more important things on their tables.
>

No doubt. But that doesn't negate the need to address the
millions/billions? of dollars in annual damage caused by system
cracking, and/or malware.

> Of the systems I've bothered to trace (relatively easy with TCP, very hard
> with UDP), most are the usual windoze lusers whose systems are running
> sluggishly because they are infested with mal-ware. If you think those boxes
> have even the slightest clue where the controller is hiding, you really
> ought to spend some time reading at Bugtraq where Matthias Leisi posted
> some interesting material, or read news.admin.net-abuse.misc and see the
> posts yesterday from "Spamhuntress". She mentions finding a spam site
> unwittingly hosted by a church. I'm so sure the FBI would want to arrest
> those criminals.

I am suprised you are unable to bridge the gap between the church that
is compromised, and the effects of a decentralized system for
collecting data on those responsible for the attack. Perhaps such a
system integrated with an RBL would have protected the church in
question?

>
> By the way, did you ever get your 11000 executables down to something

Actually yes, thanks for asking. The box has customers on it now. I've
been monitoring it, and it seems both stable and secure.

> reasonable (I know you posted that you had made substantial headway), or is
> that why you are posting with windoze?
>
> Old guy

Am I supposed to be impressed? I run Cygwin. I have customers that send
proprietary file types. Don't you?

I'm having a hard time understanding your antagonistic position.
Perhaps you are working on something similar and are trying to protect
your intellectual property? Don't worry, I haven't published anything,
and probably won't. Innovation in your line of work usually has
unforseen ethical implications. Been there, done that, regretted it.

-Have a Nice day.
-Psy

Re: Port 113?

On 10 Sep 2006, in the Usenet newsgroup comp.security.firewalls, in article
<1157893087.864116.83130@d34g2000cwd.googlegroups.com>, shrike@cyberspace.org
wrote:

>Moe Trin wrote:

>> Contrary to your wildest dreams, three letter agencies, whether the
>> BIA, FBI, NSA or a few others, really have more important things on
>> their tables.

>No doubt. But that doesn't negate the need to address the
>millions/billions? of dollars in annual damage caused by system
>cracking, and/or malware.

There are laws on the books in many jurisdictions around the world that
address this problem. You might notice how many are actually being
enforced, never mind how many convictions occurred. Jurisdictions have
borders, and their authority rarely crosses those.

Hit google, and look up "Stacheldraht" (German for "barbed wire").

>> She mentions finding a spam site unwittingly hosted by a church. I'm so
>> sure the FBI would want to arrest those criminals.
>
>I am suprised you are unable to bridge the gap between the church that
>is compromised, and the effects of a decentralized system for
>collecting data on those responsible for the attack. Perhaps such a
>system integrated with an RBL would have protected the church in
>question?

That's really funny. You have people who are at their knowledge limits
trying to figure out how to use a power switch on a computer, and you're
going to add more layers of stuff they have no capability of or desire in
understanding? Please remember that the overwhelming majority of computers
on the Internet are run by people who don't even understand the concept of
a firewall, never mind a blocklist. By the way, she ("Spamhuntress")
_called_ the church, and they hung up on her - twice.

Old guy

Re: Port 113?

Moe Trin wrote:
> On 10 Sep 2006, in the Usenet newsgroup comp.security.firewalls, in article
> <1157893087.864116.83130@d34g2000cwd.googlegroups.com>, shrike@cyberspace.org
> wrote:
>
> >Moe Trin wrote:
>
> >> Contrary to your wildest dreams, three letter agencies, whether the
> >> BIA, FBI, NSA or a few others, really have more important things on
> >> their tables.
>
> >No doubt. But that doesn't negate the need to address the
> >millions/billions? of dollars in annual damage caused by system
> >cracking, and/or malware.
>
> There are laws on the books in many jurisdictions around the world that
> address this problem.

Correct. I am not proposing a law. Simply a system for reducing the
economic investment required to _enforce_ the law.

>You might notice how many are actually being
> enforced, never mind how many convictions occurred. Jurisdictions have
> borders, and their authority rarely crosses those.

And why is that? I would estimate that the lack of enforcement is due
to the high investment required to acheive enforcement. No ground
pounder is going to give up his bullet proof vest so the department can
hire an analyst.

However, if you had an open source community-watch application with a
broad installation base, then the investment requirements are
substantially reduced making the enforcement more plausible.

If granny picks up the phone and reports a burglary next door, it is
substantially cheaper than installing a CCTV system, nearly as
effective, and has less privacy implications.

At this time there is NO technological equivilant to granny. What I am
proposing is that development is this direction may be more fruitfull
than insuring that everyone runs ultra-paranoid security policies.

>
> Hit google, and look up "Stacheldraht" (German for "barbed wire").
>
> >> She mentions finding a spam site unwittingly hosted by a church. I'm so
> >> sure the FBI would want to arrest those criminals.
> >
> >I am suprised you are unable to bridge the gap between the church that
> >is compromised, and the effects of a decentralized system for
> >collecting data on those responsible for the attack. Perhaps such a
> >system integrated with an RBL would have protected the church in
> >question?
>
> That's really funny. You have people who are at their knowledge limits
> trying to figure out how to use a power switch on a computer, and you're
> going to add more layers of stuff they have no capability of or desire in
> understanding?

Already done. The latest netscape already includes a psuedo-RBL, and it
is fairly idiot proof. And we are taking about a fairly transparent
service. How much admin has to be done to run a proxy on a socket
commonly used for a backdoor? Uh... Install it. Done! Yay.

Not to mention that it would be effective without the direct assistance
of consumers. If 1/100 of the servers out there sported proxy-pots,
(proxied honeypots) the results would probably be quite telling.

Lets not forget that security product vendors already have similar
practices for doing threat analysis for their own products. Their
results are proprietary. My suggestion is an equivilant system that is
public domain.

> Please remember that the overwhelming majority of computers
> on the Internet are run by people who don't even understand the concept of
> a firewall, never mind a blocklist. By the way, she ("Spamhuntress")
> _called_ the church, and they hung up on her - twice.
>
> Old guy

Please remember that you only have to catch the bad guy once in a
while. So throwing up your arms and waiting for the Apocolypse because
consumers are clueless is rediculous. Consumers have better things to
do with their time.

There are plenty of working volunteer based distributed processing
systems. The search for primes, and the SETI are examples. I see no
reason why a distributed system for trapping hackers wouldn't work.
Like I said before, I'm not going to write it. But I predict somebody
will.

Of course by that time you'll have moved on to condescending to someone
else about some other innovative concept that your confident won't ever
be usefull.

-Psy