Will Multinet in VSI VMS come with an integrated firewall ?

[Simon Clubley]

Will the port of Multinet to VSI VMS come with an integrated firewall ?

If it doesn't then should it ?

Don't forget that firewalls can be used to stop outgoing connections
as well as incoming ones so it could be a good tool if the VMS system
gets compromised.

I like the idea of an integrated firewall so that VMS processes
attempting to make an unauthorised outgoing connection would see
the connection attempt fail immediately and the attempt would be
logged in the VMS security logs.

The firewall could also control by port where packets for certain
destination ports could be sent (so that you couldn't get past the
firewall by adding extra payload data to DNS lookups for example
and sending it to an unauthorised DNS server.)

In large organisations this would probably be handled at the
network boundaries themselves and not on individual systems,
but I can see situations when having a firewall on the VMS system
itself could be useful (even in large organisations as maybe an
extra safeguard).

What do you think ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Stephen Hoffman]

On 2017-03-15 13:35:39 +0000, Simon Clubley said:

> ...an integrated firewall ?...

>
> What do you think ?

Firewalls are table stakes.

From 1994... https://www.cs.columbia.edu/~smb/talks/firewalls.pdf

Most of that is a review to folks that have experience with firewalls,
though page 5 has a one-page summation of the mess we're still dealing
with.

Firewall integration with signed apps and sandboxing would be useful,
but OpenVMS presently lacks the infrastructure to implement any that.


--
Pure Personal Opinion | HoffmanLabs LLC

[Paul Sture]

On 2017-03-15, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2017-03-15 13:35:39 +0000, Simon Clubley said:
>
>> ...an integrated firewall ?...
>>
>> What do you think ?
>
> Firewalls are table stakes.
>
> From 1994... https://www.cs.columbia.edu/~smb/talks/firewalls.pdf
>
> Most of that is a review to folks that have experience with firewalls,
> though page 5 has a one-page summation of the mess we're still dealing
> with.

A problem with hardware firewalls is that of keeping firmware up to date.

FWIW when I looked at commercial grade firewalls almost a decade ago,
the prices were high enough to equal several years' worth of renting
a web capable VPS with more than adequate bandwidth.

> Firewall integration with signed apps and sandboxing would be useful,
> but OpenVMS presently lacks the infrastructure to implement any that.

Also application logging, and that should cover security events. In many
cases only the application itself can determine whether a given event is
benign or hostile.

From 2010, "How to Do Application Logging Right":

<http://arctecgroup.net/pdf/howtoapplogging.pdf>

--
A supercomputer is a device for turning compute-bound problems into
I/O-bound problems. ---Ken Batcher

[Stephen Hoffman]

On 2017-03-15 20:00:14 +0000, Paul Sture said:

> A problem with hardware firewalls is that of keeping firmware up to date.
>
> FWIW when I looked at commercial grade firewalls almost a decade ago,
> the prices were high enough to equal several years' worth of renting a
> web capable VPS with more than adequate bandwidth.

I've found ZyXEL ZYWALL USG series does pretty well as commercial
firewall options go, with a consistent and reasonable user interface
with some clever touches, and with a range of bandwidths and features,
and with reasonable prices for what you get, but they're definitely not
introductory-level devices; the UI does expect the user to have some
familiarity with IP, VPNs and related tech. But then the VPS prices
have continued to drop, too. There are various decent hosting options
available at US$10 to US$20 per month, and which is part of why folks
are migrating various apps.

[Robert A. Brooks]

On 3/15/2017 4:00 PM, Paul Sture wrote:
> FWIW when I looked at commercial grade firewalls almost a decade ago,
> the prices were high enough to equal several years' worth of renting
> a web capable VPS with more than adequate bandwidth.

https://www.netgate.com/appliances/pfsense-smb.html

I have the SG-2440 for my home gigabit connection, and am quite happy with it.

The SG-2200 probably would have been enough for me, in retrospect.

--

-- Rob

[Arne Vajhøj]

On 3/15/2017 9:35 AM, Simon Clubley wrote:
> Will the port of Multinet to VSI VMS come with an integrated firewall ?
>
> If it doesn't then should it ?
>
> Don't forget that firewalls can be used to stop outgoing connections
> as well as incoming ones so it could be a good tool if the VMS system
> gets compromised.
>
> I like the idea of an integrated firewall so that VMS processes
> attempting to make an unauthorised outgoing connection would see
> the connection attempt fail immediately and the attempt would be
> logged in the VMS security logs.
>
> The firewall could also control by port where packets for certain
> destination ports could be sent (so that you couldn't get past the
> firewall by adding extra payload data to DNS lookups for example
> and sending it to an unauthorised DNS server.)
>
> In large organisations this would probably be handled at the
> network boundaries themselves and not on individual systems,
> but I can see situations when having a firewall on the VMS system
> itself could be useful (even in large organisations as maybe an
> extra safeguard).
>
> What do you think ?

As a matter of religious belief I think that it is very unfortunate
that hardware firewalls and software firewalls both are called firewalls
as I think they are very different beasts.

Windows firewalls has been pushed for more than 15 years with the
argument that they catch outbound connections. But has anyone ever
heard of malware being caught by that? I have not! If it had
a real effect there should be plenty of examples.

That said then a basic firewall similar to Linux iptables
makes sense to me. I would prefer if it was called a
network hardening tool or similar instead of a firewall.
But it is called a firewall.

Arne

[Simon Clubley]

On 2017-03-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> Windows firewalls has been pushed for more than 15 years with the
> argument that they catch outbound connections. But has anyone ever
> heard of malware being caught by that? I have not! If it had
> a real effect there should be plenty of examples.
>

Or maybe any contained damage simply gets cleaned up without it
becoming public knowledge - after all it's the failures rather than
the successes which get publicised in today's world.

> That said then a basic firewall similar to Linux iptables
> makes sense to me. I would prefer if it was called a
> network hardening tool or similar instead of a firewall.
> But it is called a firewall.
>

Ironic that a commodity operating system now has better security
in a number of areas (including MAC security) than a operating
system promoted as a secure operating system does.

And yes, something like iptables with a logging capability is what
I am thinking of. For incoming connections, I wouldn't mind seeing
specific IP addresses being (optionally) automatically blacklisted
for a period of time if breakin evasion is triggered.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Simon Clubley via Info-vax
> Sent: March 16, 2017 10:18 AM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

