Port redirection problems?

Hi

I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote
host, to tcp 19999 via udp:514 on a local syslog server.

I am using netcat to do the port redirection but when I use tcpdump to
sniff the packets, for some reason, on the remote host the port does
not seem to be redirecting. Why am I doing this? I want to encrypt the
channel (replacing netcat with cryptcat - the encrypted version of
netcat) to send syslog over an insecure medium. Remote sysloging is
already working in the clear between the 2 hosts over udp:514.

On the remote host I use:

nc -l -u -p 514 -vv | nc 192.168.1.5 [the syslog server] -p 19999
19999 -vv

This should mean listen on udp[514] and redirect over tcp [on source
port 19999]19999 to 192.168.1.5.


On the local syslog server I use:

nc -l -p 19999 | nc -u localhost 514

Which should mean listen on tcp[19999] and redirect to udp[514] on the
localhost.

Tcpdump indicates that netcat connection opens but then after the
initial connection setup, no traffic is going over the 19999 port.
Traffic continues to travel over udp[514]. If I block udp[514] on the
local syslog server firewall - it stops receiving logs. So it seems
that, on the remote host, netcat is not 'grabbing' the port.

Is there any way I can force this? To start the netcat redirection I
'ssh' to the remote server (after copying the netcat binaries over)
and running the above command from a shell. Is there any chance that
the remote syslog server will still have 'hold' of the udp[514]?

Any thoughts or help really welcome...

Kind regards
James

|I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote
|host, to tcp 19999 via udp:514 on a local syslog server.

I don't see how this would work right off. Does netcat can do the
conversion from UDP to TCP, as well as preserve information about packet
boundaries for the reverse conversion?

(E-Mail Removed) wrote in message news:<V6tOa.166$(E-Mail Removed)>...
> |I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote
> |host, to tcp 19999 via udp:514 on a local syslog server.
>
> I don't see how this would work right off. Does netcat can do the
> conversion from UDP to TCP, as well as preserve information about packet
> boundaries for the reverse conversion?

Yes it does...
http://www.atstake.com/research/tool...ork_utilities/

"Netcat has been dubbed the network swiss army knife. It is a simple
Unix utility which reads and writes data across network connections,
using TCP or UDP protocol. It is designed to be a reliable "back-end"
tool that can be used directly or easily driven by other programs and
scripts. At the same time, it is a feature-rich network debugging and
exploration tool, since it can create almost any kind of connection
you would need and has several interesting built-in capabilities.
Netcat is now part of the Red Hat Power Tools collection and comes
standard on SuSE Linux, Debian Linux, NetBSD and OpenBSD
distributions."

