Re: Amqp message sender port

[Fraser Adams <fr...@blueyonder.co.uk>]

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:fraser.adams@blueyonder.co.uk]
>> Sent: Thursday, January 31, 2013 1:42 PM
>> To: users@qpid.apache.org
>> 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: fraser.adams@blueyonder.co.uk
>>>> To: sys8284@hotmail.com
>>>> 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, sys8284@hotmail.com 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: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>
>>>>> ------------------------------------------------------------------
>>>>> --- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
>>>>> additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>>
>>>>> </quote>
>>>>> Quoted from:
>>>>>
>>> http://qpid.2158936.n2.nabble.com/Amqp-message-sender-port-
>> tp7587517p7
>>> 587519.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org