> On 2017-03-15, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >
> > Windows firewalls has been pushed for more than 15 years with the
> > argument that they catch outbound connections. But has anyone
> ever
> > heard of malware being caught by that? I have not! If it had a real
> > effect there should be plenty of examples.
> >
>
> Or maybe any contained damage simply gets cleaned up without it
> becoming public knowledge - after all it's the failures rather than the
> successes which get publicised in today's world.
>
> > That said then a basic firewall similar to Linux iptables makes sense
> > to me. I would prefer if it was called a network hardening tool or
> > similar instead of a firewall.
> > But it is called a firewall.
> >
>
> Ironic that a commodity operating system now has better security in a
> number of areas (including MAC security) than a operating system
> promoted as a secure operating system does.
>
> And yes, something like iptables with a logging capability is what I am
> thinking of. For incoming connections, I wouldn't mind seeing specific
> IP addresses being (optionally) automatically blacklisted for a period of
> time if breakin evasion is triggered.
>
> Simon.
>

In large data centres today, the trend is to use HW FW's for what is called north-south traffic (traffic from servers in-out of DC) and software host based FW's on servers for east-west traffic (traffic internal between servers in same DC). A host based FW allows groups to further isolate their App environment from internal attacks.

Multinet (and I assume the new TCPIP from VSI) does have a nice security IPS feature:
http://www.process.com/psc/fileadmin/user_upload/case_studies/multinet/ips_casestudy_3ex.pdf
"IPS is a highly flexible and customizable security feature that allows for both MultiNet and user applications to detect and defeat potential security threat events in real-time. IPS is being used to protect OpenVMS systems across the globe today."

"The IPS feature monitors network and/or system activities for malicious or unwanted behavior and can react in real-time to block or prevent those threats. MultiNet SSH, FTP, SNMP, TELNET, IMAP, SMTP, and POP3 have been instrumented with IPS to report suspicious activity to a highly flexible and customized central filter server. The filter server will then use pre-configured rules to determine if it should block an intruder’s IP address from accessing the system and/or if it should prevent an intruder from accessing a specific application. For example, it can detect when a bogus username or invalid password is being used in an attempt to access a system. The time period that the filter is in place is configurable. An API is provided so that customers can incorporate the IPS functionality into their applications."

Note that there used to be a "Digital Firewall for OpenVMS" product. Obviously has not been around for awhile, but I still have the kit and admin guide (dated 1997). The SPD was SP5626PF.PDF and it was part of the "OpenVMS Internet Product Suite"

Question to VSI - does anyone know if the "Digital Firewall for OpenVMS" code is still available for potential resurrection at some future point?

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Robert A. Brooks]

On 3/17/2017 11:17 PM, Kerry Main wrote:

> Question to VSI - does anyone know if the "Digital Firewall for
> OpenVMS" code is still available for potential resurrection at some
> future point?

I've never seen it, and I've pretty much looked at everthing we got
from HP.

It likely didn't survive the DEC--->CPQ transition, let alone CPQ--->HP.

--

-- Rob

[Stephen Hoffman]

That was likely the old Digital SecurityGate product for DECnet (prefix
was NSG), from the security group that was based in ZKO. That
development group was separate from and was later merged into OpenVMS
development back in the early 1990s.

There were intended to be two packages in that product series, the far
more familiar offering was the DECnet firewall — that was the DSG (NSG)
package that most folks saw, and it was a relative to the ZKO internal
DECnet firewall. There was a second firewall variant or option or
package intended to add IP support that was under development, and that
was tied into the filtering hooks that were available in some versions
of TCP/IP Services — hooks which disappeared and were reportedly
reinstated in more recent versions, though I've not gone looking for
those in a while — and the IP variant didn't last very long.

Not entirely certain that the IP firewall product ever shipped. If my
recollection is correct, the entire OpenVMS-based firewall effort was
cancelled before the IP support was released. I don't recall whether
the DSG product was ever ported to Alpha.

Probably better off looking at the BSD-licensed pf packet filter these
days, as the features and capabilities of any 1990s-era firewall code —
if that code can be located — won't have anywhere near what's typically
expected. That's obviously assuming that the pf code can be ported
over and connected into whatever filtering connection is available in
VSI IP, and that's assuming the VSI IP code doesn't have a firewall.

pf: http://www.openbsd.org/faq/pf/ et al.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: March 18, 2017 12:50 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

Not saying this is anywhere near to todays standards, but it certainly looks like something to investigate.

>From the Digital OpenVMS Firewall V1.0 Admin Guide: (VAX and Alpha support, focus is TCPIP)

This guide is intended for system administrators who are installing, configuring, or managing a Digital Firewall for OpenVMS system. As a firewall system administrator, you should have experience with the following across both VAX and Alpha hardware platforms:
- Digital OpenVMS system management, which includes assembling the system hardware as well as installing and configuring the operating system and layered software components

- Digital TCP/IP Services for OpenVMS management, which includes installing and configuring the software

- Network administration and management, which includes network routing, configuring the Domain Name Service (DNS), and maintaining system and network security

---

The Digital Firewall for OpenVMS system is based on the following principles:
- Every connection that comes to the firewall is examined. If the connection does not conform to the security policy specified by the system administrator, it is rejected.

- Trusted application gateways are used to provide greater control over access to services from an external network than standard OpenVMS security services can provide.

- All events involving the firewall are logged. The system administrator is automatically alerted to illegal connection attempts and other unusual events.

---

Supports the following service types:
- Gateway Services
- Time Services
- Domain Name Services
- FTP
- Telnet
- Web
- Mail
- other services - The Digital Firewall for OpenVMS includes a generic application gateway. You can use this gateway to connect users to services for which the Digital Firewall for OpenVMS does not provide a specific application gateway. For example, you can use a generic application gateway to enable a client to access an SQL server located on the other side of the firewall.

---

GUI Interface:

The Digital Firewall for OpenVMS software provides a graphical user interface (GUI) to make the task of configuring and managing the firewall as easy as possible. Extensive online help is provided for the various firewall tasks as well as the common GUI features such as menus, check boxes, radio buttons, and push buttons.

[Simon Clubley]

