[Info-vax] What to do with my VAX.....

[Arne Vajhøj]

On 11/20/2020 7:35 AM, seasoned_geek wrote:
> On Wednesday, November 11, 2020 at 6:16:54 PM UTC-6, Arne Vajhøj
> wrote:
>> On 11/11/2020 11:52 AM, seasoned_geek wrote:
>>> Even when one has a firewall in a router, PASSTHROUGH PORTS ARE
>>> ENABLED for many things.
>> Hopefully all ports inbound are closed.
> 
> They generally cannot be.

Of course they can.

It is standard for such products to come with all inbound ports closed.

>>> A firewall is not taking a free-form XML/whatever "open"
>>> Internet message and chopping it down into a fixed field length
>>> fixed record width message for a queue. This means the people
>>> stuffing a billing characters or some other nonsense into that
>>> free format message to trigger an overrun so they can perform an
>>> SQL injection or some other hack physically can't happen. When
>>> someone tries to move a billion characters into a COBOL PIC X(25)
>>> field, what happens? The first 25 characters make it and the rest
>>> land in the bit bucket.
>> Protocol conversion is sometimes used.
>> 
>> But then it will typical be:
>> 
>> --firewall--protocol conversion--firewall--backend system
>> 
>> For the same reason as firewall in front of system is better than
>> "software firewall" on system. Better isolation - less risk in case
>> something bad happens in the protocol conversion.
>> 
>> And stuffing into fixed length format is totally insufficient as
>> data validation.
> 
> Nobody said it was data validation. It is protection. By itself it
> stops 100% of the data overrun exploits

Actually it enables data overrun exploits if the code is bad.

Data overruns are a fixed length format problem only.

>                                     and an extremely high number
> of SLQ injection techniques. I won't say all because I cannot be
> certain there isn't one that can do it within the 35 characters
> allowed for a street address line.

Have you ever read anything about SQL injection?

35 characters is more than sufficient for many cases of SQL injection.

>>> You are completely incorrect about Security by Obscurity as well.
>>> ALL ENCRYPTION is security by obscurity. Period.
>> Not by the definition of security by obscurity commonly used.
> 
> Not by _your_ definition.

Given that the wikipedia article use the same definition and
that other people here also use that definition, then it is
obviously not my definition.

Arne