Ok,
I have a challenge - get two services working over a single port. (!) Sometimes it's a web service, sometimes it's a VNC service. Here's what I had in mind:
1) Server is normally a webserver listening on port 80, and normally has the following rules active: # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -t nat -A POSTROUTING -j MASQUERADE
2) Server hosts a special PHP script, that when called correctly, sets rules like
# iptables -I PREROUTING -p tcp -s $REMOTE --dport 80 -j DNAT --to-destination $FWIP:$FWPORT # iptables -I FORWARD -p tcp -s $REMOTE --dport 80 -j ACCEPT
The *next* tcp connection from their computer to the webserver will get NAT'd to service $FWIP:$FWPORT.
But I want this rule cleared out as soon as the connection is made with the latter altered rules. Is there a way to write a rule or set of rules that, when activated, then delete themselves? The "ESTABLISHED,RELATED" rule should keep the connection alive even after the latter rules are killed, right?
Is this possible? Am I just out in left field?
Benjamin Smith wrote:
Ok,
I have a challenge - get two services working over a single port. (!) Sometimes it's a web service, sometimes it's a VNC service. Here's what I had in mind:
- Server is normally a webserver listening on port 80, and normally has
the following rules active:
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -t nat -A POSTROUTING -j MASQUERADE
- Server hosts a special PHP script, that when called correctly, sets
rules like
# iptables -I PREROUTING -p tcp -s $REMOTE --dport 80 -j DNAT --to-destination $FWIP:$FWPORT
# iptables -I FORWARD -p tcp -s $REMOTE --dport 80 -j ACCEPT
The *next* tcp connection from their computer to the webserver will get NAT'd to service $FWIP:$FWPORT.
But I want this rule cleared out as soon as the connection is made with the latter altered rules. Is there a way to write a rule or set of rules that, when activated, then delete themselves? The "ESTABLISHED,RELATED" rule should keep the connection alive even after the latter rules are killed, right?
Is this possible? Am I just out in left field?
Without knowing your reasons for doing this, i would stick my neck out and say ... Have a look at port knocking - it looks like you are trying to either decrease your visibility, or mitigate a situation where you have no control over an intermediate firewall that only passes port 80
Regards,
MrKiwi
On Friday 16 March 2007, MrKiwi wrote:
mitigate a situation where you have no control over an intermediate firewall that only passes port 80
Yes, that's EXACTLY what I'm trying to do... but I dont' see how this exactly relates to port knocking.
Port knocking seems to be that you log connection attempts to various ports that are otherwise closed, EG:
iptables -I input -p tcp -j DENY -l
and then watch the log file for a specific, exact sequence of connections from a common source IP. How would that help me here? Are you suggesting that I log the inbound port 80, and then watch the logfile with a background script/daemon to clear out the rules?
Benjamin Smith wrote:
On Friday 16 March 2007, MrKiwi wrote:
mitigate a situation where you have no control over an intermediate firewall that only passes port 80
Yes, that's EXACTLY what I'm trying to do... but I dont' see how this exactly relates to port knocking.
Port knocking seems to be that you log connection attempts to various ports that are otherwise closed, EG:
iptables -I input -p tcp -j DENY -l
and then watch the log file for a specific, exact sequence of connections from a common source IP. How would that help me here?
Yes - you're right, it would not be a simple drop in solution. In the other scenario i suggested (reducing your visibility) port knocking would have been perfect.
You could still use a modified port knocking system i think - just using a url hit to do the triggering instead of a port knock sequence. That way the port knock config takes care of removing the iptables line after x seconds.
See Michael Rash's pdf http://www.usenix.org/publications/login/2006-02/pdfs/rash.pdf His implementation is rock solid, and easy to config. Also anyone with some grep and script skills should be able to hack the port-knock -> httpd-log-watcher part you need.
MrKiwi
MrKiwi wrote:
Benjamin Smith wrote:
On Friday 16 March 2007, MrKiwi wrote:
mitigate a situation where you have no control over an intermediate firewall that only passes port 80
Yes, that's EXACTLY what I'm trying to do... but I dont' see how this exactly relates to port knocking. Port knocking seems to be that you log connection attempts to various ports that are otherwise closed, EG: iptables -I input -p tcp -j DENY -l and then watch the log file for a specific, exact sequence of connections from a common source IP. How would that help me here?
Yes - you're right, it would not be a simple drop in solution. In the other scenario i suggested (reducing your visibility) port knocking would have been perfect.
You could still use a modified port knocking system i think - just using a url hit to do the triggering instead of a port knock sequence. That way the port knock config takes care of removing the iptables line after x seconds.
There is an expires ipfilter module, not a standard part of the kernel, but available from netfilter.org. I wish it were standard, there's a lot of folk I would cheerfully banish for a few hours: you trigger a spam alert, I block your /24 for 24 hours. You ping my ftp port, I take out your /24 for a day.
Benjamin Smith wrote:
On Friday 16 March 2007, MrKiwi wrote:
mitigate a situation where you have no control over an intermediate firewall that only passes port 80
Yes, that's EXACTLY what I'm trying to do... but I dont' see how this exactly
You will have a race condition.
You could, maybe, enable the DNAT for the source IP of the http request, that would alleviate both the race condition and the urgency to turn of off.
Also, you might be better enabling ssh through which you can more cleanly pipe your steaming hot VNC.
Or negotiate a clean pass with your network administrator; such folk tend to take a very dim view of those who would circumvent the rules.
Benjamin Smith wrote:
Ok,
I have a challenge - get two services working over a single port. (!) Sometimes it's a web service, sometimes it's a VNC service. Here's what I had in mind:
Let's step back; what problem are you trying to solve? It seems to me this odd requirement might not be the best solution.
- Server is normally a webserver listening on port 80, and normally has the following rules active:
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -t nat -A POSTROUTING -j MASQUERADE
- Server hosts a special PHP script, that when called correctly, sets rules like
# iptables -I PREROUTING -p tcp -s $REMOTE --dport 80 -j DNAT --to-destination $FWIP:$FWPORT # iptables -I FORWARD -p tcp -s $REMOTE --dport 80 -j ACCEPT
The *next* tcp connection from their computer to the webserver will get NAT'd to service $FWIP:$FWPORT.
But I want this rule cleared out as soon as the connection is made with the latter altered rules. Is there a way to write a rule or set of rules that, when activated, then delete themselves? The "ESTABLISHED,RELATED" rule should keep the connection alive even after the latter rules are killed, right?
Is this possible? Am I just out in left field?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Benjamin Smith -
John Summerfield -
MrKiwi