On 2017-03-17, Kerry Main <kemain...@gmail.com> wrote:
>
> Multinet (and I assume the new TCPIP from VSI) does have a nice security IPS
> feature:
> http://www.process.com/psc/fileadmin/user_upload/case_studies/multinet/ips_casestudy_3ex.pdf
> "IPS is a highly flexible and customizable security feature that allows for
> both MultiNet and user applications to detect and defeat potential security
> threat events in real-time. IPS is being used to protect OpenVMS systems
> across the globe today."
>

That explains why I didn't find it before posting. I quickly searched for
Multinet Firewall and not Multinet IPS.

> "The IPS feature monitors network and/or system activities for malicious
> or unwanted behavior and can react in real-time to block or prevent those
> threats. MultiNet SSH, FTP, SNMP, TELNET, IMAP, SMTP, and POP3 have been
> instrumented with IPS to report suspicious activity to a highly flexible
> and customized central filter server. The filter server will then use

> pre-configured rules to determine if it should block an intruder?s IP

> address from accessing the system and/or if it should prevent an intruder
> from accessing a specific application. For example, it can detect when a
> bogus username or invalid password is being used in an attempt to access a
> system. The time period that the filter is in place is configurable. An API
> is provided so that customers can incorporate the IPS functionality into
> their applications."
>

This is _exactly_ the kind of thing I am thinking of for incoming
connections, but it's not clear from the above description if you can
restrict outgoing connections initiated by the VMS system as well.

[Forster, Michael]

qZ
Having used and chosen and implemented MultiNet at a number of sites across the US and having utilized support over the years, most recently through Process Software, I would recommend purchasing MultiNet and support directly from them. First class. Yes some great people have moved on however there are still some great people there with serious tenure. Not to knock newer staff!

Don't forget to look at PMDF.

Michael Forster
Enterprise Storage and IDX Architect | Information Services
Medical College of Wisconsin
O: (414) 955-4967 | mfor...@mcw.edu


________________________________________
From: Info-vax <info-vax...@rbnsn.com> on behalf of Simon Clubley via Info-vax <info...@rbnsn.com>
Sent: Sunday, March 19, 2017 7:07:39 PM

To: info...@rbnsn.com
Cc: Simon Clubley

Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an integrated firewall ?

On 2017-03-17, Kerry Main <kemain...@gmail.com> wrote:
>
> Multinet (and I assume the new TCPIP from VSI) does have a nice security IPS
> feature:

> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.process.com_psc_fileadmin_user-5Fupload_case-5Fstudies_multinet_ips-5Fcasestudy-5F3ex.pdf&d=DwICAg&c=aFamLAsxMIDYjNglYHTMV0iqFn3z4pVFYPQkjgspw4Y&r=2i3Iy38OaXCqI2PNgrM4Aw&m=OpZw5EoZdpet553iC9q1mADtuFe4Om0qT9kgDdk3pTE&s=vftvYHel6KkWZvQDnrTfWTuvNrZmdEI3AAD3-591j24&e=

_______________________________________________
Info-vax mailing list
Info...@rbnsn.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__rbnsn.com_mailman_listinfo_info-2Dvax-5Frbnsn.com&d=DwICAg&c=aFamLAsxMIDYjNglYHTMV0iqFn3z4pVFYPQkjgspw4Y&r=2i3Iy38OaXCqI2PNgrM4Aw&m=OpZw5EoZdpet553iC9q1mADtuFe4Om0qT9kgDdk3pTE&s=_wROdn-iBH80ikpGOxGC5GawJc3rn2DWhmvg3Flc330&e=

[Stephen Hoffman]

On 2017-03-20 00:07:39 +0000, Simon Clubley said:

> That explains why I didn't find it before posting. I quickly searched
> for Multinet Firewall and not Multinet IPS.

Not using common terminology isn't a great starting place for product
documentation. That rather similar to sketchy examples too, but I
digress. Resumés aren't the only documents that are scanned quickly
or increasingly automatically and for common terms, after all.

> ...if you can restrict outgoing connections initiated by the VMS system
> as well.

A $200 box can do that, as can most existing server network
infrastructure. It's common to isolate OpenVMS configurations in
general, pending some future upgrade implementing TLS/DTLS or IPsec
throughout.

[Hans Bachner]

Stephen Hoffman schrieb am 20.03.2017 um 14:59:
> On 2017-03-20 00:07:39 +0000, Simon Clubley said:
>
>> That explains why I didn't find it before posting. I quickly searched
>> for Multinet Firewall and not Multinet IPS.
>
> Not using common terminology isn't a great starting place for product

> documentation. [snip]

With my limited knowledge of English I would not use firewall and IPS as
synonyms. I'd expect much more sophisticated mechanisms and facilities
from an IPS than from a firewall.

Of course, I might be wrong with this assumption.

Hans.

[Arne Vajhøj]

My understanding is that:

traditional network firewall - work at transport layer

IPS / application firewall - work at application layer

Arne

[Stephen Hoffman]

What's the goal here? Making the documentation more approachable?
Or making it fundamentally worse?

This thread started because an experienced user could not locate the
documentation! What does that — what should that — tell you about the
documentation?

If we're looking to help folks learn and to use the operating system,
then the inclusion of common terminology and of cogently-written
examples would be my preference.

[Simon Clubley]

On 2017-03-20, Hans Bachner <ha...@bachner.priv.at> wrote:
> Stephen Hoffman schrieb am 20.03.2017 um 14:59:
>> On 2017-03-20 00:07:39 +0000, Simon Clubley said:
>>
>>> That explains why I didn't find it before posting. I quickly searched
>>> for Multinet Firewall and not Multinet IPS.
>>
>> Not using common terminology isn't a great starting place for product
>> documentation. [snip]
>
> With my limited knowledge of English I would not use firewall and IPS as
> synonyms. I'd expect much more sophisticated mechanisms and facilities
> from an IPS than from a firewall.
>

Firewall is the standard term in use these days, but with the
understanding that there are widely different capabilities between
various firewall products, especially when you are talking about
host integrated versus network based standalone firewalls.

I would have expected to find a documentation link to a description
of the Multinet firewall while doing a Google search and this link
would contain a description of what this specific firewall was
capable of doing so I could compare it with other firewall products.

It would never, never, have occured to me to search for Multinet IPS.

> Of course, I might be wrong with this assumption.
>

