ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » Port Scanner

Post new topic  Reply to topic
 Port Scanner « View previous topic :: View next topic » 
Author Message
Ganford
PostPosted: Wed Sep 02, 2020 4:33 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Sep 02, 2020 4:48 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Wed Sep 02, 2020 4:13 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

You want to use AMQ_NO_BAD_COMMS_DATA_FDCS.
It keeps MQ from generating FDCs when scanners hit it.

https://www.ibm.com/support/pages/apar/IT30348
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Wed Sep 02, 2020 4:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Wed Sep 02, 2020 5:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Sep 03, 2020 5:00 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

PeterPotkay wrote:
You want to use AMQ_NO_BAD_COMMS_DATA_FDCS.
It keeps MQ from generating FDCs when scanners hit it.

https://www.ibm.com/support/pages/apar/IT30348


I find myself enlightened!
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
exerk
PostPosted: Thu Sep 03, 2020 10:01 am    Post subject: Reply with quote

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
View user's profile Send private message
hal
PostPosted: Thu Nov 12, 2020 10:28 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
hughson
PostPosted: Thu Nov 12, 2020 2:05 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
hal
PostPosted: Thu Nov 12, 2020 2:46 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Thu Nov 12, 2020 3:28 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

We went with
Code:
export AMQ_NO_BAD_COMMS_DATA_FDCS=1

Seems to be working OK for us.


There is an RFE to move control of this behavior into qm.ini
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=141847
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Nov 24, 2020 6:50 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Wed Nov 25, 2020 4:44 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Wed Nov 25, 2020 9:18 am    Post subject: Reply with quote

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
View user's profile Send private message
feliciello
PostPosted: Mon Nov 30, 2020 11:35 am    Post subject: Reply with quote

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
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General Discussion » Port Scanner
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.