Enforce ISO Message Validation Before Channel Establishment

[Hussain lala]

We have two applications running on the same server, receiving requests from a load balancer and forwarding them to the appropriate QServer for transaction processing. However, during security scans or health checks, the server appears to send dummy or malformed data directly to the application server ports.

From what we observe, jPOS creates a channel before validating the message, and if the incoming data is invalid (e.g., incorrect message length), it throws an exception but does not properly close the channel. As a result, when a valid request arrives, it sometimes attempts to use this stale or invalid channel, leading to timeouts.

Although we’ve already configured the QServer to accept requests only from authorized sources, we still encounter “Invalid Message Length” errors, and our maxSessions is set to 100.

What we would like to know is:

• Is there a way to validate incoming data or connections before a channel is fully established in jPOS?

• Can we configure jPOS to immediately reject or close channels created from invalid messages or untrusted sources, before they count against our session limit?

Thank you 

[chhil]

Last year you had opened a similar thread where you would need to add the allow deny IP address and use and listening on localhost. Have those recommendations been implemented along with the fix alejandro made ? 

https://github.com/jpos/jPOS/issues/602

-chhil

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jpos-users/71330089-b6ba-4896-bf07-e8de72496b10n%40googlegroups.com.

[Mark Salter]

Exclude this system from security scanning - or handle the scans by adding code to cope and filter;  The former suggestion is probably the way to go.  This sort of 'security' scanning on some devices may result in loss of service (HSMs for instance); so avoid it.
Can you share

setup, versions some evidence of the observed behavior so it can be replicated at all?

--

Mark

-------- Original Message --------

--

[Alejandro Revilla]

I recently wrote about this.

You may have some fun with the Zphi reference (ISO layer 8).

--

@apr

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/Yh4Wk2NpPX4wUmiceavK2fpZwGrGoOgfSIewmrQnFywLHqAEibAhOu1NMgMGb8vXFo49FeAZ8tkUICGAIZq2IjY08-HpaYPBHUYp87P9e60%3D%40pm.me.

[Hussain lala]

Dear  All,

Thank you for your response

chhil: Last year you had opened a similar thread where you would need to add the allow deny IP address and use and listening on localhost. Have those recommendations been implemented along with the fix alejandro made ?Yes those properties were added last year and we were able to successfully avoid the requests coming from outside the servers, however recently we saw that these requests were coming from the localhost i.e from the server itself and now when the request comes and since the originator is localhost it is accepted and then an exception is thrown.And any requests coming from actual source is denied until we restart the server. This is what we see in the logs

<log realm="EPI_SWITCH_CMS_SERVER_4051_CMS.server.session/127.0.0.1:20836" at="2025-05-01T15:45:42.554">
  <session-start>
    access granted, ip=127.0.0.1
  </session-start>
</log>

<log realm="EPI_SWITCH_CMS_SERVER_4051_CMS.server.session/127.0.0.1:20836" at="2025-05-01T15:45:42.554">
  <session-error>
    <iso-exception>
      Invalid message length 

      org.jpos.iso.ISOException: Invalid message length

at org.jpos.iso.channel.ASCIIChannel.getMessageLength(ASCIIChannel.java:118)
at org.jpos.iso.BaseChannel.receive(BaseChannel.java:714)
at org.jpos.iso.ISOServer$Session.run(ISOServer.java:344)
at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:76)
    </iso-exception>
  </session-error>
</log>

and then for any valid requests this error is coming 
    <iso-exception>
      Server has no active connections
      org.jpos.iso.ISOException: Server has no active connections
