What i have:
I am running a freeradius server fully configured of how i need it to be. Everything works just fine right now.
What i need:
I need the radius to put the devices in a seperate vlan before authentication and to run a vulnerability scan (nessus / openvas etc) on the devices in this vlan to check for software status ( antivirus etc. )
if the device passes the test the authentication should be done normaly.
if it fails it should be put into a third ( fourth if you count the unauth-vid ) vlan.
can someone tell me if this is doable in freeradius ?
thanks in advance for your answers
Yes. But this is a very broad question and is dependent on the networking equipment being used. I'll give you an overview of how I'd design such a system.
In general, you'll have an easier time if you can use the same DHCP server/IP range for your NAC and full access VLAN. That means you don't have to signal the higher networking layers in the client that there's been a state change, you can swap out VLANs behind the scenes to change what they can access.
You'd set up a database with an entry for each client. This doesn't have to be pre-populated, it could be populated during the first auth attempt. Part of each client entry would be a status field detailing when they last completed NAC.
You'd also need an accounting database, to store information about where each client is connected to the network.
If the client had never completed NAC checks before, you'd assign the client to the NAC VLAN, and signal your NAC processes to start interrogating it.
FreeRADIUS can act as both a RADIUS and DHCPv4 server, so you'd probably do signal the NAC process from the DHCPv4 side because then you'd know what IP the client received.
Binding the RADIUS and DHCPv4 sides can be done in a couple of ways. The most obvious is MAC, another common way is NAS/Port ID using the accounting table.
Once the NAC checks had completed, you'd have the NAC process write out a receipt in detail file format, and have that read back in by a detail file listener (there are examples of this in sites-available/ in the 'decoupled-accounting' virtual server files). When reading those entries back in, you'd change the state in the database, and send a CoA packet to the switch using information from the accounting database to identify the client. This would flip the VLAN and allow them to the standard set of networking resources.
I know this is very high level, documenting it properly would probably exceed StackOverflow's character limit. If you need more help with this, I suggest you research what I've described above and then start asking the RADIUS related questions on the FreeRADIUS user's mailing list https://freeradius.org/support/.
Ok, I want to check if I can run some OS or MQSC commands in MQ server remotely. As long as I know, this could be done with SYSTEM.ADMIN.SVRCONN. In order to do that, I add a remote Queue Manager to my WebSphere MQ client. I put Queue Manager name on the server with proper IP, but when I use SYSTEM.ADMIN.SVRCONN as channel name, I have got: Channel name not recognized (AMQ4871) error.
Also, if I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER, can I run some commands (MQSC or OS) through this channel on the server?
Thanks.
Edit1
I am using WebSphere MQ v.7.0
By "I add a remote Queue Manager to my WebSphere MQ client" I meant I added a remote queue manager to MQ Explorer.
Edit2
I want to explain my question more precisely in this edit. I want to connect to a remote Qmanager via MQ Explorer. I know Qmanager name and its IP ofcourse. Also, the remote Qmanager has both SYSTEM.ADMIN.SVRCONN and SYSTEM.AUTO.SVRCONN channel available. When I check CHLAUTH for these channels, I've got:
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
6 : dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN)
MCAUSER( )
As you can see here, I should be able to connect via these two channels and run some commands. But when I choose SYSTEM.ADMIN.SVRCONN as channel name in remote configuration I get : Channel name not recognized (AMQ4871) and when I choose SYSTEM.AUTO.SVRCONN as channel name, I get: You are not authorized to perform this operation (AMQ4036).
Any idea?
when I use SYSTEM.ADMIN.SVRCONN as channel name, I have got: Channel
name not recognized (AMQ4871) error.
Did you define the channel on the remote queue manager?
if I have a channel name like MY.CHANNEL.NAME and it is a
server-connection channel with mqm as its MCAUSER, can I run some
commands (MQSC or OS) through this channel on the server?
Sure. And so can anyone else. You should read up on MQ security and not expose your queue manager to hackers.
I add a remote Queue Manager to my WebSphere MQ client.
I'm not at all sure what this means exactly. MQ Explorer keeps a list of queue manager definitions. MQ Client is just a library for making connections.
If you meant you added a remote queue manager to MQ Explorer, then it makes sense. In addition to defining the connection in Explorer, you will also have to provision the connection at the queue manager. This means defining the SYSTEM.ADMIN.SVRCONN channel or one with a name of your choosing, defining and starting a listener. If you are on a 7.1 or higher queue manager (it's always good to list versions when asking about MQ), then you will also need to create a CHLAUTH rule to allow the connection, and another CHLAUTH rule to allow the connection with administrative privileges. either that or disable CHLAUTH rules altogether, but this is not recommended.
If I have a channel name like MY.CHANNEL.NAME and it is a server-connection channel with mqm as its MCAUSER, can I run some commands (MQSC or OS) through this channel on the server?
Maybe.
Out of the box, MQ denies all client connections. There are CHLAUTH rules to deny administrative connections, and other CHLAUTH rules to deny connections for any SYSTEM.* channel other than SYSTEM.ADMIN.SVRCONN. Since admin connections are denied, non-admin users must have access provisioned using SET AUTHREC or setmqaut commands before they can use SYSTEM.ADMIN.SVRCONN, hence MQ is said to be "secure by default."
When you create MY.CHANNEL.NAME and connect as an admin, and if CHLAUTH is enabled, the connection will be denied. You would have to add a new CHLAUTH rule such as...
SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD)
...in order to allow the admin connection.
(Note: MQ CHLAUTH blocking rules use a blacklist methodology. The default rule blocks *MQADMIN from all channels. The rule I listed above overrides the default rule because the channel name is more specific, and it blocks *NOBODY - which is a list of user IDs that does not include mqm or any other administrative user ID. It's weird, but that's how it works.)
More on this topic at http://t-rob.net/links, and in particular Morag's conference presentation on CHLAUTH rules is a must-read.
20150506 Update
Response to edits #1 & #2 in the original question is as follows:
The first edit says that the QMgr is at v7.0 and the second shows that the QMgr had CHLAUTH records defined. Since CHLAUTH wasn't available until v7.1, these two statements are mutually exclusive - they cannot both be true. When providing the version of the MQ server or client, best to paste in the output of dspmqver. If the question pertains to GSKit, Java code or other components beyond the base code, then dspmqver -a would be even better.
The MQSC output provided in the question updates completely explains the errors.
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
As Morag notes, the SYSTEM.ADMIN.SVRCONN cannot be used because it has not been defined.
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
The auths error happens because any connection to any SYSTEM.* SVRCONN channel that is not expressly overridden is blocked by this rule. The CHLAUTH rule for SYSTEM.ADMIN.SVRCONN takes precedence because it is more explicit, and allows non-admin connections to that channel. The lack of a similar overriding rule for SYSTEM.AUTO.SVRCONN means it is denied by the existing rule for SYSTEM.* channels as listed above.
As noted previously, it is STRONGLY recommended to go to the linked web site and read Morag's conference presentation on MQ v7.1 security and CHLAUTH rules. It explains how the CHLAUTH rules are applied, how the precedence works, and perhaps most importantly, how to verify them with the MATCH(RUNCHECK) parameter.
To do the MQ Security right, you need at least the following:
Define a channel with a name that does not begin with SYSTEM.* and set MCAUSER('*NOBODY').
Define a CHLAUTH rule to allow connections to that channel, mapping the MCAUSER as required.
If you wish to connect to the channel with mqm or admin access, define CHLAUTH rules to authenticate the channel, preferably using TLS and certificates.
There are several things that you do not want to do, for reasons that are explained in Morag's and my presentations. These include...
Using SYSTEM.AUTO.SVRCONN for any legitimate connections.
For that matter, using SYSTEM.* anything (except for SYSTEM.ADMIN.SVRCONN or SYSTEM.BROKER.*) for legitimate connections.
Allowing unauthenticated admin connections.
Disabling CHLAUTH rules.
Disabling OAM.
I want people to learn MQ security, and to learn it really well. However, as a consultant who specializes in it I must tell you that even customers who have hired me to give on-site classes and help with their implementation have trouble getting it locked down. There are two insights to be gleaned from this fact.
First, if you do not enough time to get up to speed on MQ security then the implementation will not be secure. To study the topic to the point of understanding how all the pieces fit together well enough to devise a decent security model requires hands-on training with a QMgr that you can build, hammer at, tear down, build again, etc. takes weeks of dedicated hands-on study, or months or years of casual study. My advice here is to go get MQ Advanced for Developers. It is fully functional, free, and has a superset of the controls you have on the v7.1 or v7.5 QMgr you are working on now.
Second insight is that there is no shortcut to learning MQ (or any other IT) security. If it is approached as though it were simply a matter of configuration, then it is almost guaranteed to not be secure when implemented. If it is approached as learning all the different controls available for authentication, authorization, and policy enforcement, and then learning how they all interact, and if security is approached as a discipline of practice, then it is possible to achieve some meaningful security.
Addressing that second issue will require an investment in education. Read through the presentations and try out the various controls live on a test QMgr that you administer. Understand which errors go to which error logs, which generate event messages and which type of events are generated. Obtain some of the diagnostic tools in the SupportPacs, such as MS0P which is one of my favorites, and get familiar with them. Consider attending the MQ Tech Conference (where you can meet many of the folks responding here on SO) for more in-depth training.
If you (or your employer) are not ready to commit to in-depth skill building or are trying to learn this for an imminent project deadline, then consider hiring deep MQ Security skills on an as-needed basis because reliance on just-in-time on-the-job training for this topic is a recipe for an unsecure network.
I am writing a build script which has some password protected files (keys). I need a way to prompt the user once for the password and then use this key across multiple scripts. These scripts do not live inside the same shell, and may spawn other windows via dbus. I can then send them commands, one of which must have access to the password.
I have this working already, but at a few points the passphrase is either used directly on a command-line (passed via dbus), or is put into a file (the name then passed to the other script). Both of these are less secure than I want*. The command-line ends up in a history which may be stored in a file, as well as appearing in the process list, and the second option stores in a file which can be read by somebody else.
Is there some standard way to create a temporary communications channel between two processes which could communicate the password and not be intercepted by another user on the system (including root)?
*Note: This is primarily an exercise to be fully secure. For my current project the temporary in-file storage of the password is okay.
Setting "root being all-powerful" aside, I would imagine that a Private DBus Connection would do the trick although the documentation I could find seems a little light on what exactly makes a private connection private.
However, the DBus Specification, more specifically, the Message Bus Specification subsection on eavesdropping says in part:
Receiving a unicast message whose DESTINATION indicates a different
recipient is called eavesdropping. On a message bus which acts as a
security boundary (like the standard system bus), the security policy
should usually prevent eavesdropping, since unicast messages are
normally kept private and may contain security-sensitive information.
So you may not even need to use private connections which incur more overhead costs. But on a risk/reward basis with security being paramount, that may be the more secure alternative for you. Hope that helps.
We have our application running on a Sun Solaris system and have a local WebSphere MQ installation. The applcation uses bindings mode to connect to queue manager. When trying to send message to the local queue, the JNDI binding is successfull but we encounter javax.jms.JMSSecurityException: MQJMS2013: invalid security authentication supplied for MQQueueManager error. When investigated found that the credentials (userid) used for authentication is not case sensitive as the user on which the application is running. The userid matches but it is not a case sensitive match. By default the user on which the application is running will be passed for authentication, but here the case sensitive match is failing. The application server is WebLogic. Appreciate any inputs.
In order to open the local queue, the application must have first connected to the queue manager successfully. The error on the remote queue is a connection error so it is not even getting to the queue manager. This suggests that you are using different connection factories and that the second one has some differences in the connectivity parameters. First step is to reconcile those differences.
Also, a MQJMS2013 Security Error can be many things, most of which are not actually MQ issues. For example some people store their managed objects in LDAP and an authentication problem there will throw this error. For people who use a filesystem-based JNDI, OS file permissions can cause the same thing. However if it is an actual WMQ issue (which this appears to be) then the linked exception will contain the MQ Reason Code (for example, MQRC=2035). If you want to be able to better diagnose MQ (or for that matter any JMS transport) issues, it pays to get in the habit of printing linked exceptions.
If you are not able to resolve this issue based on this input, I would advise updating the question with details of the managed object definitions and the reason code obtained from printing the linked exceptions.
We were using createQueueConnection() in QueueConnectionFactory for creating the connection and the issue got resolved by using the method createQueueConnection("",""). The unix userid (webA) is case sensitive and the application was trying to authenticate on the MQ with the case insensitive userid (weba) and MQ queue manager was rejecting the connection attempt. Can you tell us why the application was sending the case insensitive userid (weba) earlier?
Thanks,
Arun
Are there any known methods of finding peers without using a dedicated central server?
ie: If I have peers which are disconnecting and reconnecting to the internet but getting a new IP address each time, and I want to connect to them without setting up a dedicated server to register with.
I was thinking about using peers email address to send a manifest of connected peers periodically, with some sort of timecode, negating the need for a dedicated server. This would be a fallback if none of the peers could be connected to after trying all the previously known peer addresses. But existing models of finding peers would be preferable.
There's no way around having to know at least one initial peer to discover more.
Fully P2P protocols, such as Gnutella or Gnutella2, or the simpler Overnet (made famous by Storm Worm), are based on each client having a start-up list of a few peers. These can come off a web-based automated tracker for example. The client will discover the whole network or portions of it by asking other peers for more addresses, for example when delegating a file search.
If you truly can't have any kind of a centralized resource, the best you can do is find the first peer through broadcasted messages and ultimately IP address scanning. The first approach is well-meaning but in at least 98% of cases won't yield any results. The later approach, of course, is abusing the internet, as well as illegal in most countries.
I really would rethink having some kind of a central tracker. It can be something as simple as a PHP script on a webserver (the gnutella network, today, is held up by ten-twenty such scripts, hosted by people who don't even know each other). And this sure is more lightweight than email (which, due to spam filters at the very least, would not work anyway).
In the limited case of peers within an intranet, it is possible to send a broadcast UDP message to a known port asking for peers to report back.
The BitcoinQT client uses a variety of methods to find nodes, some of them might be useful to you.
Satoshi Client Node Discovery
IRC is no longer used, but might be the most easy to implement:
As of version 0.6.x the Bitcoin client no longer uses IRC bootstrapping by default, and as of version 0.8.2 support for IRC bootstrapping has been removed completely. This documentation below is accurate for most prior versions.
In addition to learning and sharing its own address, the node learned about other node addresses via an IRC channel. See irc.cpp.
After learning its own address, a node encoded its own address into a string to be used as a nickname. Then, it randomly joined an IRC channel named between #bitcoin00 and #bitcoin99. Then it issued a WHO command. The thread read the lines as they appeared in the channel and decoded the IP addresses of other nodes in the channel. It did this in a loop, forever, until the node was shutdown.
When the client discovered an address from IRC, it set the timestamp on the address to the current time, but it used a "penalty" of 51 minutes, which means it looked like it was actually seen almost an hour earlier.
Take advantage of any existing forum where data can posted. Think secret IRC channel, embedding data in photos and posting to photo sharing sites 4chan?, any site that would allow your application to login and post data without captia logins etc.
http://chatzilla.hacksrus.com/faq/#password
Another strategy might be to embedded messages in digital currency transactions. Pick a cheap coin that's likely to hang around ... DOGE or MOON coin maybe. Build wallet functionality into your app. such that you can post micro transactions back and forth between addresses that your app controls. There would still be a miners fee, but this is only fractions of pennies. Even if they later prohibit adding metadata to transactions, you could make a transaction equivalent to your IP address in MOON, and use vanity addresses in MOON coin for your app. such that when a new node comes online it knows what to search the blockchain for -- 2daMOON%bootStr#pM3. SEND - 104.003021133 MOON IP = 104.3.21.133 not an expensive proposition.
Old question but I've been thinking about this problem myself so will ad my 2-cents. In short, a central server is not required if a node is aware of at least one valid peer. New nodes must be added to the network by any current member (e.g. invited, or node spawns another node, depending on your application).
Assuming that:
agents keep track of peers; the size of this address book and how entries are managed will depend on the nature of the system; e.g. how long peers remain connected, if peers use stable addresses
agents share peer information with other peers
at least some agents remain available for relatively long periods of time relative to frequency node connects to network to update it's address book (or nodes have stable addresses)
in addition to peer addresses, availability information is also tracked (many options here depending on your system. examples include: whether peer has a stable address, when last seen, some availability metric, content/service type information, address valid-until time if known)
new agents are initialized with at least one valid peer (doesn't have to be a central node, can be any valid node)
trust mechanisms shall be required if malicious peers are a possibility
When a peer comes online, it queries the peers in it's peer table to discover which are active and perhaps removes expired dynamic addresses. Nodes exchange peer information and may become linked themselves. This peer discovery/exchange may continue a certain number of hops or via random walk until peer list if of sufficient size and/or quality.
A few more details:
Nodes connect and share peer information with frequency related to how often node addresses change, so address book doesn't become stale and node becomes disconnected because none of it's former peers are available at their last known addresses
Nodes may need to limit the number of peers they accept, to avoid tendency towards centralization around the most stable nodes.
Nodes should be selective about the peers they keep; i.e. ones in which they are more likely to exchange data (e.g. weight based upon history)
Node links may be asymmetric or symmetric depending on the application
Three ways, off the top of my head, though you're always going to need some central server to start the connection unless you went with option 3.
Central server that maintains known list of peers, with keep-alive.
One or more central servers that maintain some common resource peers can use to discover one another, but once connected no longer need the central server as long as the peer remains connected (something like BitTorrent); can chain peered connections as well.
Port/IP scanning (strongly not recommended).
In your example, you'd still have some kind of central server where the peers would be registered; the protocol is the only difference.
To put it simply no, there is no way to do this without a central sever.
If you want to do this you simply need one or more central servers, whether by dynamic dns or not. The clients need a method to discover where they should connect to, and the only truly sensible way to do this is with your own server, in the simplest scenario it only needs to send an IP address in response.
Virtual severs can be had for around $15/month, which IMO is considerably cheaper than trying to use or abuse someone else's bandwidth.
[Edit].
To put it simply, there is another way, as follows.
Upon reflection I think what I'd do is to designate a set of peers as cluster controllers and use a dynamic DNS service to allow other peers to discover the cluster controllers.
Choose a dynamic DNS provider I'll call it myc.ath.cx (I Use http://www.dyndns.com/).
Each peer has to be capable of becoming a cluster controller. A cluster controller will contain a list of all the other peers connected.
When a peer is started it looks up myc.ath.cx and attempts to connect. If connection cannot be made within a period, say 30 seconds, it takes over the registration of the DNS entry.
Any peer wishing to discover other peers can simply query myc.ath.cx and a list will be provided
All peers are responsible for periodically downloading the list of peers, in case they need to cluster controller.
The cluster controller will periodically query the DNS entry - if has changed from it's IP address then it knows that it is no longer the cluster controller - so it will contact the cluster controller that currently has the DNS entry and provide it's list of known hosts.
The cluster controller will periodically contact hosts on the list to ensure that they are still valid.
Your method of sending email does use a dedicated server, though; the peer's email server, to be precise.
Roughly, I don't think it's possible without using some sort of dedicated storage or server (which the email approach does, albeit obliquely) UNLESS you are able to characterize the connectivity to the internet that your peers are using.
Basically, if you have a set of X number of peers, that connect for Y amount of time, and they are then off the grid for Z amount of time... essentially, you can construct a probability equation about how likely it is that the set of peers that you last contacted is still available; where that probability approaches 1 (for a given set of X, Y, and Z above), you can most likely sustain a peer-to-peer network without using storage.
Possibly more in the spirit; instead of having a "dedicated central server", use simple online free service to specify a peer list. Set up a yahoo group, or something like that; clients can automatically look it up and get a peer address from which to query a set of peers; the client can be coded with the authentication to post to the group, and can post periodically its IP address so that others can request the set of known active peers.
If you want to get really tricky, you can start using basically steganographic methods to hide peer location information. I.e. get a google search for "blah"; find the first site listed in the results that has an unprotected (no CAPTCHA) message board; find the third (or whatever) post that starts with "Indubitably" (or whatever), and find the header of the first message there, and there's the IP address of a peer. If that doesn't work, go down the list of search terms to the next one.
But that's sneaky. :-)
Could you re-use an existing dedicated server for the purpose?
I am thinking in particular of registering each of the peers with a Dynamic DNS, but if you were willing to get a bit uglier, sharing access to a known Hotmail account or Google Doc or the like.
You can either use a central directory or some sort of broadcast protocol for service discovery. Assuming that you could get them indexed by Google, you could conceive of a system whereby each peer runs a web site with some unique, rare words contained on a specific page. You could then use Google search results based on these words to identify potential peers. This would essentially be a (noisy and slow) internet broadcast.
If the page structure was a well known pattern or contained identifiable connection information for that peer, it would be easy to distinguish them in the search results. Using such a public directory leaves you open to compromised nodes in the network that is formed, but this is pretty much true of any P2P network absent some security mechanism.
Getting the web sites crawled and highly ranked by Google (or some other search engine) for your particular arcane set of search terms would be the trick. I can think of a couple of ways, but they aren't ones that I would use. For a legitimate service, I'd rather spend the money or find a free web site that could function as a directory.
What about another P2P system built specifically to track online peers of other P2P systems?
Then we reduce the problem of finding peers for any new P2P system to simply finding peers for the 'main' P2P system, which will give you the addresses of online peers for the system you're interested in using...
This is a typical use of a distributed hash table algorithm. I'd suggest looking at something like pastry. It uses a overlay network (Application layer network) on top of other layers.
Each node has a GUID which is used to route requests across the peer network.
If you're loooking for an already established central server then see the metaserver entry on page here:
http://martindevans.appspot.com/
You can register peers on there and then other peers can find them. Obviously this is a central server, but it requires no maintenance on your part.