"Netcat 1.10
=========== /\_/\
/ 0 0 \
Netcat is a simple Unix utility which reads and writes data ====v====
across network connections, using TCP or UDP protocol. \ W /
It is designed to be a reliable "back-end" tool that can | |
_
be used directly or easily driven by other programs and / ___ \
/
scripts. At the same time, it is a feature-rich network / / \ \ |
debugging and exploration tool, since it can create
almost (((-----)))-'
any kind of connection you would need and has several /
interesting built-in capabilities. Netcat, or "nc" as the ( ___
actual program is named, should have been supplied long ago
\__.=|___E
as another one of those cryptic but standard Unix tools. /

In the simplest usage, "nc host port" creates a TCP connection to the
given
port on the given target host. Your standard input is then sent to
the host,
and anything that comes back across the connection is sent to your
standard
output. This continues indefinitely, until the network side of the
connection
shuts down. Note that this behavior is different from most other
applications
which shut everything down and exit after an end-of-file on the
standard input.

Netcat can also function as a server, by listening for inbound
connections
on arbitrary ports and then doing the same reading and writing. With
minor
limitations, netcat doesn't really care if it runs in "client" or
"server"
mode -- it still shovels data back and forth until there isn't any
more left.
In either mode, shutdown can be forced after a configurable time of
inactivity
on the network side....

and so on.."

(E-Mail Removed) wrote in message news:<vbyOa.492$(E-Mail Removed)>...
> |> |I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote
> |> |host, to tcp 19999 via udp:514 on a local syslog server.
> |>
> |> I don't see how this would work right off. Does netcat can do the
> |> conversion from UDP to TCP, as well as preserve information about packet
> |> boundaries for the reverse conversion?
> |
> |Yes it does...
> |http://www.atstake.com/research/tool...ork_utilities/
> |
> |"Netcat has been dubbed the network swiss army knife. It is a simple
> |Unix utility which reads and writes data across network connections,
> |using TCP or UDP protocol. It is designed to be a reliable "back-end"
>
> Yeah sure it can handle each protocol separately, I see nothing in there
> that suggests it will translate UDP to TCP and the reverse.
>
> Syslog messages are one per UDP message. Unless message boundaries are
> noted and preserved in the translation, the logger will not be able to
> find the beginning of messages in the stream.

Well according to this message on Security focus this contradicts what
you say... Netcat (or cryptcat) will redirect, or more correctly,
tunnel, udp through tcp...

http://www.securityfocus.com/infocus/1613

"One way to facilitate instant access to logs is tunneling. Some say
this is inelegant but it works. Using Netcat one can tunnel UDP over
Secure Shell by redirecting the syslog traffic to TCP tunnel,
protected by Secure Shell. The directions can be found at
http://www.patoche.org/LTT/security/00000118.html Make absolutely sure
that the syslog is not receiving messages from other hosts, or message
looping will occur.

In fact, by replacing Netcat with Cryptcat, one can eliminate SSH from
the equation. In this case the setup is as follows:

On log-generating host:

1. edit /etc/syslog.conf to have:

*.* @localhost

2. run command:

# nc -l -u -p 514 | cryptcat 10.2.1.1 9999

On log collecting host:

1. run syslog with remote reception (-r) flag (for Linux)
2. run command:

# cryptcat -l -p 9999 | nc -u localhost 514"

*******

and from

http://www.patoche.org/LTT/security/00000118.html

"Netcat will happily pipe UDP into a TCP stream. On the client
machine,
you would want to do something like:

nc -l -u -p syslog | nc localhost 9999

(as root, to bind to the syslog port)

On your syslog server end, you'd do something like:

nc -l -p 9999 | nc localhost -u syslog

Setup your ssh tunnel from port 9999 on the client machine to
port 9999 on the syslog server machine.

Setup syslogd on the client to log the messages to localhost. Also,
make sure that the client syslogd is set up to not receive messages
from the network.

You'll want to filter on the TCP listening port on the server to
prevent
people from DoS'ing you with spurious messages."

*******************

and perhaps this from the netcat readme will help...

"UDP connections are opened instead of TCP when -u is specified.
These aren't
really "connections" per se since UDP is a connectionless protocol,
although
netcat does internally use the "connected UDP socket" mechanism that
most
kernels support. Although netcat claims that an outgoing UDP
connection is
"open" immediately, no data is sent until something is read from
standard
input. Only thereafter is it possible to determine whether there
really is a
UDP server on the other end, and often you just can't tell. Most UDP
protocols
use timeouts and retries to do their thing and in many cases won't
bother
answering at all, so you should specify a timeout and hope for the
best. You
will get more out of UDP connections if standard input is fed from a
source
of data that looks like various kinds of server requests."

**********************************
**********************************

But we digress.... The real question is why netcat is not 'grabbing
the udp[514]' port on the server sending syslog messages to the remote
loggin server.

Could it be this? - again from the netcat readme?

"Netcat can bind to any local port, subject to privilege restrictions
and ports
that are already in use. It is also possible to use a specific local
network
source address if it is that of a network interface on your machine.
[Note:
this does not work correctly on all platforms.] Use "-p portarg" to
grab a
specific local port, and "-s ip-addr" or "-s name" to have that be
your source
IP address. This is often referred to as "anchoring the socket".
Root users
can grab any unused source port including the "reserved" ones less
than 1024.
Absence of -p will bind to whatever unused port the system gives you,
just like
any other normal client connection, unless you use -r [see below]."

However, I have tried to 1) stop syslog server, 2) start nc
redirection [udp[514] -> tcp [19999]], 3) restart syslog server but
the traffic still travels over udp[514].

So, debates over whether nc works or not (and as it has been for 7
years I doubt it would not be doing this...) aside, and in fact I
could (and will experiment with) udp[19999] through nc instead.

Can anyone helps me or are there any netcat experts out there?

Kind regards
James

fixx <(E-Mail Removed)> wrote in message news:<(E-Mail Removed) .za>...
> try installing datapipe from ports

Thanks fixx,

For me the issues is security - hence after proofing with netcat - I
would switch to cryptcat.

The other issues is I am limited in what I can install on the logging
host - it's a firewall (Ipcop/smoothwall) - which is a *very* tied
down linux distribution (I think based on OpenBSD). There is nothing,
most services disabled, no compiler - hence the ease of copying
accross the 'already compiled on linux' netcat or cryptcat.

This is why I have ruled out other options, namely,

1) SSH Tunneling - the firewall has ssh server but no client.
2) STunnel - an ssl tunnel, again - not enough to compile