10-20 years ago, firewalls used to be limited things (compared to
today) with a standard set of capabilities; that's no longer true
these days. The products are all called firewalls now and the
documentation is the vendor's opportunity to describe what their
specific firewall is capable of doing.

[Arne Vajhøj]

On 3/21/2017 12:21 PM, Stephen Hoffman wrote:
> On 2017-03-21 01:00:25 +0000, Arne Vajh j said:
>> On 3/20/2017 3:47 PM, Hans Bachner wrote:
>>> Stephen Hoffman schrieb am 20.03.2017 um 14:59:
>>>> On 2017-03-20 00:07:39 +0000, Simon Clubley said:
>>>>
>>>>> That explains why I didn't find it before posting. I quickly searched
>>>>> for Multinet Firewall and not Multinet IPS.
>>>>
>>>> Not using common terminology isn't a great starting place for product
>>>> documentation. [snip]
>>>
>>> With my limited knowledge of English I would not use firewall and IPS as
>>> synonyms. I'd expect much more sophisticated mechanisms and facilities
>>> from an IPS than from a firewall.
>>>
>>> Of course, I might be wrong with this assumption.
>>
>> My understanding is that:
>>
>> traditional network firewall - work at transport layer
>>
>> IPS / application firewall - work at application layer
>

> What's the goal here? Making the documentation more approachable? Or
> making it fundamentally worse?
>
> This thread started because an experienced user could not locate the
> documentation! What does that — what should that — tell you about the
> documentation?
>
> If we're looking to help folks learn and to use the operating system,
> then the inclusion of common terminology and of cogently-written
> examples would be my preference.

Not that I disagree with what you wrote. But does it relate to this
semi-relevant sub-thread?

Arne

[Stephen Hoffman]

On 2017-03-21 23:18:06 +0000, Arne Vajh j said:

> Not that I disagree with what you wrote. But does it relate to this
> semi-relevant sub-thread?

Distinguishing among what is a "firewall" and what is an "IDS" or "IPS"
is murky at best, and this is — as was the case with the start if this
thread — a distinction that's not particularly useful to anyone that's
searching for a common term such as "firewall". Want to add IDS or
IPS or other TLAs and XTLAs as additional search targets in the doc?
Have at. But the generic term here is "firewall", and firewalls
increasingly provide IDS and IPS capabilities.

Some background on firewalls, for those that have not worked with
what's been available in recent years...
https://en.wikipedia.org/wiki/Firewall_(computing)#Third_generation:_application_layer

https://en.wikipedia.org/wiki/Next-Generation_Firewall

One example open-source firewall:
https://doc.pfsense.org/index.php/Features_List — snort, tools to scan
mail, web content — getting tougher without MITM, and US CERT
recommends against that — and a variety of other detection and
prevention and supporting features are included. There are
commercial firewall packages with these and other IDS- and IPS-like
capabilities, as well.

ps: I'd originally considered using the quote "a difference that makes
no difference is no difference" here, but this particular difference
made the relevant documentation more difficult to locate.
Documentation that is more difficult to locate might be useful for
increasing the difficulty and the frustration and the costs incurred
among inexperienced or infrequent users, but that's generally not
considered auspicious approach. Obviously.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of

> Stephen Hoffman via Info-vax
> Sent: March 21, 2017 9:34 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>

> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

IPS (Intrusion Prevention System), IDS (Intrusion Detection System) and Firewall are all different products with each having a different focus on different aspects of network security vulnerabilities.

A firewall is NOT an IPS system and vice versa. Hence, why would one expect to find firewall in a product description for a product like Multinet which features an IPS capability?

Reference:
http://searchsecurity.techtarget.com/Do-you-need-an-IDS-or-IPS-or-both

Extract from web:
" If an IPS is a control tool, then an IDS is a visibility tool. Intrusion Detection Systems sit off to the side of the network, monitoring traffic at many different points, and provide visibility into the security posture of the network."

[Stephen Hoffman]

On 2017-03-25 15:17:04 +0000, Kerry Main said:
>
> IPS (Intrusion Prevention System), IDS (Intrusion Detection System) and
> Firewall are all different products with each having a different focus
> on different aspects of network security vulnerabilities.
>
> A firewall is NOT an IPS system and vice versa. Hence, why would one
> expect to find firewall in a product description for a product like
> Multinet which features an IPS capability?

1: most modern commercial-grade firewalls do provide some form of IPS
and IDS capabilities,
2: documentation that does not reference common terminology familiar
with and used by end-users — as started off this thread — doesn't often
help the intended users of the documentation.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: March 26, 2017 1:18 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

> On 2017-03-25 15:17:04 +0000, Kerry Main said:
> >
> > IPS (Intrusion Prevention System), IDS (Intrusion Detection System)
> > and Firewall are all different products with each having a different
> > focus on different aspects of network security vulnerabilities.
> >
> > A firewall is NOT an IPS system and vice versa. Hence, why would
> one
> > expect to find firewall in a product description for a product like
> > Multinet which features an IPS capability?
>
> 1: most modern commercial-grade firewalls do provide some form of
> IPS and IDS capabilities,

>From the link I provided in my previous response:
http://searchsecurity.techtarget.com/Do-you-need-an-IDS-or-IPS-or-both

"The combination of an IPS and a firewall into a single system, with a single management system, is attractive. Unfortunately, most unified threat management systems (UTMs) are designed for SMB deployment, an environment where the simplicity of the management system is one of the most critical design requirements. Combining IPS management with firewall management is a very difficult task. In fact, no product vendor has successfully managed to merge their web-based firewall management system with a good IPS management tool."

> 2: documentation that does not reference common terminology
> familiar with and used by end-users — as started off this thread —
> doesn't often help the intended users of the documentation.
>

Different products, different documentation .. its like calling a van a truck .. same thing, only different.

An IPS is usually a separate appliance from the firewall.

Those in the enterprise DC space would not call a firewall an IPS or vice versa.

[Scott Dorsey]

Well, the problem is that everyone calls any security-related system a
"firewall" these days, and often the systems call themselves that even
when they aren't. So the name is meaningless anyway.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Stephen Hoffman]

On 2017-03-26 17:54:55 +0000, Kerry Main said:

> Different products, different documentation .. its like calling a van a
> truck .. same thing, only different.

If the goal is to create utterly unapproachable and inaccessible and
generally impenetrable documentation, I'd agree.