at org.jpos.q2.iso.QServer.notify(QServer.java:354)
at org.jpos.space.TSpace.notifyListeners(TSpace.java:313)
at org.jpos.space.TSpace.out(TSpace.java:85)
at org.jpos.q2.iso.QMUX.request(QMUX.java:143)
at com.duc.epi.episwitch.participant.SendRequest.doPrepare(SendRequest.java:71)
at org.jpos.transaction.TxnSupport.prepare(TxnSupport.java:44)
at org.jpos.transaction.TransactionManager.prepare(TransactionManager.java:585)
at org.jpos.transaction.TransactionManager.prepare(TransactionManager.java:651)
at org.jpos.transaction.TransactionManager.run(TransactionManager.java:323)
at java.lang.Thread.run(Unknown Source)
    </iso-exception>

is there any property that we can enable to see more logs to identify the source of theses invalid requests? 

[Mark Salter]

-------- Original Message --------

On 04/05/2025 08:23, Hussain lala wrote:
>
is there any property that we can enable to see more logs to identify the source of theses invalid requests? 

Do you control this server or not?

Run a network trace and perhaps report processes and ports in use locally to track whatever is running on your server 'attacking' the ports in question.
Details of the operating system may help guide what to use.

By the way, this is not a jpos problem. You should seek to either exclude your ports from these scans or speak to the team running your servers for their help.

--
Mark

[chhil]

Thanks for the response.

I would need to look into this further and if client and server behave differently.

I think an incorrect message length is part and parcel which should cause a similar issue irrespective of the senders intent, be it a scan or the length header being screwed up.

-chhil

--

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/GIUxWRuIu0PbgCYNPCyHkY2Sd7-XKNlLbOhlvELdB5Iztzv3r-R_EVFYAMSB4p9f4oP4Q8Y7WRYq2xNZCs1D-bcHQ7eae5RgL7gmiTdWqUE%3D%40pm.me.

[chhil]

Recovering from this is not easy.
TCP is a streaming protocol, broken up by MTU and collected. So you could have N messages with and without the correct length . Security scan sends a message and the length interpreted could be 10K, the server will wait for 10K bytes , or the length could be interpreted as 10 bytes and the next bytes 11 onwards would be considered a new message and it would be wrong and get the system out if sync till it's not restarted.

I would think your own testing security scan needs to understand such limitations and test accordingly.

-chhil

[Hussain lala]

Dear  chhil,

Is there a way to know how many channels are stale or corrupted or is there a way to reset the channel pool once we encounter ISOException.

[Alejandro Revilla]

Can you share your channel/server configuration?

--

@apr

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/461ee2e9-1248-4c27-b839-57eb356fa678n%40googlegroups.com.

[chhil]

What is your "ignore-iso-exceptions" property configured as?

https://github.com/jpos/jPOS/blob/main/jpos/src/main/java/org/jpos/q2/iso/ChannelAdaptor.java#L291C9-L291C28


If it is set to anything but "yes" the channel is disconnected on an ISOException.

https://github.com/jpos/jPOS/blob/main/jpos/src/main/java/org/jpos/q2/iso/ChannelAdaptor.java#L390-L399

-chhil

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3DkQMG4H0aMST6Z0EGntomOhxgttDFGU2%3D4Ac9X7MYs6QA%40mail.gmail.com.

[Hussain lala]

Dear All,

This is my QServer config file

<server class="org.jpos.q2.iso.QServer" logger="Q2" name="EPI_SWITCH_CMS_SERVER_4050_CMS">
   
 <attr name="port" type="java.lang.Integer">5959</attr>
 <property name="allow" value="127.0.0.1" />
 <property name="bind-address" value="localhost" />
 <attr name="maxSessions" type="java.lang.Integer">100</attr>
 <!-- Channel -->
 <channel class="org.jpos.iso.channel.ASCIIChannel" logger="Q2" packager="org.jpos.iso.packager.GenericPackager">
      <property name="packager-config" value="cfg/packager/iso93ascii.xml" />
        <property name="packager-realm" value="SWITCH_TO_CMS" />
 </channel>
 
 <!-- MUX -->
 <in>SWITCH_CMS_MUX_IN_4050_CMS</in>
 <out>SWITCH_CMS_MUX_OUT_4050_CMS</out>
 
