To whom it may concern, Is there a way to look into telnet data part or udp packets and log or even filter that on some keysequences? I read in the documentation that telnet proxy only filters some telnet commands but not what the user types. This PlugProxy could also handle UDP and telnet trafic but seems like no use because it does only simply forward without doing anything? Can Anypy be used for this as I think telnet would need a no-blocking proxy and Anypy seems to block on read? Does Anypy handle UDP paquets, too? I hope anyone can help me here and sorry for my bad english! Sincerely Yours Clement Fillon
On Wed, 2008-08-06 at 15:04 +0200, Clement Fillon wrote:
To whom it may concern,
Is there a way to look into telnet data part or udp packets and log or even filter that on some keysequences? I read in the documentation that telnet proxy only filters some telnet commands but not what the user types. This PlugProxy could also handle UDP and telnet trafic but seems like no use because it does only simply forward without doing anything? Can Anypy be used for this as I think telnet would need a no-blocking proxy and Anypy seems to block on read? Does Anypy handle UDP paquets, too?
I hope anyone can help me here and sorry for my bad english!
What do you want to accomplish exactly? It is quiet complicated to filter out keystrokes, as there's usually a terminal emulator at the client, and escape sequences and the server state can change the meaning of a single character significatnly. To make things safe, you'd probably have to embed a complete terminal emulator into Zorp. As a sidenote, this is something similar that we do with our Shell Control Box product, but instead of doing online filtering, we save the complete telnet (and ssh) terminal traffic, and replay it later in an audit player on the auditor's computer. About your questions about anypy: Mag (m4gw4s@gmail.com), also subscribed to this list, has patches to add non-blocking AnyPy support And about UDP: in Zorp, proxies are independent of the transport protocol, so each proxy can be used to transfer both UDP and TCP traffic. You can even convert between the two. -- Bazsi
Dear Balazs Scheidler,
What do you want to accomplish exactly? I would be happy if I could just log plain data separated by telnet session into different files (perhaps also separated by client => server and server => client).
Searching data seems indeed complicated as when I look into Wireshark each keystroke is a separate paquet. Ideally I would like to check information so when a user sends for example "root" that the session just terminates. It does not need to be perfect because instead of root you could also send "r","o","o","s","del","t" but that does not matter much to me and changing server states or other special cases do not matter, too.
And about UDP: in Zorp, proxies are independent of the transport protocol, so each proxy can be used to transfer both UDP and TCP traffic. You can even convert between the two. Sounds very good! And how can I specify this conversion if I would want to do that? Do I need to set --enable-conntrack Enable connection tracking for UDP based protocols at compile-time or does it work without this switch too?
Sincerely Yours Clement Fillon
On Wed, 2008-08-06 at 19:16 +0200, Clement Fillon wrote:
Dear Balazs Scheidler,
What do you want to accomplish exactly? I would be happy if I could just log plain data separated by telnet session into different files (perhaps also separated by client => server and server => client).
Searching data seems indeed complicated as when I look into Wireshark each keystroke is a separate paquet. Ideally I would like to check information so when a user sends for example "root" that the session just terminates. It does not need to be perfect because instead of root you could also send "r","o","o","s","del","t" but that does not matter much to me and changing server states or other special cases do not matter, too.
To save the traffic to disk you could increase the log level to 9 which includes hexadecimal traffic dumps even in the telnet proxy, however this is not very disk-space and performance friendly, but you could use that. Our commercial offerings have something better, but I don't want to write about that on the open source lists. To terminate the connection based on byte sequences, this is not currently supported. So you'd have to come up with an implementation. The Linux kernel for instance has a textsearch implementation, that offers multiple algorithms to do stream based searching. (look for the text search API, in lib/ts_*.c in the linux kernel source tree).
And about UDP: in Zorp, proxies are independent of the transport protocol, so each proxy can be used to transfer both UDP and TCP traffic. You can even convert between the two. Sounds very good! And how can I specify this conversion if I would want to do that? Do I need to set --enable-conntrack Enable connection tracking for UDP based protocols at compile-time or does it work without this switch too?
This switch is not needed anymore currently unused. I've just commited a patch to remove it. There was some mailings on the 3.3 release of Zorp GPL, I'd recommend using that, there were some important changes in 3.3 regarding UDP support that makes it more reliable. -- Bazsi
Hi, On Wed, 2008-08-06 at 19:16 +0200, Clement Fillon wrote:
And about UDP: in Zorp, proxies are independent of the transport protocol, so each proxy can be used to transfer both UDP and TCP traffic. You can even convert between the two. Sounds very good! And how can I specify this conversion if I would want to do that?
The client side protocol: ------------------------- The transport protocol on the client side is specified by the Dispatcher attribute (in elder releases (3.1 or previous) Receiver handled UDP, while Listener handled TCP traffic). 3.3: Binding to an IP: Dispatcher(transparent=TRUE, bindto=DBSockAddr(protocol=ZD_PROTO_TCP, sa=SockAddrInet('127.0.0.1', 50300)), service="Fixme", rule_port="300", backlog=255) Bindiong to an interface: Dispatcher(transparent=TRUE, bindto=DBIface(protocol=ZD_PROTO_TCP, port=50300, iface="lo", ip="127.0.0.1"), service="a", rule_port="300") The 'protocol' attribute specifies the client side protocol. Use ZD_PROTO_UDP or ZD_PROTO_TCP. If you need both, use two dipatchers. Of course you need proper packet filter rules. 3.1: Use Receiver for UDP and Listener class for TCP traffic. The server side: ---------------- On the server side the connection is initiated by the Chainer, which's attribute specifies the server side protocol: Service(name="Fixme", router=TransparentRouter(), chainer=ConnectChainer(protocol=ZD_PROTO_TCP, timeout_connect=30000), max_instances=0, proxy_class=FixmeProxy) The chainer's 'protocol' attribute specifies the transport protocol. Use ZD_PROTO_UDP or ZD_PROTO_TCP to force a protocol or just keep the client side protocol by ZD_PROTO_AUTO (this is the default). Regards, Peter -- Höltzl Péter IT biztonsági tanácsadó holtzl.peter@balabit.hu +36 20 366 9667 BalaBit IT Security 1115 Budapest XI. Bártfai u. 54. Tel +36 1 371 0540 Fax +36 1 208 0875 Az üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll, a nyilvános közléstõl védett. Az üzenetet kizárólag a címzett, illetve az általa meghatalmazottak használhatjak fel. Ha Ön nem az üzenet címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse errõl az üzenet küldõjét és törölje az üzenetet, valamint annak összes csatolt mellékletét a rendszeréböl. Ha Ön nem az üzenet címzettje, abban az esetben tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie.
participants (3)
-
Balazs Scheidler
-
Clement Fillon
-
HÖLTZL Péter