Technical accuracy is a good thing.

Technical accuracy that comes at the expense of not being able to find
the requisite documentation given common search terms, or other similar
documentation design errors, or wading through seas of acronyms, not so
much.

Much of the perceived quality of the OpenVMS documentation was due to
the skills of the tech writers. The standards and practices that
they followed, too. (Various of those practices and doc designs are
now sadly dated, but that's fodder for another day.)

Writing good documentation — and even providing apparently-simple
features in the documentation, such as a useful index or of searchable
content — involves a whole lot more thought than many realize, and what
differentiates good documentation from bad can be subtle. Experienced
users just don't think like end-users, for instance. Experienced
users know the terms. Referencing common terms — such as referencing
"firewall", in this context — is one of the most important ways to
allow end-users to access the documentation. Differentiating between
a firewall and an IDS or IPS isn't something that particularly advances
the end-user that is — as started this thread — looking for information
on the platform-integrated firewall, either. Leaving the end-user
unable to locate the requisite documentation — as started this thread —
doesn't help the end-user, and doesn't make the product easier to sell
and support. "RTFM" is bad enough. Wading through pedantic or
arcane or acronym-filled documentation is worse.

In this case, this documentation should reference firewall. Maybe
also IDS or IPS when those specific capabilities are described, but —
KISS, et al — the particular mechanism that started this thread is a
software firewall.

If you can find folks that can write simple, clear, and short
documentation, try to hire them.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: March 26, 2017 3:10 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

No one would argue against clear and concise documentation, but putting "firewall" reference into a product reference like Multinet, when it does not (or even pretend to) offer a firewall capability, might be called an "alternative fact".

It offers an IPS capability and that is what the associated documentation references.

Lets agree to disagree.

[Stephen Hoffman]

On 2017-03-26 19:27:42 +0000, Kerry Main said:

> Lets agree to disagree.

We disagree on many things. On documentation and approachable
terminology, on Linux security and patches and on the increasing
necessity for app isolation, on the usefulness of DVCS packages, about
scaling and hosting using external providers, and various other topics.
But I have hope. You'll come around.

[Hunter Goatley]

On 3/26/2017 2:27 PM, Kerry Main wrote:
>
> No one would argue against clear and concise documentation, but putting "firewall" reference into a product reference like Multinet, when it does not (or even pretend to) offer a firewall capability, might be called an "alternative fact".
>
> It offers an IPS capability and that is what the associated documentation references.

Just to expand a bit: before IPS (Intruder Prevention System) existed in
MultiNet, we had added "Packet Filtering," which is the underlying
mechanism used by IPS. That section of the MultiNet Install & Admin
Guide is titled:

Using Packet Filtering for Security

http://www.process.com/docs/multinet5_5/install_admin/chapter_8.htm

From that:

"Packet filtering is used today in almost all (from basic to
sophisticated) security firewalls. Packet filtering firewalls apply
filtering rules to each packet received to determine whether to accept
or discard it. These filtering rules specify the protocol, source and
destination IP addresses, and destination ports (for TCP and UDP) for
accepted or discarded packets."

But it is true that Googling "MultiNet firewall" doesn't pull up the
link to that documentation, for some reason.

I assume it was called "Packet Filtering" and not "firewall" for
specificity.

And to answer questions, packet filtering is not applied to outgoing
packets, and no logging occurs except the logging provided by IPS.

--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
goath...@goatley.com http://hunter.goatley.com/

[Stephen Hoffman]

On 2017-03-27 10:00:43 +0000, Hunter Goatley said:

> But it is true that Googling "MultiNet firewall" doesn't pull up the
> link to that documentation, for some reason.
>
> I assume it was called "Packet Filtering" and not "firewall" for specificity.

I assume it was called that because the developers were proud of what
they created, and didn't think about the end-users. Put another way,
us OpenVMS folks have had our respective heads up our butts around
terminology and documentation writing and examples, and have completely
missed the shifts in terminology and documentation that an increasing
number of end-users expect and use and need.

We bury far too much of what we do and use and work with behind
blizzards of acronyms.

Yes, writing that's simple and concise is hard.

Yes, simpler product naming is another hard problem, too. OpenVMS has
far too many acronyms in the doc and in the names, and — seemingly
other than in DCL — eschews the use of common English words.

Yes, some few references to technical jargon and acronyms and the rest
are certainly still necessary, as there'll be a few folks that will
first search for "IPS" or "IDS" and not for "firewall". That group
probably largely comprising the folks that implemented the features and
that wrote the doc, of course. Does anyone reading here need to guess
how the names get picked and the documentation gets written this way?

> And to answer questions, packet filtering is not applied to outgoing
> packets, and no logging occurs except the logging provided by IPS.

Host-based firewall tools including pf can do that and can provide IPS,
as can the dedicated firewall I'm running. They're still commonly
called firewalls, though. Some folks do seem to like doc that's
cryptic and dense and arcane, too. I'm just not among those folks.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: March 27, 2017 12:44 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

> On 2017-03-27 10:00:43 +0000, Hunter Goatley said:
>
> > But it is true that Googling "MultiNet firewall" doesn't pull up the
> > link to that documentation, for some reason.
> >
> > I assume it was called "Packet Filtering" and not "firewall" for
> specificity.
>
> I assume it was called that because the developers were proud of
> what
> they created, and didn't think about the end-users. Put another way,
> us OpenVMS folks have had our respective heads up our butts around
> terminology and documentation writing and examples, and have
> completely missed the shifts in terminology and documentation that
> an increasing number of end-users expect and use and need.
>
> We bury far too much of what we do and use and work with behind
> blizzards of acronyms.
>
> Yes, writing that's simple and concise is hard.
>

And presenting something as something it is not is what is now known as dealing in "alternate facts".

Internet definition of a firewall -
"A firewall is a network security system, either hardware- or software-based, that uses rules to control incoming and outgoing network traffic."

Note incoming AND outgoing reference.

Those who deal in the enterprise DC space regularly deal with IPS/IDS and firewalls as separate network security devices.

> Yes, simpler product naming is another hard problem, too. OpenVMS
> has far too many acronyms in the doc and in the names, and —
> seemingly other than in DCL — eschews the use of common English
> words.
>
> Yes, some few references to technical jargon and acronyms and the
> rest are certainly still necessary, as there'll be a few folks that will
> first search for "IPS" or "IDS" and not for "firewall". That group
> probably largely comprising the folks that implemented the features
> and
> that wrote the doc, of course. Does anyone reading here need to
> guess
> how the names get picked and the documentation gets written this
> way?
>

