I would like to use the code at this link to send tweets from Oracle PL/SQL. However I have to convince the network administrator to open up the port on the DMZ firewall in order to do this. So my question is what port would that code need so that I can tell them to open that port. Is it just port 80 for html, so nothing has to be opened?
There's this: Twitter Development Talk
The Twitter API runs on standard web service ports: Port 80 for non-secure traffic and Port 443 for SSL-based traffic.
Related
I'm looking for a command like:
ping google.com
But I also want to use the port, like google.com:8080
I want to know if a client can connect to my servers socket listener at a certain port.
My core problem is, 100% of users are able to connect to my websocket port at 8080, but only single digit x% are able to connect to websocket port at 2053. This is independent of device. After research I've found out that some ISPs might be blocking this port.
Hello today configured vps on Google Cloud and put Vesta control panel, but the problem is not open one https that is, and the ip server and the domain itself does not open on https. Set up Google Cloud firewall and opened ports 80,443 but https does not open the site itself is not the ip of the server. Checked through online services port 443 is closed but settings of the server and a firewall of Google and ip tables say that port 443 is opened (checked by several services port 443) and in the browser through ip of the server and the domain on https do not open. Please tell me how to open port 443?
Same with ports 8443,8080.
I am not able to comment but here are some steps that might help to isolate the issue:
Check to see if the port is open or closed or filtered using nmap
nmap [ip_address]
Firewall rules are defined at the network level and therefore make sure that you follow this document while creating the firewall rules to allow incoming traffic on TCP port 80 and 443 (same for other ports). In this document in step 11, choose " specified protocols and ports" and enter tcp: 80, tcp: 443.
As you previously stated, you need to make sure there is no firewall running inside the VM blocking those connections.
You also need to verify if the application running on your vps is listening on port 443. To check this, try with this command.
sudo netstat -ntlp | grep LISTEN
In the output, if you don't see the application beside port number, check if your vps is rightly configured to ports for your application.
I was having the same issue with NGinx. And Found the root cause finally to be the Firewall (GCP VM Firewall) having a lower priority for the rule. ie: I had 65534 (which is super low priority) for the "Ingress 443" rule. Which did block the traffic coming into the SSL. Instead when I set this rule to 1, traffic started flowing and issue sorted.
What finally helped me was https://cloud.google.com/vpc/docs/using-firewalls
Thanks #Md Zubayer for the tip.
All,
I have a web application running on tomcat on an amazon ec2 instance and I have a DNS name on godaddy which redirects to this web app on ec2 with an elastic ip.
Everything works fine when I open the port number 80 to all inbound traffic but recently I received an email from Amazon support saying Denial of Service (DoS) attacks were launched from my instance to IP(s) xxx.xx.xx.xxx via UDP port(s) 80.
How can i make the application accessible by closing port 80 to outside world?
Thanks in advance,
keran
http is over TCP. Only open TCP on 80, keep UDP on 80 closed. The webapp should work.
I have a web application running on tomcat on an amazon ec2 instance and I have a DNS name on godaddy which redirects to this web app on ec2 with an elastic ip.
A re-directs is an HTTP thing (and not very effecient, nor good for bookmarking). Do you mean your web app has an A record?
Everything works fine when I open the port number 80 to all inbound traffic
Yup, you need to open port 80 to serve traffic.
but recently I received an email from Amazon support saying Denial of Service (DoS) attacks were launched from my instance to IP(s) xxx.xx.xx.xxx via UDP port(s) 80.
There are 2 possible explanations:
1) Your software is buggy and trying to send data to their box via UDP. This isn't that likely, but is possible if you accidentally enabled/misconfigured collectd, syslogd, statsd, or some other package.
2) Your software is buggy and let a hacker take over your box. It could have been your web application, or it could have been some other service (if you have other ports open to the world).
Either way, a good system administrator could use TCPDump to figure out where the problem is.
How can i make the application accessible by closing port 80 to outside world?
You Can't. If you want to serve traffic to the world, you need an open port. Blocking port 80 TCP will not fix your problem because "incoming traffic on TCP port 80" (used for web servers) has nothing to do with "outgoing UDP port 80". If your box is sending UDP traffic, then it's a broken/misconfigured program running on your box.
That said, you can use a proxy service like CloudFlare to "hide" your servers behind their load balancers. But that won't fix your fundamental problem, which seems to be that your box insecure. If you are going to put a server on the Internet, you need to level up your security knowledge, or hire a system administrator.
If your content is "static" (i.e. not constantly changing, like a simple blog that's updated a few times per day), you should look into serving it from S3. S3 doesn't require a System Administrator, while EC2 does.
My server offered by boss can access by port 80.
How can I configure the Web UI port 7180 to 80?
It doesn't work that I modified the server_port in /etc/cloudera-scm-agent/config.ini
I can't access the UI, so the following does not work:
Cloudera Server Ports
I need configure it in config files.
I have strong belief that you should NOT change this port. It's possible in general, however you may meet some issues like those one in your case.
I can suggest you to use reverse proxy server such as Nginx or Apache. It's much safer and maybe even faster.
So as result I'll get the following proxying chain which is fully transparent to clients:
Client (your Boss) connects to server via port 80
Nginx (or Apache) is listening port 80
Nginx sends HTTP requests to Cloudera on port 7180
Nginx returns request result to client (your Boss)
I currently have a small socket server that I'm trying to convert to a web server. Basically it dumps XML to anyone connecting to it. At the moment, it's not a web server as it listens to a non-web port (1337).
I know that both 80 and 8080 are accepted web ports, but none of those are free on the machine I'm going to use. Are there any other web ports available? Or how do I configure a windows machine so that e.g. port 1337 is web?
Well for the most simplistic method append :port to your URL such as http://192.168.1.1:1337
I may be misunderstanding your question though.
You just start listening on the port. Viola. It's a server. That simple.
Oh, and you have to tell your audience which port to use.
To be more complete: it's a web server not because of the port, but because of the language spoken on that port. You can serve HTTP over any port, which is one of the ways back-door-style malware gets around misconfigured firewalls.
What you probably need is to implement (in order to implement an easily usable web service, which I assume is what you are aiming for) the http protocol and probably SOAP or REST, not select a port number. Tell us what language you are using, and we might be able to suggest a suitable framework.
What #fictoris said. Or setup your webserver to redirect http://myapp.com to the correct port as well.
There's nothing really magic about the ports you are talking about. And really it's just port 80 that's standard HTTP. 443 is the standard for secure HTTP though (HTTPS).
If you have to run on a non-standard port you must specify that port in every (non-relative) URL: http://localhost:13828 ...
If you need to use port 80 you might be able to redirect the incoming client depending on what demain it requested though.
Here is a list of all the TCP/UDP ports that have official designations and the hi-jacked, oh I mean unofficial ports that are known. Hopefully that will give you an idea of what is going on "out there."
Note the "Dynamic, private or ephemeral ports: 49152–65535" section at the bottom.