Author |
Message
|
Ganford |
Posted: Wed Sep 02, 2020 4:33 am Post subject: |
|
|
Novice
Joined: 09 Aug 2011 Posts: 22
|
EddieA wrote: |
My guess is that Nessus is trying to determine exactly what is listening to that port, and is confused. It thinks MQSeries is SSL.
Cheers, |
Hi, does somebody maybe know how it really looks like between vulnerability scanner and IBM MQ? I am currently getting lot of errorx by generic scanner features on mq. Also many FDC files are always created. By asking IBM and checking option, I have not really ways to fix this behavior on MQ side.
Still I would be great for any other option. Currently I am asking architects to stop vulnerability scanner towards MQ or at least disable generic scan, but maybe there other way around.
The scanner is initiated also from local and over LB, so I am not able to distinguish it from other real production connections. |
|
Back to top |
|
|
Vitor |
Posted: Wed Sep 02, 2020 4:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Ganford wrote: |
I have not really ways to fix this behavior on MQ side. |
No, you don't. MQ thinks anything coming in on it's port is a connection attempt from another MQ component, and throws an FDC because it's not a valid MQ handshake.
Ganford wrote: |
Currently I am asking architects to stop vulnerability scanner towards MQ or at least disable generic scan |
That's the only effective way; to "white-list" the open MQ port in the scanner.
My own experience is similar, but I was blessed that queue manager errors and FDC files automatically raised a trouble ticket. One of my minions did something Javascript-ish to identify which tickets were the result of the port scan (originating IP address? Source connection name? Tarot cards?) and automatically reassign them to the security team for closure.
They stopped the scan about 2 weeks later. Turned out they'd been getting grief from the database people for years about the same problem, so there was happiness for all. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
PeterPotkay |
Posted: Wed Sep 02, 2020 4:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001 Posts: 7717
|
|
Back to top |
|
|
gbaddeley |
Posted: Wed Sep 02, 2020 4:48 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003 Posts: 2527 Location: Melbourne, Australia
|
AFAIK, MQ does not use OpenSSL libraries, it implements its own SSL / TLS protocol management code. It looks like your scanner attempts to initiate a SSL session on the MQ port, and the MQ Message Channel Agent does not like it. MQ works with SSL 3+ and TLS 1+ versions, it doesn't know anything about OpenSSL versions. _________________ Glenn |
|
Back to top |
|
|
PeterPotkay |
Posted: Wed Sep 02, 2020 5:51 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001 Posts: 7717
|
Glenn,
The openssl related question in this thread is from 2004
Ganford resurrected the 16 year old thread asking about scanners against MQ in general. We deal with it all the time, but not since took advantage of AMQ_NO_BAD_COMMS_DATA_FDCS. Now they can scan and we don't need to mop up any FDC files. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
|
Vitor |
Posted: Thu Sep 03, 2020 5:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
I find myself enlightened! _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
|
exerk |
Posted: Thu Sep 03, 2020 10:01 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Split off from the original 2004 post... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
|
hal |
Posted: Thu Nov 12, 2020 10:28 am Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005 Posts: 67 Location: New York City, New York
|
An important detail is missing from https://www.ibm.com/support/pages/apar/IT30348
Quote: |
This APAR adds the ability via
environment variable "AMQ_NO_BAD_COMMS_DATA_FDCS" to suppress
the generation of these diagnostic files when the initial
communications data flow is not recognised by IBM MQ. |
What value(s) of AMQ_NO_BAD_COMMS_DATA_FDCS will suppress FDC file generations? Any non-null string or 0 or 1, for example? I do not have access to invoke security scans, so please don't ask me to test...
Which of the following, if any, works?
export AMQ_NO_BAD_COMMS_DATA_FDCS=ANYTHING
export AMQ_NO_BAD_COMMS_DATA_FDCS=0
export AMQ_NO_BAD_COMMS_DATA_FDCS=1 |
|
Back to top |
|
|
hughson |
Posted: Thu Nov 12, 2020 2:05 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013 Posts: 1948 Location: Bay of Plenty, New Zealand
|
When I point my browser at a V9.1.3 queue manager, I get no FDC and error message AMQ9207E.
The text in error message AMQ9207E has this to say on the matter.
Code: |
AMQ9207E: The data received from host '::1' on channel '????' is not valid.
EXPLANATION:
Incorrect data format received from host '::1' over TCP/IP. It may be that an
unknown host is attempting to send data.
An FFST file might be generated containing the invalid data received. It will
not be generated if this is the beginning of a conversation with the remote
side, and the format is a simple known format (example: a GET request from an
HTTP web browser). If you want to override this, to cause FFST files to be
written for any bad data, including simple known formats, then set the
environment variable AMQ_BAD_COMMS_DATA_FDCS=TRUE and restart the queue
manager.
The channel name is '????'; in some cases it cannot be determined and so is
shown as '????'.
ACTION:
Tell the systems administrator. |
so perhaps:-
Code: |
export AMQ_NO_BAD_COMMS_DATA_FDCS=FALSE |
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
|
hal |
Posted: Thu Nov 12, 2020 2:46 pm Post subject: |
|
|
Acolyte
Joined: 07 Dec 2005 Posts: 67 Location: New York City, New York
|
Clear as mud.
So there are two environment variables?
1.) AMQ_BAD_COMMS_DATA_FDCS
2.) AMQ_NO_BAD_COMMS_DATA_FDCS |
|
Back to top |
|
|
PeterPotkay |
Posted: Thu Nov 12, 2020 3:28 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001 Posts: 7717
|
|
Back to top |
|
|
bruce2359 |
Posted: Tue Nov 24, 2020 6:50 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9442 Location: US: west coast, almost. Otherwise, enroute.
|
Inbound flows from unknown ip addresses should be BLOCKED at your firewall BEFORE they are presented to any listener. Inbound flows from known ip addresses should be MAPPED to the appropriate MQ channel with CHLAUTH records. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
|
PeterPotkay |
Posted: Wed Nov 25, 2020 4:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001 Posts: 7717
|
bruce2359 wrote: |
Inbound flows from unknown ip addresses should be BLOCKED at your firewall BEFORE they are presented to any listener. Inbound flows from known ip addresses should be MAPPED to the appropriate MQ channel with CHLAUTH records. |
The thread is about port scanners from known IP addresses. The port scanners are being run by your own security team looking for vulnerabilities. Asking to block them via the firewall is A.) going to go nowhere fast and B.) counter to the best interest of the company as a whole - what good is the security team's scanning if every app and platform eventually blocks them at the firewall.
Vulnerability scanning is not going away. Apps including MQ need to gracefully deal with it. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
|
tczielke |
Posted: Wed Nov 25, 2020 9:18 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
The internal vulnerability port scan. Somewhat similar to the Dwight Schrute fire drill. Security vulnerabilities are important, but you would hope people are also taking into consideration the false alert monitoring, production applications that can't handle a barrage of unexpected data on their ports, etc. that can happen when you run these type of things. _________________ Working with MQ since 2010. |
|
Back to top |
|
|
feliciello |
Posted: Mon Nov 30, 2020 11:35 am Post subject: |
|
|
Guest
|
tczielke wrote: |
The internal vulnerability port scan. Somewhat similar to the Dwight Schrute fire drill. Security vulnerabilities are important, but you would hope people are also taking into consideration the false alert monitoring, production applications that can't handle a barrage of unexpected data on their ports, etc. that can happen when you run these type of things. |
I agree. Security vulnerabilities are really important. |
|
Back to top |
|
|
|