New post

查找

Digest
· Dec 23, 2024

Publications des développeurs d'InterSystems, semaine Décembre 16 - 22, 2024, Résumé

#Developer Community Official #Digest
Articles
#Portail d'apprentissage
Annonces
#InterSystems IRIS
Publication de l'IPM 0.9.0
Par Sylvain Guilbaud
#Autre
#Communauté des développeurs officielle
Décembre 16 - 22, 2024Week at a GlanceInterSystems Developer Community
Question
· Dec 23, 2024

Interfaz sencilla para modificar y reenviar mensajes HL7

#Ensemble #HealthShare #Open Exchange

Hola a todos,

Estoy buscando alguna herramienta que se pueda utilizar como base para crear una interfaz que permita a un usuario no técnico reenviar mensajes de manera sencilla. La idea es que el usuario pueda encontrar un mensaje HL7 ya enviado y reenviarlo modificando campos específicos del mensaje sin necesidad de tener ningún conocimiento técnico.

Un ejemplo sería algo similar al buscador de Ensemble, pero con un enfoque menos técnico y mucho más intuitivo y que solo permita cambiar 1 o 2 campos. ¿Existe alguna solución en la comunidad o algo que pueda adaptar para este propósito? Algo tipo frontend en React que se comunique con backend IRIS para el reenvio. No encuentro nada y igual se ha de crear ya desde cero, pero por si acaso...

Gracias de antemano por vuestra ayuda.

2 Comments
Discussion (2)2
Log in or sign up to continue
Question
· Dec 23, 2024

Import error when using SOAP wizard with Gematik TI Connector WSDL Files

#SOAP #Health Connect

Hello Community,

I'm trying to import WSDL service descriptions from Gematik (https://www.gematik.de/) to allow communication with the german TI infrastructure using the TI connectors webservice interface over a IRIS healthconnect SOAP operation. For import I'm using the SOAP Wizard Add-Inn from Studio.

The WSDL files can be found here: https://fachportal.gematik.de/fileadmin/Fachportal/Downloadcenter/Schemata-_und_WSDL-Dateien/Schema-_und_WSDL-Dateien/OPB3.1_Schemadateien_R3.1.2_Kon_PTV3_20191002.zip

The interface specification and some helpful graphics are published here: https://gemspec.gematik.de/downloads/gemILF/gemILF_PS/gemILF_PS_V2.22.0.html

I exctracted the folder with the schema files to the filesystem of our Health Connect server and tried to import some services.

CardService and EventService worked as expected without any problems. With some configuration of the connectors endpoint it is possible to list all card terminals associated with the specific connector. When importing the VSDService, which allows to read health ensurance card data from card reader terminals, I got import errors. The file is located in conn/vsds/VSDService.wsdl relatively located to the root folder of the archive. The file could be loaded and parsed in the first place, but when trying to create class files an business operations I got an error

I thought it might be a rights problem and changed ownership of all files to the cacheusr (called irisuser in new installations), but this did not change anything.

I found this post in the developer community, but this one also does not seem to cover my case. The VSDService.wsdl is parsable and the error occurres at a later point while processing the contents. I had a similar error before with another file, when trying to import without providing the complete folder structure and contained files. In the current case all references exist and should be resolvable. Here is the WSDL File I'm trying to import:

