For interest,
There's quite a good article on iptables here:
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables
I was musing on this last night. I'm still not sure about what Sree is
trying to achieve, but his mails seem to be focussing on what he wants
to allow out from a given host. I'm not sure the context and I'd agree
that the most obvious thing to do is to block everything except to 5672.
If he's particularly concerned about *outbound* connections one other
(probably over complex) option is to set up a local broker and block all
outbound connections, but enable inbound connections to 5672 and
federate that broker to the main broker. It's a bit of an odd approach
though as most people would want to prevent inbound connections to
client hosts.
It was only idle musing though.
I did wonder if it was possible to configure the client connection to
bind to a static (non-ephemeral) source port but I couldn't see any
obvious connection options for this, I guess that's not surprising as
it's a pretty unusual thing to want to do.
My view is still that the best approach would be to
1) Enable a firewall to block outbound traffic except to port 5672 and
(possibly only to the host running the broker)
2) Enable authentication so that only the clients he wants can connect
to that broker.
If he's feeling adventurous
3) Enable Access Control Lists to limit what those clients can do.
F.
On 31/01/13 21:15, Steve Huston wrote:
Usually in setting up firewall rules, you only need to specify the destination
port (the broker port) to allow the firewall to pass. The firewall usually
remembers the details of the TCP connection it allowed to open and allows the
traffic coming back from the broker on the same connection to pass as well.
Think of a web browser connection... the firewall needs to know to allow port
80 TCP data out, but how does it know to allow the data returned by the web
server to get to your browser? You don't need to program the firewall with your
browser's port number - it remembers the source port when your browser opens
the port 80 connection outward.
-Steve
-----Original Message-----
From: Fraser Adams [mailto:[email protected]]
Sent: Thursday, January 31, 2013 1:42 PM
To: [email protected]
Subject: Re: Amqp message sender port
I'm afraid that you've hit the limits of what I might be able to help with, as I
said before there *may* be a way of figuring out the port down-casting to a
qpid specific class, but I couldn't say for sure and couldn't tell you what
class
without going through the APIs.
However I'm still *really* baffled by what you are trying to achieve and I can't
get the London Taxi Driver joke out of my mind as in "I wouldn't start from
here".
When you say "allowing traffic from my machine to the other machines" it
sounds like you are talking about some sort of firewall configuration?
As//I said before the source port is ephemeral, so you'd have to end up
dynamically updating rules 'cause this information will change each time you
connect out.
I'm no expert, but thinking about it I'm not entirely sure that this strategy
has
legs at all. It's been a while since I looked at the nitty gritty, but aren't
ephemeral ports only allocated when the socket connects, so you wouldn't
actually know the source port until it has actually connected but you're trying
to block ports that you don't know?? I may be wrong but that rings a bell.
If you are wanting to only allow AMQP traffic from your system surely you
just need to enable dest port 5672 or if you really want to go to town put in a
packet filter that only allows AMQP.
I really can't get out of my mind that you're going about this the wrong way.
It's probably worth you thinking about what exactly it is that you are trying to
protect.
You could enable authentication on the broker so only your particular clients
can interact with the broker and you could enable Access Control Lists to
restrict what each client can do once connected.
I'm no expert on this but if you search the mailing list there's quite a bit of
stuff on this (Google Qpid, SASL ACL should give quite a bit to be getting on
with).
Frase
On 31/01/13 12:49, Sree C wrote:
Hi Fraser,
Thanks for the information provided.
I need the source port information for the purpose of allowing traffic
from my machine to the other machines.
So if i know the AMQP source port I can allow only the AMQP packets.
The netstat solution and the python scripts are of little help to me
since they give information after the packets leave the machine.
So for this purpose, if I can get this info from the qpid library,then
I can write rules for the traffic management.
Could you please suggest me any other alternative solution ?
Regards,
Sree.
Date: Sun, 27 Jan 2013 09:10:55 +0000
From: [email protected]
To: [email protected]
Subject: Re: Amqp message sender port
Hi Sree,
I'm still not *entirely" sure what you are trying to achieve.
So in your architecture as you've described it you have a single
producer, a broker and multiple consumers.
You say "To distinguish messages that are sent to different
machines, I need to know the Source Port number from which the AMQP
Message is sent " that confuses me a bit because you say you've got a
single producer?
So presumably all consumers would receive messages from that
producer (assuming they had the correct bindings in place).
I'm curious as to why you are interested in the source port on the
source host. That feels a bit weird at a fundamental level as the
source
port is an ephemeral port
http://en.wikipedia.org/wiki/Ephemeral_port
and so every time a Connection is made this port number will be
different, so it's hard to see how you'd use it to "distinguish
messages
that are sent to different machines ".
I may be mistaken, but it sounds like you are interested in using
some sort of information about the producer machine from the
perspective of the consumer machine, is that correct? Remember that
in an AMQP 0.10 topology you have the message broker in play and
producers and
consumers
are decoupled (with one producer and multiple consumers I suspect
that you are using a publish/subscribe model to the topic exchange,
this is sometimes known as "fire and forget" as the producer
generally doesn't know about consumers and vice-versa).
To pass information from a producer to a consumer in a MoM
architecture you'd (conceptually at least) design some form of
"application
protocol"
for passing information between endpoints (i.e. a protocol layered
on top of the Messaging Protocol). That all sounds very grand, but
in your case such a "protocol" can probably decompose into setting a
message header with a particular value in the producer that the
consumer can then retrieve and interpret. Although that's probably
how you'd implement it I'd recommend that you do think of it like a
protocol and design it with a well defined interface, because your
application will be a lot easier to maintain in the long run if you
do and your
producers
and consumers will know where they stand.
So passing arbitrary information from a producer to a consumer isn't
hard, but if you *really do need* to find the ephemeral port of the
underlying socket connection that is carrying the AMQP then that is
I believe pretty hard because as I said in my previous post the APIs
are deliberately designed to abstract that information (Qpid can
actually use multiple transports including tcp and rdma). As I said
earlier you
*might* be able to down-cast from the API classes to implementation
classes and find some way to navigate to the underlying socket
connection. It's probably possible but I'd assert that doing that
sort of thing is *evil hackery* and I really wouldn't recommend it.
I have to be honest, I think that you are going about this from the
wrong angle. My strong advice would be for you to take a deep breath
and
a step back and consider what you really want to achieve at an
architectural level. Going straight for an ephemeral port is almost
certainly an "implementation decision" and in most cases unless you
are doing some sort of network diagnostics unlikely to be what you
"really want". I'd think first about what information you really
want to pass between your producers and consumers at a logical level
first, if you decide that it really is the ephemeral port of the
AMQP socket
transport
then fair enough, but I'd love to know the justification for such a
choice.
If you *really* want to get at the ephemeral port after what I've
said above as I say I can't think of a really easy way through any
API and I'm not even sure how to hack the implementation classes to
get at it, but there may be mileage in a slightly more lateral
approach. I'm no expert, but running "netstat -an | grep 5672" on my
Linux box yields
tcp 0 0 0.0.0.0:5672 0.0.0.0:* LISTEN tcp 0 0 127.0.1.1:5672
127.0.0.1:43459 ESTABLISHED
tcp6 0 0 127.0.0.1:43459 127.0.1.1:5672 ESTABLISHED
Now running netstat from your application might be a pain, but I'd
assume that in Linux netstat gets its info from the /proc filesystem.
Looking at the results for cat /proc/net/tcp the results aren't as
easy to interpret as netstat but 5672 is 1628 in hex so I did "cat
/proc/net/tcp | grep 1628" and got:
3: 00000000:1628 00000000:0000 0A 00000000:00000000 00:00000000
00000000 1000 0 6199631 1 0000000000000000 300 0 0 2 -1
129: 0101007F:1628 0100007F:A9C3 01 00000000:00000000 00:00000000
00000000 1000 0 9622157 1 0000000000000000 20 4 0 10 -1
The first result is the listen on the wildcard address, but the
second is what you want 0101007F is clearly 127.0.1.1, 1628 is hex
for 5672, 0100007F is 127.0.0.1 and A9C3 is hex for 43459.
Clearly if you have multiple clients on the same host connecting to
5672
then the results will be a whole lot harder to interpret and
obviously you'd need to write something to read and parse
/proc/net/tcp
I really wouldn't recommend any of this and my previous comments on
thinking about what you're really trying to achieve stand, but if
you really want to hopefully some of this helps.
Regards,
Frase
On 27/01/13 04:18, [email protected] wrote:
Hi Frase
I am sending AMQP Messages from one machine to multiple machines.
To distinguish messages that are sent to different machines, I
need to know the Source Port number from which the AMQP Message
is sent from the sender machine (including all the amqp packets that
leave the sender machine).
I tried using the APIs in the qpid::sys::SystemInfo namespace,but
it gives the destination IP and Port information which is of little
help to me.
Is there any other way to get the Source Port number ?
I am using qpid 0-10 C++ api
The destination Port I use is always 5672.
Thanks
Sree.
<quote author='fadams'>
Hello,
what's the objective that you are trying to achieve?
Do you mean that you want a producer client to be able to work out
the source port the connection is using, or given a producer
client, a broker and a consumer client you want to figure out from
the
broker say
what the source port is on inbound connections?
I don't thing either scenario is necessarily trivial.
In the first scenario if you are in Qpid Client code you normally
use an
API such as qpid::messaging in C++ or JMS in Java to provide an
abstraction for creating a Connection, a Session etc.
In a Messaging system these abstractions tend to be pretty high
level, so for example with JMS I'm pretty certain that there's not
any way in the API to retrieve the underlying Socket or InetAddr.
You *might* be able to get to the Socket by down-casting to the
Qpid specific class that is implementing javax.jms.Connection and
digging around there (similar for qpid::messaging) but it's not
certain if this is even exposed on a public method on a private class.
If it's the second scenario then it's not trivial but it is
exposed, the
QMF connection ManagementObject exposes the host and port info
for
both
sides in the address property (the old 0.8 broker only exposed one
end but from 0.10 both sides are exposed).
The Qpid GUI that I recently posted info on exposes all of this
and it's
pretty easy to see most things one is likely to care about.
If you need to look at this in your own code you might want to
take a look at a posting I sent in reply to Lance D. on the topic
of "Instrumenting the Broker" (around the 11th of January). I
posted
him a
couple of python programs I'd written (connection-logger and
connection-audit) those illustrate how to get connection info
(plus a load else) out of the broker via QMF. The might well help
you get
up and
running.
HTH,
Frase
On 26/01/13 16:16, sys8284 wrote:
HI
How can i get the sender port number i.e .., the port from which
the AMQP
Message is sent from Source Computer
I know the destination port as 5672. But i need the origin port
number
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Amqp-message-sender-port-
tp7587517.h
tml
Sent from the Apache Qpid users mailing list archive at Nabble.com.
-----------------------------------------------------------------
---- To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
------------------------------------------------------------------
--- To unsubscribe, e-mail: [email protected] For
additional commands, e-mail: [email protected]
</quote>
Quoted from:
http://qpid.2158936.n2.nabble.com/Amqp-message-sender-port-
tp7587517p7
587519.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
