Default ports to be open for a kerberos protected web server on different domain from the user - cross-domain

A client computer ClientA (with IE) belonging to DomainA, domain controller DCA.
A server computer ServerB (with IIS) belonging to DomainB, domain controller DCB.
Which are the minimum required default ports between machines from the two domains I need to open to allow a user in Client A, to login into a kerberos protected Web Application hosted in IIS on ServerB with its DomainA credentials?
At a minimum ClientA to ServerB TCP 80 :)
When the ClientA makes a request to ServerB:80 it receives a NEGOTIATE Authorize Header. Then ClientA does a SPN request to DCA on port 88. Then I don't know if DCA need to contact DCB or if it is required for DCA and DCB to have been established some kind of configuration (one-way trust?) between them and which ports need to be opened for that.
I guess ClientA doesn't need to contact DCB in any case.
Let's imagine ClientA have received the required service token from DCA. Then it sends its own credentials to ServerB. In order to decrypt the token and figure out if I am who I am, ServerB needs to contact DCB? Or ServerB needs to contact DCA? I guess not.
Be aware that in principle I don't have the requirement to be able to list DomainA users from the ServerB machine. I could manually add users in web.config Authorization section.
It seems to me that the ports listed here https://support.microsoft.com/en-us/kb/179442
is too much for my scenario.
EDIT:
After reading several info on the subject, it seems ClientA computer need to have TCP 88 (Kerberos) connectivity to DCB. And between DomainA and DomainB a one-way trust should be established previously so a TDO object exists in the two domains, so DCA would be able to generate referals tickets for DCB to consume. It seems there is no need for direct connectivity between DCA and DCB except the one needed to have the TDO objects synchronized.

Related

Using a Secure SSL-app within a none -SSL VPN, still possible to be jeopardized data?

In some countries like Iran or china because of severe Internet censorship, people use a foreign VPN server to bypass government censorship.
Imagine we implement a none-SSL VPN for people who connect their phone to the Internet through this VPN. I want to know if they use a secure application within their phone which is secured by SSL like Instagram or WhatsApp, still, is there any security issue for the transmitted data between their phone and server?
I mean is it possible in this case their data would be sniffed by the government or others? (although the VPN is none-SSL but Instagram is SSL secured)
If I understand the scenario you have described, the VPN does not use SSL when communicating with the user device, but the secure application requires the use of SSL between the server and the client device.
The answer would depend on a few more things. Does the "severe internet censorship" flat out restrict the usage of the application? Take Instagram for example. Is the government banning the use of the application in its entirety or just certain aspects (such as filtering specific tags)? Sometimes the term "internet censorship" is used to mean one of these things but not the other (though most often the former).
Assuming the application is banned in its entirety, and the connection to the VPN is not secured by SSL, then the domain which is being banned would be visible to eavesdroppers at some point prior to the secure channel establishment (with SSL or rather TLS) between the client device and server. For example, it is likely the case that the DNS resolution of the domain is unencrypted (either at the client device level or communicating the query to the VPN). So, the eavesdropper (say, the government) would be able to see this and possibly act on it (say by dropping the request if they have a middlebox unknown to you).
So basically, if the connection to the VPN is not secured by SSL (or TLS) then there would be no benefit in using the VPN with regards to censorship.

is it feasible to save the public IP of the user in my API in case of a thef of a jwt?

I was thinking about how to secure my API and prevent token theft from affecting my users. I thought it would be a good idea to save my users IP if an attacker manages to steal a token and is used by one with a different IP. I'm going to use a middleware or a function to verify if it is in the user ip list and if not I'm going to reject his token and then ask for your credentials in the frontend. If the credentials are correct I will overwrite the IP or store it as a new one.
I don't know exactly what you mean by "is it feasible". Yes, you can do it if you want.
But, there are plenty of potential issues with relying on a user's IP address not changing and forcing them to reauthenticate every time it does change.
1. Mobile devices moving around. As mobile devices move on a cellular network, their IP address can legitimately change.
2. Mobile devices connecting to different networks (such as WiFi). As your phone goes from being in your car and on the cellular network to being at home and on your WiFi network, that phone's IP address in connecting to your service will change.
3. NAT behind some firewall. Nearly every user (even home users) are going through a NAT device and the IP address you're seeing is the IP address of a gateway, not the actual user's IP address. In a larger corporate network, the gateway IP address may not always be the same. And, multiple different users may appear to be from the same gateway IP address so there is not necessarily a one-to-one correspondence between users and IP addresses.
In general, you should just be using https for all connections in which you transmit the JWT so there is little risk of man-in-the-middle attacks stealing the JWT. The user themselves needs to secure their own local storage of the JWT.
An approach used by many modern services is to fingerprint the local device by recording a set of characteristics it has which may even include the presence of some other cookie along with a number of other browser characteristics. Then, you require reauthentication whenever the fingerprint changes by some significant amount. You will see many bank and airline websites doing something like this. The idea here is that even if the credential is stolen, then the fingerprint is unlikely to match when a credential is being used by an attacker.

