Is it possible to name a multicast or broadcast address? Usually for a single machine I'd put a line in /etc/hosts. Will that work for a multicast address?
I have a private server on AWS that has no publicly open inbound ports. The only open port is SSH, and it's only accessible from other machines in the same subnet.
This machine reads files from S3 over the network. Recently it stopped working because the server's time had drifted by more than 15 minutes and the requests to S3 were rejected:
<Code>RequestTimeTooSkewed</Code>
<Message>
The difference between the request time and the current time
is too large.
</Message>
<MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds>
The easy fix is to install ntp, but it requires opening UDP port 123. Because UDP is stateless, both inbound and outbound ports must be open.
How can I automatically update the system time using only TCP connections initiated by my server? Is there a standard TCP-based daemon like NTP? I don't care if it's not as precise: even a skew of up to 10 minutes would be acceptable.
Edit 2 Jun 2017
This is how the security groups are set up:
Inbound
Type Protocol Port Range Source SSH TCP 22 172.31.0.0/16Outbound
Type Protocol Port range Destination All traffic All All 0.0.0.0/0
This is the network ACL for the subnet - just the default ACL:
Inbound
Rule # Type Protocol Port Range Source Allow / Deny 100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW * ALL Traffic ALL ALL 0.0.0.0/0 DENYOutbound
Rule # Type Protocol Port Range Destination Allow / Deny 100 ALL Traffic ALL ALL 0.0.0.0/0 ALLOW * ALL Traffic ALL ALL 0.0.0.0/0 DENY
Edit 2 Jun 2017 #2
Alright now it works without any special security groups, as prediceted by @Tim. I think I was just not testing it properly:
ntpdatedoesn't use the servers in/etc/ntp.conf, so it was reporting an error:no servers can be used, exiting
ntpddoes not attempt to update the clock as soon as it starts; it waits for a minute or so.
Testing instead with ntpdate-debian, and without port 123 open in a security group, works fine; and ntpd updates the time properly if I let it run for a while.
I'm running a Tornado web server that only accepts SSL connections, and only listens on port 443. Connecting to it in a browser over HTTPS works well.
I'm seeing messages like this in my logs:
ERROR [tornado.general] Uncaught exception
[...]
File "/usr/lib/python3.4/ssl.py", line 828, in do_handshake
self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:600)
WARNI [tornado.access] 405 OPTIONS / (<some IP>) 0.57ms
I'm not sure if the warning is related to the error (I need to add time stamps to the logs). The requests don't come in quickly which makes me think it's not an attack; on the other hand, they are coming from many places over the world, and this is a site that not many people should know about.
If I try it myself by going to http://my-site:443 I get the same exception, without the warning, plus an additional line:
WARNI [tornado.general] SSL Error on 18 ('<my IP>', <port>): [SSL: HTTP_REQUEST] http request (_ssl.c:600)
Is something using the wrong protocol to connect to the HTTPS port?
I have a network that looks like this:
ADSL VLAN 2 VLAN 3
------[Modem]----------[firewall]----------[intranet PC]
|
| VLAN 4
\-------------[DMZ server]
I want to set up port forwarding to expose a web server in the DMZ to the Internet. The IPs are:
- Modem: 192.168.0.1
- Firewall eth0.2: 192.168.0.126
- Firewall eth0.3: 192.168.1.1
- Firewall eth0.4: 192.168.2.1
- PC: 192.168.1.2
- Server: 192.168.2.2
I opened ports 80 and 443 on the modem and have them forwarded to the firewall (192.168.0.126). And I have these rules in iptables on the firewall:
NAT:
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -d 192.168.0.126/32 -p tcp -m multiport --dports 80,443 \
-j DNAT --to-destination 192.168.2.2
-A PREROUTING -d 192.168.1.1/32 -p tcp -m multiport --dports 80,443 \
-j DNAT --to-destination 192.168.2.2
-A POSTROUTING -o eth0.2 -j MASQUERADE
Forwarding:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
# Disallow new connections from DMZ to modem and intranet
-A FORWARD -d 192.168.0.0/16 -i eth0.4 -m state --state NEW -j DROP
# Allow intranet to access Internet
-A FORWARD -i eth0.3 -o eth0.2 -j ACCEPT
-A FORWARD -i eth0.2 -o eth0.3 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow DMZ to access Internet
-A FORWARD -i eth0.4 -o eth0.2 -j ACCEPT
-A FORWARD -i eth0.2 -o eth0.4 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow web ports to DMZ
-A FORWARD -i eth0.2 -o eth0.4 -p tcp -m multiport --dports 80,443 -j ACCEPT
# Allow intranet to access DMZ
-A FORWARD -i eth0.3 -o eth0.4 -j ACCEPT
-A FORWARD -i eth0.4 -o eth0.3 -m state --state RELATED,ESTABLISHED -j ACCEPT
Everything seems to work well except for the port forwarding. If I open 192.168.1.1 in a browser from an intranet PC, I see the DMZ server. And this is how it looks in telnet:
$ telnet 192.168.1.1 80
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'
But if I try to open it from the Internet using the modem's external IP, I get this:
$ telnet <EXT_IP> 80
Trying <EXT_IP>...
telnet: Unable to connect to remote host: No route to host
I tried setting up a hairpin NAT as described in the answer to this similar question, but there was no change. Maybe I didn't use the right addresses.
So, two questions :)
- Why can't incoming connections see the DMZ server?
- Is my iptables configuration gernerally OK? Or should I be dropping packets by default somewhere?
The firewall is running Debian Jessie, Linux 3.16.