<?xml version="1.0" encoding="UTF-8"?>
<!-- gematik revision="\main\rel_online\rel_ors1\1" -->
<!-- edited with XMLSpy v2010 (http://www.altova.com) by n.n. (gematik) -->
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:GERROR="http://ws.gematik.de/tel/error/v2.0" xmlns:VSD="http://ws.gematik.de/conn/vsds/VSDService/v5.2" name="VSD" targetNamespace="http://ws.gematik.de/conn/vsds/VSDService/v5.2">
	<documentation>
		Copyright (c) 2011, gematik - Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH. Alle Rechte vorbehalten.
		Beschreibung: Dienste zum Lesen der Versichertenstammten von einer eGK
	</documentation>
	<types>
		<xs:schema>
			<xs:import schemaLocation="VSDService.xsd" namespace="http://ws.gematik.de/conn/vsds/VSDService/v5.2"/>
			<xs:import schemaLocation="../../tel/error/TelematikError.xsd" namespace="http://ws.gematik.de/tel/error/v2.0"/>
		</xs:schema>
	</types>
	<message name="ReadVSDRequestMessage">
		<part name="parameter" element="VSD:ReadVSD"/>
	</message>
	<message name="ReadVSDResponseMessage">
		<part name="parameter" element="VSD:ReadVSDResponse"/>
	</message>
	<message name="FaultMessage">
		<part name="parameter" element="GERROR:Error"/>
	</message>
	<portType name="VSDServicePortType">
		<operation name="ReadVSD">
			<input message="VSD:ReadVSDRequestMessage"/>
			<output message="VSD:ReadVSDResponseMessage"/>
			<fault name="FaultMessage" message="VSD:FaultMessage"/>
		</operation>
	</portType>
	<binding name="VSDServiceBinding" type="VSD:VSDServicePortType">
		<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
		<operation name="ReadVSD">
			<soap:operation soapAction="http://ws.gematik.de/conn/vsds/VSDService/v6.0#ReadVSD"/>
			<input>
				<soap:body use="literal"/>
			</input>
			<output>
				<soap:body use="literal"/>
			</output>
			<fault name="FaultMessage">
				<soap:fault name="FaultMessage" use="literal"/>
			</fault>
		</operation>
	</binding>
	<service name="VSDService">
		<port name="VSDServicePort" binding="VSD:VSDServiceBinding">
			<soap:address location="http://unspecified"/>
		</port>
	</service>
</definitions>

I would really appreciate, if anyone would help me out with some ideas how to fix this error.

Kind regards,

Martin

5 Comments
Discussion (5)1
Log in or sign up to continue
Digest
· Dec 23, 2024

Nuevas publicaciones en la Comunidad de InterSystems, 16-22 diciembre

#Developer Community Official #Digest
Artículos
Anuncios
Preguntas
#Caché
Versión Evaluación de Cache II
Por Bernabé Martín
Obtener Studio
Por Bernabé Martín
16-22 diciembreWeek at a GlanceInterSystems Developer Community
Article
· Dec 23, 2024 6m read

从TTL值发现网络中的中间人攻击

#Tips & Tricks #InterSystems IRIS

技术支持团队在不同的项目中发现了类似中间人攻击的情况， 和各位分享一下。

我们的系统一般是安装在内网里，没有恶意的中间人攻击的风险。但是在有些医院发现了这样的情况：IT在网络中安装了某种网络监控或者嗅探的设备， 它会在通信通道中模拟其中一方，或者双方的通信节点， 以截获通信双方的网络流量。通常它不影响双方的通信，但偶尔，它会中断双方的连接， 造成业务的中断。实质上这也是一种中间人攻击的情况，只不过这是用户允许的行为，偶然出现了故障。 

 

我们看看以下的例子:

以下的wireshark抓包截图中， 172.18.1.131和172.18.1.145在正常的通信过程中， 忽然收到了RST消息，造成了TCP连接上的复位。

 

其中172.18.1.131是intersystems的health connect系统， 它在序号50134的包里面首先发送了RST，因此客户怀疑是不是Health Connect出错，中断了连接，也就把问题提交了InterSystems的技术支持。

我们的技术支持检查了各种内部日志，没有发现任何错误，咨询了InterSystems的网络专家，才发现这是个网络层的错误，也就是说： 这个RST不是Health Connect发送的， 同样， 序号50135的RST消息， 也不一定是172.18.1.145发送的，这是中间网络层的行为。  经过客户的证实，发现客户在网络层安装的监控工具， 不知道什么原因，触动了某种安全机制，它模拟两个系统，分别向对方各发送了一个RST消息。 

我们的技术人员之所以发现了疑似中间人攻击的情况， 是基于仔细研究了RST消息中的TTL值。 

IP 数据包中的 TTL(Time To Live)是什么：

当 IP 数据包在网络中传输时，TTL 用于防止数据包在网络中无限循环转发。 发送方在创建 IP 数据包时设置一个初始 TTL 值，通常为 64、128 或 255 等。每经过一个路由器，TTL 值就会减 1。当 TTL 减为 0 时，路由器会丢弃该数据包，并向源地址发送一个 ICMP（Internet Control Message Protocol）超时消息。TTL确保网络中的数据包不会无限制地循环，避免网络拥塞。同时，TTL 也可以帮助网络管理员诊断网络问题，例如通过观察 TTL 值的变化来确定数据包经过的路由路径。可以通过 IP 数据包中的 TTL 值来大致判断路由信息，但这种方法并不十分精确，只能提供一些有限的线索。

为了理解上面一段话的意思，我们向不同的目的地发ping包观察一下TTL值:

hma@CNMBP23HMA ~ % ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.132 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.162 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.151 ms
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.132/0.148/0.162/0.012 ms
hma@CNMBP23HMA ~ % ping bjsvmse01
PING bjsvmse01.iscinternal.com (172.19.85.68): 56 data bytes
64 bytes from 172.19.85.68: icmp_seq=0 ttl=64 time=10.388 ms
64 bytes from 172.19.85.68: icmp_seq=1 ttl=64 time=6.013 ms
64 bytes from 172.19.85.68: icmp_seq=2 ttl=64 time=4.614 ms
^C
--- bjsvmse01.iscinternal.com ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.941/5.778/10.388/2.050 ms
hma@CNMBP23HMA ~ % ping www.baidu.com
PING www.a.shifen.com (110.242.68.4): 56 data bytes
64 bytes from 110.242.68.4: icmp_seq=0 ttl=52 time=14.167 ms
64 bytes from 110.242.68.4: icmp_seq=1 ttl=52 time=12.411 ms
64 bytes from 110.242.68.4: icmp_seq=2 ttl=52 time=12.560 ms
^C
--- www.a.shifen.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.411/13.046/14.167/0.795 ms
hma@CNMBP23HMA ~ % ping www.intersystems.com
PING e9933.b.akamaiedge.net (104.124.163.63): 56 data bytes
64 bytes from 104.124.163.63: icmp_seq=0 ttl=42 time=173.183 ms
64 bytes from 104.124.163.63: icmp_seq=1 ttl=42 time=170.947 ms
64 bytes from 104.124.163.63: icmp_seq=2 ttl=42 time=169.031 ms
64 bytes from 104.124.163.63: icmp_seq=3 ttl=42 time=171.195 ms
64 bytes from 104.124.163.63: icmp_seq=4 ttl=42 time=168.908 ms
64 bytes from 104.124.163.63: icmp_seq=5 ttl=42 time=169.736 ms

上面我分别发送ICMP到4个地址：127.0.0.1，bjsvmse01, www.baidu.com, www.intersystems.com, 从对端响应消息中显示的TTL值分别是64, 64, 52, 42。

 

TTL=64是Linux系统的TTL初始值。 在linux系统ping 127.0.0.1时返回的当然就是64。 第二个服务器bjsvmse01返回TTL也是64, 说明它和我的本机在同一个网络，他们中间没有路由器的转接。

第3个第4个ping返回的消息中的TTL分别是52和42, 理解为：从Baidu.com的服务器到我的本机，经过了64-52=12个路由，而从intersystems.com到我的本机经过了64-42=22个路由。因为intersystems.com的服务器在国外，经过更多路由。从ping的结果看， 响应时间也更长，平均响应要100多ms。

有了TTL的知识，我们来看看前面医院里的RST是怎么回事。 

首先是RST的包， 可以看到TTL是128。 这就不对了。 128是Windows系统的TTL初始值， 而我们技术人员已经知道了， Health Connect是安装在一个Linux系统上，如果是Health Connect发出的RST，TTL应该是低于64的. 

 

我们去和一个正常工作的从这个服务器发出的TCP消息来比较，比如上面的HTTP消息，下面的截中可以看到TTL是64， 这是对的。本来这两个服务器就在一个网络里。

 

因此， 结论就是： 抓包中显示为从Health Connect 172.1.18.131发出的RST消息，因为TTL不对， 应该不是真的从Health Connect服务器发出的。 类似的情况出现在不同的客户的不同医院环境， 所以我们认为维护或者支持任何可能应该了解一下这个情况。 如果遇到，请及时和医院的IT工程师了解情况。 

 

有关TCP消息中的TTL值， 再补充几点：

  • 如果源和目的服务器不在一个网络，TTL值不是64和128，也可以用来判断是否是真实的服务器发送的消息。我们有个支持的工单里， 发现了正常工作的TTL是62，而发送了一个错误的TCP消息，TTL是57， 这也是可疑且需要网络工程师确认的。
  • 上面的例子中，从Health Connect对端，也就是172.18.1.145也发出了一个无法理解的RST消息。一个TCP端，收到一个RST消息后，不需要也不应该再回复，所以这个RST和上面Health Connect发出的RST没有关系。检查这个RST, 它的TTL值是128， 而正常通信时从这个服务器发出的消息也是128， 显然这是个Windows系统，所以这样的情况下， 只通过TTL是无法判断消息来源的身份真假的。除非在不同的地方，比如在中间的交换机上和该服务器上分别抓包比较，才可以得到线索。 
  • 网络路径中的某些设备（如防火墙、代理服务器等）对数据包进行了特殊处理。这些设备可能会修改数据包的 TTL 值，以确保数据包能够在网络中存活足够长的时间到达目的地. 典型的是当ping 8.8.8.8，也就 是 Google 的公共 DNS 服务器的时候，收到的TTL可能是不同的值，下面的截图中TTL是111， 如果您也测试一下， 您可能发现这个值是150， 170等等， 这时不只是源服务器的操作系统，LINUX/UNIX/Windows的初始值起作用，而是在中间网络设备将这个值做过特殊处理。
hma@CNMBP23HMA ~ % ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=111 time=50.109 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=111 time=45.896 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 45.896/48.002/50.109/2.107 ms
hma@CNMBP23HMA ~ %

 

因此，关于TTL值的局限性， 有这样的说法：

  • 准确性有限：
    • 由于网络中的路由可能会动态变化，TTL 值推断出的路由信息可能并不完全准确。
    • 一些网络设备可能会对 TTL 值进行修改或干扰，导致推断结果不准确。
  • 不完整性：
    • 对于一些复杂的网络环境，如使用 VPN（Virtual Private Network）、代理服务器或网络地址转换（NAT）的情况，TTL 值可能无法准确反映真实的路由路径。
Discussion (0)1
Log in or sign up to continue