Secure communication between two servers

I want to securely store private keys of my users on a separate server (lets call it B) and it's used to sign, decrypt information. B stores keys on a database (postgres). Server A (public) sends information to B. Ideally B needs to get the private key, sign the token with information and send it back to A. Instead of sending the private key to A, which can be a security issue (if server A is compromised).
My options are:
web sockets
Https request (https://nodejs.org/api/https.html#https_https_request_options_callback)
Questions:
Is there any other options to securely communicate with two servers?
If server B was on port "7000" how can I make sure only server A can access it?
How does HSM server help in my case and how does it communicate with other servers (websocket or https request)?
I could just take the easy route and connect database of server B on port "7000" and run queries from A but as I said it's not as secure. I heard that HSM handles/decrypts information and sends it back, so I though I can do something similar with normal servers.
Thanks any help would be appreciated
UPDATE
#zaph has answered questions 2 and 3.
Question: Does server A need to do a https request and include the private ip address of server B, for example https://203.0.113.25? Then server B would use an API router to handle the request. However ip isn't a DNS, therefore it won't work due to certificates. So how do servers communicate, send/receive data?
Reference: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html
For others: Use security groups, configure them so only a specific instance can access it. Make a normal request, e.g.: domain.com:PORT. PORT is the instance that's listening to request...
When you specify a security group as the source or destination for a
rule, the rule affects all instances associated with the security
group. Incoming traffic is allowed based on the private IP addresses
of the instances that are associated with the source security group
(and not the public IP or Elastic IP addresses).
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html

How can I get information about the users network when he tries to authenticate towards my IIS?

I want users, when they are in the workplace (e.g. on the LAN), to authenticate themselves with their regular username and password. Auto-login is disabled.
However - logging in from outside the LAN should trigger a 2-level authentication (like SMS, mail or similar). How can we get information about the users network when they try to log in to the application from outside the LAN?
NB - it does not matter if you have AD user and pwd. If you are on the outside you have to trigger the 2 level auth.
NB2 - we do not want any client-side scripts running, so this must be something coming with the initial request
Technology: IIS 7, ISA 2006, .Net 4, MS Sql 2008 server.
Question also asked here: https://serverfault.com/questions/354183/what-2-level-authentication-mechanism-is-available-that-can-differentiate-if-the
Information why ISA server remove the information I need: http://www.redline-software.com/eng/support/articles/isaserver/security/x-forwarded-isa-track.php
If it's reasonable, don't expose your web server to anything outside of your LAN -- require VPN access.
If that isn't reasonable, you should be able to use the REMOTE_ADDR variable to determine the source of the request. Whitelist your LAN as single-factor and require everything else to be multi-factor. Depending on the scenario, the server variables will be similar to either
Context.Request.ServerVariables ["REMOTE_ADDR"]
or
Request.UserHostAddress()
If you have a proxy in the way, make the proxy tag the originating IP source in the headers and read the request headers to determine the external IP.

Receive sms on specific port j2me

I am developing j2me app. I need to receive sms on specific port. Which is the best port to define for receiving sms?
Thanks for advice
The SMS spec (JSR 120) says you can't have a port that another app is using at that time, and also you can't have any of the ports that are specified in the following table.
For security reasons, Java applications are not allowed to send SMS messages to the port numbers listed in Table A-4. Implementations MUST throw a SecurityException in the
MessageConnection.send() method if an application tries to send a message to any of these port numbers.
Table A-4: Port Numbers Restricted to SMS Messages
Port number Description
2805 WAP WTA secure connection-less session service
2923 WAP WTA secure session service
2948 WAP Push connectionless session service (client side)
2949 WAP Push secure connectionless session service (client side)
5502 Service Card reader
5503 Internet access configuration reader
5508 Dynamic Menu Control Protocol
5511 Message Access Protocol
5512 Simple Email Notification
9200 WAP connectionless session service
9201 WAP session service
9202 WAP secure connectionless session service
9203 WAP secure session service
9207 WAP vCal Secure
49996 SyncML OTA configuration
49999 WAP OTA configuration
Oddly, I can't see any restriction on any other values of the port number. I'm sure this must be set out somewhere but I can't find it in the spec.
However, I strongly suggest restricting yourself to port numbers between 1 and 65535.
Generally 5001 port is use for such operation. you can see very good example here.

Resources