</server>

Where should this ignore-iso-exception be configured?

[chhil]

> Where should this ignore-iso-exception be configured?

Write above the end server tag </server>.

-chhil

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/f8d4e807-61f1-41b1-8393-f0dc08987a01n%40googlegroups.com.

[Alejandro Revilla]

> Write above the end server tag </server>.

Just to clarify Hussain, you probably don’t want to ignore the ISO exceptions.

--

@apr

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CAPazefBA9ZsPW5zoJuTOaSNRfJJJgCB-ksB3SpxV_gY6U7ep3A%40mail.gmail.com.

[Hussain lala]

 Hi All,

> Write above the end server tag </server>. -- Adding ignore-iso-exception did not help? Is there any other way, for example to manually disconnect all the channels in a session and re-establish the session all together?

[Andrés Alcarraz]

That could be a workaround, but it would make all pending transactions fail.

If I were you, I'd just find the infractor trying to connect from localhost and stop the process for good.

----
Enviado desde mi móvil, disculpas por la brevedad.

Sent from my cellphone, I apologize for the brevity.

Andrés Alcarraz.

El dom, 11 may. 2025, 07:45, Hussain lala <hussai...@gmail.com> escribió:

 Hi All,

> Write above the end server tag </server>. -- Adding ignore-iso-exception did not help? Is there any other way, for example to manually disconnect all the channels in a session and re-establish the session all together?

--

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/d2834bb0-2557-410c-9c56-53b21b41c27an%40googlegroups.com.

[Islam Alnahrawy]

If in your setup you have one Channel connecting to QServer on port 5959 (with QServer using its default <send-request>LAST</…> behavior), setting maxSessions=1 I believe can be a simple fix. You get one session slot for your persistent, with keep-alive channel connection . Immediate “connection refused” on any extra TCP scan, so no extra resources are used or messages processed. For failover consideration, you may also need to configure a session timeout and enable automatic reconnect (reconnect-delay) on the channel

Regards,
Islam Alnahrawy

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/f8d4e807-61f1-41b1-8393-f0dc08987a01n%40googlegroups.com.

[Alejandro Revilla]

With a reasonable (small) timeout, this is probably the best solution for these non-sense scans.

--

@apr

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/CABsVbd9hdT6S_Yw3QJ_VoFmDXu2Q6WuKnxrUx5-Ju32Kd5iEpQ%40mail.gmail.com.

[Hussain lala]

Dear All,

If in your setup you have one Channel connecting to QServer on port 5959 (with QServer using its default <send-request>LAST</…> behavior), setting maxSessions=1 I believe can be a simple fix.

I checked the codebase and I think if we set the  <send-request> tag with  ALL instead of the default LAST, The Qserver will check for all ISO Channel and whichever is connected it will send the ISOMessage over that channel. Please let me know if my understanding is correct.

[Mark Salter]

Please check that the system you are replying to will be happy with responses arriving back on a different connection than the request was sent - it might matter to them.

For all other  (future) readers, the correct approach to this scanning issue is to opt out of the scan process which makes the attempts here to not have a random scan break things completely unnecessary!

-- 
Mark

-------- Original Message --------

--

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/601f21d3-5111-458b-8f98-cd7f332e860bn%40googlegroups.com.

[Alejandro Revilla]

Problem with the scan is that once connected, if you use ALL, QServer might think the scan client is a valid ISO endpoint and send the message to it, while the scanner is probably trying to figure out if you are running a WikiWikiWeb.

--

@apr

To view this discussion visit https://groups.google.com/d/msgid/jpos-users/42XKVTDWtxwyxKk77zchl8T7z_Br89OEh9u9kImc4jGuHVlVq9aXoqzWpl8WqbYDlyTMABU7ffxhX7DcfQR8aNJiIew0Zpbh1VIxxVwoGIM%3D%40pm.me.