Kind regards
James

>
> On Tue, 08 Jul 2003 07:16:20 +0200, James wrote:
>
> > Hi
> >
> > I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote host,
> > to tcp 19999 via udp:514 on a local syslog server.
> >
> > I am using netcat to do the port redirection but when I use tcpdump to
> > sniff the packets, for some reason, on the remote host the port does not
> > seem to be redirecting. Why am I doing this? I want to encrypt the
> > channel (replacing netcat with cryptcat - the encrypted version of
> > netcat) to send syslog over an insecure medium. Remote sysloging is
> > already working in the clear between the 2 hosts over udp:514.
> >
> > On the remote host I use:
> >
> > nc -l -u -p 514 -vv | nc 192.168.1.5 [the syslog server] -p 19999 19999
> > -vv
> >
> > This should mean listen on udp[514] and redirect over tcp [on source
> > port 19999]19999 to 192.168.1.5.
> >
> >
> > On the local syslog server I use:
> >
> > nc -l -p 19999 | nc -u localhost 514
> >
> > Which should mean listen on tcp[19999] and redirect to udp[514] on the
> > localhost.
> >
> > Tcpdump indicates that netcat connection opens but then after the
> > initial connection setup, no traffic is going over the 19999 port.
> > Traffic continues to travel over udp[514]. If I block udp[514] on the
> > local syslog server firewall - it stops receiving logs. So it seems
> > that, on the remote host, netcat is not 'grabbing' the port.
> >
> > Is there any way I can force this? To start the netcat redirection I
> > 'ssh' to the remote server (after copying the netcat binaries over) and
> > running the above command from a shell. Is there any chance that the
> > remote syslog server will still have 'hold' of the udp[514]?
> >
> > Any thoughts or help really welcome...
> >
> > Kind regards
> > James

I think I got my fix... it was entirely my fault...

In the syslog.conf file for remote loggin you set up under kern

*.* @192.168.1.5 [logging server]

But when you use nc to redirect - you need to just redirect the
'localhost' from udp[514] ->

so change the above line to

*.* @localhost

with the cryptcat redirection and bingo - all traffic goes over
tcp[19999].

This is not perfect as with the original remote logging scenerio you
would get the name of the client logging machine appearing in the
logs, now I just get the remote syslog server name [which comes in
under a redirected 'localhost']logging messages under it's name in the
logs not the actualy client logging. So it's really difficult to know
the difference between the two machines, remote or client... And this
will be compunded when I get many other servers logging to the syslog
server...

JT


fixx <(E-Mail Removed)> wrote in message news:<(E-Mail Removed) .za>...
> try installing datapipe from ports
>
> On Tue, 08 Jul 2003 07:16:20 +0200, James wrote:
>
> > Hi
> >
> > I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote host,
> > to tcp 19999 via udp:514 on a local syslog server.
> >
> > I am using netcat to do the port redirection but when I use tcpdump to
> > sniff the packets, for some reason, on the remote host the port does not
> > seem to be redirecting. Why am I doing this? I want to encrypt the
> > channel (replacing netcat with cryptcat - the encrypted version of
> > netcat) to send syslog over an insecure medium. Remote sysloging is
> > already working in the clear between the 2 hosts over udp:514.
> >
> > On the remote host I use:
> >
> > nc -l -u -p 514 -vv | nc 192.168.1.5 [the syslog server] -p 19999 19999
> > -vv
> >
> > This should mean listen on udp[514] and redirect over tcp [on source
> > port 19999]19999 to 192.168.1.5.
> >
> >
> > On the local syslog server I use:
> >
> > nc -l -p 19999 | nc -u localhost 514
> >
> > Which should mean listen on tcp[19999] and redirect to udp[514] on the
> > localhost.
> >
> > Tcpdump indicates that netcat connection opens but then after the
> > initial connection setup, no traffic is going over the 19999 port.
> > Traffic continues to travel over udp[514]. If I block udp[514] on the
> > local syslog server firewall - it stops receiving logs. So it seems
> > that, on the remote host, netcat is not 'grabbing' the port.
> >
> > Is there any way I can force this? To start the netcat redirection I
> > 'ssh' to the remote server (after copying the netcat binaries over) and
> > running the above command from a shell. Is there any chance that the
> > remote syslog server will still have 'hold' of the udp[514]?
> >
> > Any thoughts or help really welcome...
> >
> > Kind regards
> > James

|> Yeah sure it can handle each protocol separately, I see nothing in there
|> that suggests it will translate UDP to TCP and the reverse.