There are likely good examples where OpenVMS naming could be improved, but saying an IPS device is the same as a firewall is not one.

> > And to answer questions, packet filtering is not applied to outgoing
> > packets, and no logging occurs except the logging provided by IPS.
>
> Host-based firewall tools including pf can do that and can provide IPS,
> as can the dedicated firewall I'm running. They're still commonly
> called firewalls, though. Some folks do seem to like doc that's
> cryptic and dense and arcane, too. I'm just not among those folks.
>

As my previous link and extract pointed out, this is only for small firewalls, but enterprise ones are separate devices - for good reason, as the article pointed out.

Note - IPS/IDS devices are expensive and becoming more like big data analytic devices.

[Hunter Goatley]

On 3/27/2017 11:43 AM, Stephen Hoffman wrote:
> On 2017-03-27 10:00:43 +0000, Hunter Goatley said:
>
>>
>> I assume it was called "Packet Filtering" and not "firewall" for
>> specificity.
>
> I assume it was called that because the developers were proud of what
> they created, and didn't think about the end-users.

I wasn't the one who did, so I can't say. But I will also say that when
that was added, end-users (system administrators) used to actually read
the documentation to learn how things worked. Plenty of our customers
use the packet filtering, because it's clearly documented in the chapter
about setting up MultiNet.

But these days, people try to Google a phrase to learn how to do what
needs to be done (I'm guilty of that, too), and if you don't use the
right keywords, you may or may not find it. Google has made it so easy
to do that that few people will sit down and just read a manual anymore.
I first learned what I knew about OpenVMS from being like Scotty and
reading the manuals for fun....

[Simon Clubley]

On 2017-03-27, Kerry Main <kemain...@gmail.com> wrote:
>
> And presenting something as something it is not is what is now known as dealing in "alternate facts".
>
> Internet definition of a firewall -
> "A firewall is a network security system, either hardware- or software-based, that uses rules to control incoming and outgoing network traffic."
>
> Note incoming AND outgoing reference.
>
> Those who deal in the enterprise DC space regularly deal with IPS/IDS and
> firewalls as separate network security devices.
>

However Kerry, you were the one who pointed me to the Multinet IPS
offering when I was asking about firewalls in x86-64 VMS... :-)

[Simon Clubley]

