Security team has requested access logs of our bomgar appliance to be sent to their qradar (enterprise security information and event management (SIEM) product) server over port 514.
Will the events be properly sent when filling out the URL field shown below in the 'outbound events' tab? example. 127.0.0.12:514
enter image description here
Yes, that should be fine if it is over UDP(514 default). But, if the syslog server is configured for TCP then the default port is 6514 (well-known port). So make sure this specific configuration?
Make sure the topology is in place as mentioned in RFC 5425 under Deployment Scenarios.
Related
We are using SharePoin 2013SP1 in-premise with OWA-2013, WOPIZone is set to external-http in SP, view/editing/adding of office files works behind the load-balancer (LB) but when viewing from client (outside LB) blank page is displayed for any office files.
When launching the URL of OWA check "http:///hosting/discovery" from the client I get the XML file displayed on the client browser.
Check the OWA and SP logs and could not find any exception, the file checking is performed and replied successfully (compared this with a good request and failure request both seams same).
hence requested network team to check on firewall, who has given the below info.
Network Findings:
we found that IPS signature HTTP: RFC 2397 Data URL Scheme Policy blocked the traffic.
It was found that the reply from server was blocked due to DATA URI packet is transferred which is blocked at firewall.
Question:
1) Can provide more info on this DATA URI base64 encoding data reply from OWA server. When network team want to open this policy what info I should provide (origin source, uni/bi drection, etc).
2) Any other such policy to be opened for view/adding/editing office files using OWA from client.
3) In the event this rule/policy is marked as "HIGH" in terms of security then any other work-around for viewing office files through OWA.
Thanks,
Hari
I'm new to setting up smtp, and I'm trying to figure out how to secure my server, but I'm getting a little turned around with all the security options - hopefully someone can help me clear this up. I'm using Windows 2008 R2 sp1 with IIS 7.5 if that makes any difference.
So what I'm seeing is, in the properties of the smtp virtual server I have an Access tab with an Authentication button. Seems to make sense, I pick Integrated Windows User, but then on the Delivery tab, I see an Outbound Security button which presents the same set of options again. I select Integrated Windows User.
Then, following the instructions I found online to setup smtp, I created a new domain under the smtp virtual server which then gave me ANOTHER Outbound Security tab with the same set of options. What are all these settings for? I've scoured google and couldn't find anything differentiating the 3 (maybe more?). I've found various sites that will tell me what one does or another, but they all seem to be doing the same thing and no site addresses that. Does one override another? Like a default for the server, but then specific ones for the domains or something like that? What's the difference between the Authentication and Outbound Security? What's the difference between the Outbound Security for the domain and for the main smtp server?
Oh, and one more question while we're semi on the topic - is the setup for domains mainly used for remote access? Like, it would be unnecessary for localhost use?
You have two sets of authentications: inbound and outbound.
The Access tab lets you limit who and from where are allowed to access your SMTP server (i.e inbound), while the Outbound Security in turn lets you provide credentials that the SMTP service will use when delivering mails to another SMTP server (e.g. if relaying all outgoing emails to a smarthost that requires authentication).
You can furthermore set up remote domains, i.e. have emails for a specific domain be delivered to a specific server using specific credentials.
It is highly recommended to have all your outgoing emails forwarded to a smarthost that acts as an official email server for your sending domain, otherwise you risk your emails being classified as spam because they are sent from an unknown server.
Docusign connect service is not posting data to the url specified in the connect service option. Actually if i resend the data from log it works but it do not works on its own.
Please help me
Thanks
Usually when DocuSign Connect is not publishing to a URL it is caused by one of a few things:
Your server is not listening on the correct port(s).
You are not testing for the correct events.
You do not have the user (sender) configured for Connect.
Your server is not publicly accessible.
Your firewall or network security is not letting the requests going through.
Your server has crashed.
A potential bug with DocuSign Connect.
Possible resolutions:
If testing in DocuSign demo environment (demo.docusign.net) ports 80 (http) and 443 (https) are allowed. If testing in production environment (www.docusign.net) only 443 - https is allowed.
Make sure you are testing for the correct event triggers - this can be confirmed on your Connect settings page. Login to the Console and go to Preferences -> Connect -> (select one of your Connect configurations). On the following page you'll see how to select events that you want Connect to push on, as well as for which users.
Followup answer to 2 - you need to also make sure you have the correct account members enabled for Connect on the Console -> Preferences -> Connect page.
You can not use a localhost address for the Connect URL - it must be a publicly accessible URL.
Your network administrator might have a firewall (physical or virtual) or other security software setup that is stopping the requests from going through. Check your security settings and test that the proper ports are enabled, etc.
Ensure that your server is still up and running and that it hasn't crashed.
Although DocuSign Connect has been around for some time it still occasionally exhibits a bug or two. If not one of the other potential reasons then provide the failure log in your post and someone from DocuSign will follow up.
If you are running into issues with DocuSign Connect hopefully one of the above remedies resolve your issue.
I've installed WebSphere MQ 7.1 on Linux platform, after which I installed WebSphere Message Broker 8.0.0.1. Now when I try to create an execution group, I get an exception: Reason code 2035. This exception states that the user is unauthorised to connect to the queue manager. I have this user added in the mqm group. I did not face any such issue when I was working with MQ 7.0.x. I searched a lot and came to know that there is user ID blocking in MQ 7.1. But, I want this user to be able to create execution group, how can I do so? Please advise.
MQ security has been improved a lot in MQ v7.1 and is different from what it used to be in earlier MQ versions. In MQ v7.1, by default all SYSTEM.channels are blocked. If you are trying to use any of these SYSTEM. channels then you will get 2035 which is MQRC_NOT_AUTHORIZED. The recommended way is to create your own SVRCONN channel for broker and create channel authentication records to allow the user to access queue manager.
Please see this link for detailed answers from T.Rob on similar issue.
Update:
A SVRCONN channel defines the endpoint of a queue manager meaning the connection information required by the clients to connect to a queue manager. Client applications use this type of channel to send and receive messages to/from a queue or a topic.
Message Broker toolkit is GUI that you can use to administer message broker, for example creating execution groups, creating flow, deploying bar files etc. Toolkit is available on Windows and I guess it's available on Linux.
I got to know that MB toolkit requires SYSTEM.BRK.CONFIG channel which is a SVRCONN channel to connect to queue manager. I am thinking this is the channel you will need to authorize to allow Message Broker to connect to MQ. Can you check if this is the case and if so create channel authentication record for that channel?
If you create a new QMgr at V7.1 or above, it comes with the following default CHLAUTH rules:
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
DESCR(Default rule to allow MQ Explorer access)
ADDRESS(*)
MCAUSER( ) USERSRC(CHANNEL)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
DESCR(Default rule to disable all SYSTEM channels)
ADDRESS(*)
MCAUSER( ) USERSRC(NOACCESS)
SET CHLAUTH(*) TYPE(BLOCKUSER)
DESCR(Default rule to disallow privileged users)
USERLIST(*MQADMIN)
The one on the bottom tells the QMgr "if someone tries to connect over a SVRCONN using an administrative user ID, block the connection in all cases."
To allow a connection from Broker Toolkit you have two choices as follows:
Remove mqbrkrs from the mqm group. This allows it to connect without firing the CHLAUTH rule that blocks admin users. You will of course be required to grant authorization for the mqbrkrs group to all the broker and application queues to which it needs access since it is no longer an MQ admin.
Override the CHLAUTH rule to allow the broker toolkit to connect as an admin on the SYSTEM.BROKER.CONFIG channel.
As a security specialist, I favor the first option. It is unavoidable that the MQ admin can administer the broker. However it is possible to avoid allowing the broker (and by extension all the broker flows) to administer the QMgr.
If, however, you wish to take the second route you'll need to override the CHLAUTH rule that blocks admin access. There are several ways to do this. You could delete the rule but that opens all your channels to admin connections. A more precise approach is to provide a rule just for the channel on which the administrator is to connect. For example:
SET CHLAUTH(SYSTEM.BKR.CONFIG) TYPE(BLOCKUSER) +
USERLIST('*NOACCESS')
Since WMQ applies the most specific rule, the default rule is overridden by the new one but only for the SYSTEM.BKR.CONFIG channel. The BLOCKUSER rule syntax allows us to specify who to deny but not who to allow and it takes user IDs rather than group IDs. In order to allow admin access it is necessary to specify some ID that is not *MQADMIN. I picked *NOACCESS because it cannot be an actual user ID and is a reserved word used by WMQ elsewhere. You could as easily used any user ID such as nobody or even mqm. (Blocking mqm would allow mqbrkrs but not mqm however since mqbrkrs is in the mqm group it would not restrict mqbrkrs from administering the QMgr.)
Finally, note that any channel which allows admin access should be strongly authenticated. If the only CHLAUTH rule you set is the one above, then anybody with a network route to the QMgr can connect on that channel by asserting the mqbrkrs user ID on the connection. Once connected, they would have full control over the QMgr and the ability to remotely, anonymously execute commands using the mqm or mqbrkrs user IDs. At the very least add a CHLAUTH rule to filter conenctions on this channel by IP address. Or, even better, use SSL and filter connections by the certificate distinguished name.
I want to configure SMTP on my web server, so that any email sent through the SMTP server is relayed to a remote SMTP Server. The IIS SMTP server would have to use SMTP authentication, and use the host name, username and password (as if configuring a normal email client).
Does anybody know if this is possible?
Yes, it' completely possible, and relatively easy to configure.
I've got a couple of articles about SmartHosting on my web site that will probably help:
http://www.christopherlewis.com/SmartHosting/SMTPSmartHosting.htm
and
http://www.christopherlewis.com/SmartHosting/SMTPSmartHostingPt2.htm
They're written towards Exchange 2003, but Exchange 2003 used IIS's SMTP engine, so the settings are the same.
Bascially, you right click the SMTP site, select properties, Delivery tab, Outbound security, and enter your credientials in the Basic Authentication fields. Back on the Delivery tab, you then click Advanced and enter the remote SMTP server name in the SmartHost field.
Editing
The links above are no longer available.
Try http://intellitect.com/configuring-windows-smtp-server-on-windows-2008-for-relay/.
HTH and answers your needs
http://www.cmsconnect.com/praetor/webhelpg2/Chapter_2_-_Pre-installation_considerations/Configuring_the_SMTP_Server.htm
I think you can only set outbound relays for specific domains, not blanket coverage.
http://www.isaserver.org/articles/smtprelayinboundoutbound.html
EDIT:
I've not done this before, buy maybe worth a try:
From the Server properties, you could try selelcting the 'Delivery' Tab, then advanced. In the Smart Host, type the outgoing SMTP relay IP / domain. Select OK, and then select 'Outboud Security' and enter your username / password in the basic authentication box.