Ok fine so it bridges between TCP and UDP.

|> Syslog messages are one per UDP message. Unless message boundaries are
|> noted and preserved in the translation, the logger will not be able to
|> find the beginning of messages in the stream.
|
|Well according to this message on Security focus this contradicts what
|you say... Netcat (or cryptcat) will redirect, or more correctly,
|tunnel, udp through tcp...

No, it doesn't allay my second concern. Unless netcat is doing something
to delimit the boundaries of UDP blocks in the stream, they will be lost
going to TCP and then back to UDP. I can see how tunneling syslog might
work simplistically, a UDP block gets read, copied over to TCP, and then
at the other end output as a UDP block again. But what happens when two
UDP messages come in quick sucession. Will they get sent off in the same
TCP packet and then be coalesced into a single UDP packet at the other
end? Or perhaps a large UDP packet gets split between two TCP packets
and then turned into two UDP blocks at the other end. You'll probably
get away with it most of the time, but you risk losing the second
message in case 1 and losing the second half of a message in case 2.
--

James wrote:

> I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote
> host, to tcp 19999 via udp:514 on a local syslog server.
>

Why not use a Linux VPN, such as CIPE?

--

Fundamentalism is fundamentally wrong.

To reply to this message, replace everything to the left of "@" with
james.knott.

I have done something similar to this using xinetd that was quite easy.

> James wrote:
>
> > I'm trying to redirect udp:514 (syslog) via tcp 19999 on a remote
> > host, to tcp 19999 via udp:514 on a local syslog server.
> >
>
> Why not use a Linux VPN, such as CIPE?
>
>

In article <r3vPa.158$(E-Mail Removed)>
(E-Mail Removed) writes:
>|> Yeah sure it can handle each protocol separately, I see nothing in there
>|> that suggests it will translate UDP to TCP and the reverse.
>
>Ok fine so it bridges between TCP and UDP.

Actually it doesn't, if you look at the suggestions - they use two
netcat processes at each end, on the client there is one doing UDP ->
stdout piped to one doing stdin -> TCP, and vice versa at the server
end. Which of course guarantees not only that UDP packet boundaries are
*not* preserved, but that there is nothing netcat can do to preserve
them, since the "bridging" happens outside netcat (i.e. the pipe).

As an aside, having another process listen on UDP 514 and hoping to have
syslogd on the same host send it messages via a @localhost target is
iffy, since syslogd typically wants to bind its sending socket to port
514 (even if not listening). It can be done, but at least requires that
you have strict control over how the bindings happen (in which order and
which IP addresses are being used).

>|> Syslog messages are one per UDP message. Unless message boundaries are
>|> noted and preserved in the translation, the logger will not be able to
>|> find the beginning of messages in the stream.
>|
>|Well according to this message on Security focus this contradicts what
>|you say... Netcat (or cryptcat) will redirect, or more correctly,
>|tunnel, udp through tcp...
>
>No, it doesn't allay my second concern. Unless netcat is doing something
>to delimit the boundaries of UDP blocks in the stream, they will be lost
>going to TCP and then back to UDP. I can see how tunneling syslog might
>work simplistically, a UDP block gets read, copied over to TCP, and then
>at the other end output as a UDP block again. But what happens when two
>UDP messages come in quick sucession. Will they get sent off in the same
>TCP packet and then be coalesced into a single UDP packet at the other
>end? Or perhaps a large UDP packet gets split between two TCP packets
>and then turned into two UDP blocks at the other end. You'll probably
>get away with it most of the time, but you risk losing the second
>message in case 1 and losing the second half of a message in case 2.

I guess syslog packets are rarely "large", but certainly with a busy
syslogger they may be coalesced and then split at unrelated points at
the other end. The probable result of that (given the very simple nature
of the syslog protocol) is that you'd see unrelated messages (that
should perhaps have gone to another file) tagged onto "legitimate" ones
with a strange "<NN>" in between, and the tail-end of some of those
messages possibly lost or logged elsewhere (at least current FreeBSD
syslogd doesn't require the initial <prio>, but treats the message as
user.notice if it isn't there). In short, a mess.

It could possibly be made to mostly work by assuming that all syslog
messages are single-line and newline-terminated (which they probably are
after forwarding by the client-end syslogd), if the pipe-to-UDP netcat
at the server end took newline as packet separator. That's certainly not
the default according to the netcat "documentation", but there is a '-i'
option that might be used to that effect - though with the serious side
effect of limiting average message frequency to 1/second. It's not used
in the examples referred to in this thread as far as I can see, though.

--Per Hedeland
(E-Mail Removed)