On 2017-03-28, Hunter Goatley <goath...@goatley.com> wrote:
>
> I wasn't the one who did, so I can't say. But I will also say that when
> that was added, end-users (system administrators) used to actually read
> the documentation to learn how things worked. Plenty of our customers
> use the packet filtering, because it's clearly documented in the chapter
> about setting up MultiNet.
>
> But these days, people try to Google a phrase to learn how to do what
> needs to be done (I'm guilty of that, too), and if you don't use the
> right keywords, you may or may not find it. Google has made it so easy
> to do that that few people will sit down and just read a manual anymore.
> I first learned what I knew about OpenVMS from being like Scotty and
> reading the manuals for fun....
>

I read full manuals all the time, even these days, so I can understand
the conceptual background to something and build a model of how it works.

However, when you are trying to find out if a product has certain
capabilities before posting, it's not unreasonable to use a Google
search as an initial jumping on point to find a section of the
manual which you need to read or even to find out the names of
products which might have what you are looking for.

[Stephen Hoffman]

On 2017-03-28 03:32:12 +0000, Kerry Main said:

> There are likely good examples where OpenVMS naming could be improved,
> but saying an IPS device is the same as a firewall is not one.

I have no problems referencing IPS or IDS in the docs, as that'll make
it easier for the few folks that look for those acronyms first. But
it's first and foremost called a firewall.

> As my previous link and extract pointed out, this is only for small
> firewalls, but enterprise ones are separate devices - for good reason,
> as the article pointed out.
> Note - IPS/IDS devices are expensive and becoming more like big data
> analytic devices.

Whatever you're reading is very unfamiliar with the market, and with
what firewalls are available now, and what the features are, and what
the current prices are.
Or whatever you're reading is looking to sell some expensive gear.
I'm routinely installing and managing network firewalls with IPS and
IDS capabilities and distributed logging, and that can feed data into
centralized services.
I'm installing some of these firewalls to allow managing private folks'
local networks remotely too, because they're that inexpensive.

[Stephen Hoffman]

On 2017-03-28 09:57:11 +0000, Hunter Goatley said:

> On 3/27/2017 11:43 AM, Stephen Hoffman wrote:
>> On 2017-03-27 10:00:43 +0000, Hunter Goatley said:
>>
>>> I assume it was called "Packet Filtering" and not "firewall" for specificity.
>>
>> I assume it was called that because the developers were proud of what
>> they created, and didn't think about the end-users.
>
> I wasn't the one who did, so I can't say. But I will also say that when
> that was added, end-users (system administrators) used to actually read
> the documentation to learn how things worked. Plenty of our customers
> use the packet filtering, because it's clearly documented in the
> chapter about setting up MultiNet.

I don't doubt it. As a developer, I can and have really gotten into
trouble writing documentation, too — I know too much, and I have to
work at understanding what I already understand and assume, and what
the end-users may not or do not or just don't want to understand. At
changes in common terms, among other details.

I railed against the use of "firewall" and "router" for years, but...
when writing docs or books or articles, I have to reference what the
end-user folks expect and search for, even if I also use and reference
the "differently-correct" terminology. But I've also learned that
"Multinet Firewall" is a whole lot more obvious to more folks than
"Multinet {IPS|IDS|TLA}", and the folks that know the IPS or IDS or
whatever might be, um, snobby about the use of "Firewall" terminology,
but they'll generally figure it out, and particularly if those terms
and acronyms are referenced in subsections or feature lists for the
component. Progressive disclosure, et al.

As an end-user, I certainly use more than a little of the features of
some very complex devices and tools. Designs with user interfaces
using progressive disclosure, and the use of common terms, and better
defaults and better abstractions really help all of us, too. But I
just don't have the time to find and read through and memorize shelves
of documentation — shelves that are larger than the OpenVMS doc sets,
and that are changing faster.

Developer tools help here, too. OpenVMS doesn't integrate
documentation and developer tools and fast local search engines and
example code, for instance. Other platforms and IDEs do.

Same for management and deployment tools, too. We're all increasingly
dealing with and managing more servers and different servers, or more
customers or users or applications or {whatever} and usually with fewer
folks and even less time...

> But these days, people try to Google a phrase to learn how to do what
> needs to be done (I'm guilty of that, too), and if you don't use the
> right keywords, you may or may not find it. Google has made it so easy
> to do that that few people will sit down and just read a manual
> anymore. I first learned what I knew about OpenVMS from being like
> Scotty and reading the manuals for fun....

Same here. That's becoming less practical in recent years. In some
cases, there either aren't manuals — I like it when I can reduce or
retire a manual or documentation because the tools or defaults or the
UI allow that — or where the manuals are vastly larger than what
OpenVMS offered, and larger than what most of us can manage to
reasonably read through and remember. And that change more often.
There are trade-offs around compatibility and defaults, too. Worse,
handing folks a bag of low-level parts doesn't end well. It never
did, but we're now getting caught by the ensuing messes. Security in
particular. With docs and frameworks and abstractions, we can either
do what we have always done, or we can re-think and adapt our products
to current user expectations.

There's no single right answer, though there are many wrong ones.
Common terms is usually a win, though.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: March 28, 2017 10:58 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

I deal with high end enterprise DC networking and security folks, so perhaps the folks you deal with are in fact somewhat different i.e. Small business types.

Bluecoat, Fortinet, Cisco all have separate IPS/IDS offerings from their firewall offerings.

<https://www.bluecoat.com/ja/documents/download/b4b3059f-fe2f-497e-b5c9-281e1e3858b9>

< http://docs.fortinet.com/uploaded/files/2028/inside-fortios-ips-52.pdf>

<http://www.cisco.com/c/en/us/products/security/ngips/index.html>

Another area where we will have to agree to disagree.

😊

[Stephen Hoffman]

On 2017-04-01 15:59:38 +0000, Kerry Main said:

> I deal with high end enterprise DC networking and security folks, so
> perhaps the folks you deal with are in fact somewhat different i.e.
> Small business types.

Ayup, I get to deal with that stuff, too. Here's one of the more
recent discussions with some of the folks I work with:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170317-cmp


But oddly enough, none of that is even particularly relevent to my
comments. Which is the use of common terminology in documentation.
Such as "firewall". That sort of thing really helps with the adoption
of the product among new customers, among other benefits. You might
think that heaping acronyms into documentation and product names is
goodness — DEC certainly did, as does HPE — but that sort of technical
writing and user interface strategy does seem rather less popular with
end-users, and rather less successful in recent years. You know, like
for an experienced and technical user — Simon — who was unable to
locate the desired documentation?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: April 1, 2017 2:23 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Will Multinet in VSI VMS come with an
> integrated firewall ?
>

Users?

Perhaps that is the reason for this disagreement here.

IPS/IDS devices are NOT purchased by end users. These devices starting price ranges are not for home or even small businesses i.e. $10-20K+. These are high end security devices used in enterprise Data centres with serious large scale security requirements.

Firewalls purchased by end users are home/small business types.

Enterprise DC types know exactly where to go when they need these high end devices and it is usually an RFP (competitive request for quote) from a few of the high end vendors (Cisco, Bluecoat, Fortigate, others etc.)

The integrated IPS offering is a great value add feature to build on for the upcoming OpenVMS IP stack. Imho, it was one of the reasons why one would pay extra $'s for Multinet over the free TCPIP stack.

I would love to see this IPS features enhanced to also include a host based firewall capability (incoming and outgoing filtering) as well, because in almost all next gen DC network designs I have been seeing, HW security devices are used to manage/monitor north-south traffic (in-out of DC), while host based firewalls are used to further manage east-west traffic (server-server data within the DC).

This is especially true with emerging hyper converged designs from the likes of VMware / NSX (very, very cool technology btw).

Not just a buzz word .. definitely worth reading up on.
http://www.vmware.com/ca/products/hyper-converged-infrastructure.html

[Scott Dorsey]

Kerry Main <kemain...@gmail.com> wrote:
>IPS/IDS devices are NOT purchased by end users. These devices starting =
>price ranges are not for home or even small businesses i.e. $10-20K+. =
>These are high end security devices used in enterprise Data centres with =

>serious large scale security requirements.
>
>Firewalls purchased by end users are home/small business types.

Those are called firewalls but most of them aren't firewalls at all but just
fancy routers. If it's not stateful, it's not a firewall.

We have come to the point where anything even remotely security related is
called a "firewall" by the marketing people, even when it really has nothing
to do with firewalls.

[Stephen Hoffman]

On 2017-04-01 20:18:18 +0000, Kerry Main said:

> Users?

Yes, you know; the sorts of folks that some "enterprise software
developers" have a well-deserved reputation of dumping poorly-written
and variously cryptic documentation for?

That can be the sorts of folks that cannot locate the documentation
because they searched for the common term, as is this case. As
started this thread, BTW.

The sorts of folks that are better served by using common phrases in
the documentation. That's when the documentation remains necessary,
and the developers haven't reduced or eliminated chunks of the
documentation, because the developers have provided tools that just
work better.

> Perhaps that is the reason for this disagreement here.

If that's why you think we're disagreeing, no. We're apparently
disagreeing because I'm suggesting an opportunity to improve the
associated documentation. That when eliminating the documentation is
not feasible.

> IPS/IDS devices are NOT purchased by end users. These devices starting
> price ranges are not for home or even small businesses i.e. $10-20K+.

Just who is an end user of the documentation or the product varies, of
course. In this thread, it was an OpenVMS user seeking information
on an OpenVMS feature — one commonly referred to as a firewall, and was
unable to do so.

That price range is probably an order of magnitude high, BTW.

As for hardware solutions? Entry prices for very nice commercial
systems are under US$200. That includes embedded IDS, IPS and VPN
server features and capabilities — where many vendors are headed, of
course — subscription services for features and updates. Slightly
further up and still under US$1000, redundant high-availability
features, higher bandwidth, more VPNs, and other such. As I
mentioned earlier, I'm deploying these devices for even small sites and
single-user sites.

For those that need it, this trend is continuing, and fully-remote
configuration and provisioning are also available as well — the on-site
folks need to plug the device in, and the rest is remote. Established
policies and configuration settings, firmware upgrades and the rest
are all fetched and verified by the device. Automatically. This one
is a bit more expensive, at just under US$700.

All available. Now.

I'm rolling out managed switches for sites too, as the prices on those
are cratering as well. But I digress.

Again, my comments are that "firewall" is a commonly-accepted and
widely-used term, and — if y'all want to layer in a bunch of acronyms
for specific features — have at. But failure to reference a common
term in end-user documentation is a simple and easily-correctable error
in the documentation. Best to use acronyms in products and
documentation with some care, as folks just aren't reading
documentation the same way folks used to, too. The way many of us once
read the OpenVMS doc set from end-to-end.

Using "host-based volume shadowing" (HBVS) is a similarly poor idea, as
it utterly obfuscates one of the remaining and powerful differentiators
for OpenVMS, too. Users know this as mirroring or RAID-1. But I
digress.

As for writing and updating documentation, that's better written for
the actual end-users now and going forward, and to adopt clarity and
simplicity where possible, with reviews and end-user tests, and to use
the terms that end-user folks — such as the one that started off this
thread — expect. Documentation filled with cryptic acronyms and
arcane terms — and utterly lacking references to common terms — isn't
that. Not when it can be made simpler. Same for user interfaces,
too.

There are certainly examples where simplicity lacks in OpenVMS, whether
in the documentation or its structure or navigation, or in the user
interfaces, or even in some parts of OpenVMS itself. Migration to and
use of common terminology is likely one. Overhauling the existing
clustering configuration implementation is another. Updating that
quarter-century-old robust OpenVMS programming document mentioned
else-thread is certainly yet another. These among the many projects
on the VSI list for OpenVMS.

[Hans Bachner]

Stephen Hoffman schrieb am 02.04.2017 um 23:45:
> [...]

> That can be the sorts of folks that cannot locate the documentation
> because they searched for the common term, as is this case.

> [...]

The difference between technical documentation and marketing flyers
(imho) is, that the first uses technically correct terms, and the latter
tends to use common terms, regardless whether the accurately describe
what a product does.

Hans.

[Stephen Hoffman]

On 2017-04-03 20:09:34 +0000, Hans Bachner said:

> Stephen Hoffman schrieb am 02.04.2017 um 23:45:
>> That can be the sorts of folks that cannot locate the documentation
>> because they searched for the common term, as is this case.
>

> The difference between technical documentation and marketing flyers
> (imho) is, that the first uses technically correct terms, and the
> latter tends to use common terms, regardless whether the accurately
> describe what a product does.

Y'all can ignore documentation problems. Y'all can justify
documentation problems however y'all desire, too.

Y'all can also continue to believe that terminology is both universally
understood and used and that definitions and acronyms are forever
immutable, and that new users and new partners can and will search for,
expect and use the same terms as OpenVMS users with decades of
experience. That folks won't be trying to research and use the
platform, without reading through dozens of manuals and thousands of
pages of doc. If they're even willing to give such a product — which
clearly does not contain a firewall — a second look. Good luck with
that strategy for OpenVMS growth, if VSI tries that...

Common terms. Simple phrasing. Easier and simpler and less
management. Cookbooks and examples.

Because the market is NOT going back to the era when existing OpenVMS
users and developers first encountered OpenVMS. Ever.

At least some folks here seem to forgotten the troubles, confusion and
frustration that can and often does arise when learning some new
platform or technology, too.

[David Froble]

"Hard drive"

"Burn a CD"

The list is long. What we used to call things has been overtaken by general
terms, many of which are deplorable. The marketing people understand one thing,
sales, and will do whatever it takes to get them.

Do I deplore some of the terms? Yes, very much. But what does that matter. If
you want to sell, then you better say the right words. Well, not "right", but
what the consumer will most likely understand.

[Simon Clubley]

The technical documentation _is_ the marketing material when you
are the person who has been given the job of shortlisting several
products for closer evaluation.

If some of the large range of products you are looking at use the
obvious terms in the documentation and others do not, then you will
never know about the latter as you will still successfully come up
with a list of products for your shortlist.

It just won't include the products whose vendors decided to be
"clever" and use terminology which you didn't think to search for.

This is because you use the generic keywords when searching to home
in on possible products. You then look at the section of the product's
documentation mentioning the keywords so you can see if the detailed
list of features includes those you are looking for.

If the generic keywords are not in the documentation, then you
never get to find the product's documentation in the first place
but your manager is still happy with you because you still came up
with a shortlist of other products matching your requirements.

[ultr...@gmail.com]

yes hunter thats what I did with TCPware, I observed IP logs
daily and edited in the necessary packet filters. Worked great
even for my decnet over IP ports.

[Stephen Hoffman]

On 2017-04-11 21:37:00 +0000, ultr...@gmail.com said:

> I observed IP logs daily and edited in the necessary packet filters.
> Worked great even for my decnet over IP ports.

An approach that's utterly untenable in the current era, though.
Botnet brute-forcing means one or two tries from each of an unlimited
number of hosts. Distinguishing that behavior from a legitimate user
that botched a password? Many aspects of computing and security from
twenty or thirty years ago just don't work now, whether due to changes
user expectations, or due to the sorts of configurations and network
attacks that are commonplace.

[Arne Vajhøj]

I would think that 10000 IP's doing 1 login attempt would be
as visible as 1 IP doing 10000 login attempts.

I think the real problem is the amount if data. It would
require a small army of people to manually analyze all this
data and they may still miss something due to the gigantic
size of data being generated constantly.

There is a reason why SIEM systems was invented!

Arne

[Stephen Hoffman]

On 2017-04-12 23:54:18 +0000, Arne Vajh j said:

> I would think that 10000 IP's doing 1 login attempt would be as visible
> as 1 IP doing 10000 login attempts.

As visible? With some \ data reduction, sure. Harder to block,
though. This assuming the sites also have remote users logging into
those same accounts, and that those sites not wishing to lock those
users out, and that those users are occasionally flubbing passwords.
Hard to tell the user and bot cases apart. Possible, with more
knowledge about the originating user — pattern or client or source IP
matching or otherwise — as triggering OpenVMS-style evasions on too-few
failures will block legitimate users and have negligible effects on the
botnets.