In android, i have a proxy daemon which listens on a dedicated port and would like to relay the visit of some specific domains,but not for others, for example: this proxy will relay the request for www.yahoo.com, but does not affect www.google.com.
Is it possible to use iptables to implement this?
Normally it can't do that. Iptables routes/blocks traffic from/to IP's/Ports. Maybe a plugin can do that, but I am not firm with iptables plugins, and I don't know anything about iptables on android.
Apache can forward connections to, maybe that's the right choice for you.
Related
I have redirected all ipv4 dns request to my local dns server on port 60053 use iptables -J redirect.
But when I trying to do the same things for ipv6 dns request I failed, cause there isn’t a nat table for ipv6 on my router.
I have googled but didn’t found a solution, any suggestions would be appropriate. Thanks.
The nat table isn't there because the kernel module isn't loaded. You'll need to load it (and probably install it first). If you're on OpenWRT, the package you need is ip6tables-mod-nat.
I just got a raspberry pi for Christmas and I have just installed apache, php and all the required stuff to host my website. I want to use my raspberry pi as a web server for my website. I obviously need to port forward! Apache is running on port 80 how safe is it to forward port 80? I want to know if I port forward is my whole Wi-Fi now under threat from hackers ? If I am hacked, what can they compromise ? And finally I heard about changing the apache port to stop malicious bot port scanners, can I just change my port from 80 to anything or are there only certain ports ?
Thanks, Jamie
The thing is: if you want people's web browser to access your web app, it needs to be on standard ports (80 or 443 for HTTPS). You'll need to redirect connections to ports 80 and/or 443 on your raspberry pi ' local ip in the configuration of your router.
If you want to isolate your raspberry pi from the rest of your local network and that your router allow it, consider putting it in a dmz
Even if you were to redirect on a custom ports later to be listened to by Apache, it wouldn't change much in such a case. If you want to secure your server, there is several other options to consider (fail2ban, firewall rules, etc).
Last: from personal experience, raspberry pis make good web servers to experiment with. Have a lot of nerdy fun
(I'm in fact, on the CentOS behind AWS ELB. But i don't want this question to be specific for AWS ELB only, but for the general ground.)
I'm working on a CentOS 6.5 box, which is behind a loadbalancer which only passes the X-Forwarded-For IPs to me. As a web server, I know the bad IPs coming in, and I need to block them, from by server itself. (Assuming there is no any IPS/IDS/Firewall in front, to rely on.)
So far, I don't know (I can't) block those bad IPs by my iptables because there's no real IP, but only X-Forwarded-For IPs passed to me. (So what I do is, I am using the .htaccess to block. And it works)
How to achieve this by the proper firewall level please?
I'd like to do the same thing. I've got a very long list of IP addresses to block in CIDR format, and converting it to regular expressions to use in a .htaccess file just doesn't seem like the right thing to do. And you know that in terms of processor load, regular expressions in .htaccess aren't even in the same galaxy as the integer bit-fiddling that iptables can do. But I don't believe that it's possible to use iptables for this. Iptables runs in the kernel, and it blocks the incoming IP addresses at a low level, before any header is read.
In my case, I'm only using the load balancer as a convenient way to handle https requests, I don't really need to balance a heavy load across multiple webserver instances. So what I've been considering is running a separate instance with nginx reverse proxy to handle https for my apache webserver, adding the X_FORWARDED headers exactly like the AWS load balancer does. That way I can use iptables on the instance running nginx, and I don't have to touch my apache configuration or webapps that have been running behind the load balancer.
You lose the redundancy of multiple IP addresses for the load balancer itself, as well as integration with AWS Cloud Front to balance backend load, but you gain ability to use iptables and you can offload processing of static content from apache, perhaps improving your response time. Since nginx is said to be much lighter-weight than apache for simple request processing, you shouldn't need much muscle on that instance. I wonder if AWS load balancers are actually just instances running nginx. If you look at the pricing, the hourly cost of a load balancer is roughly the same as a t2.small linux instance.
I haven't tried this yet myself, as nginx configuration is brand new to me, and it would require buying and installing an SSL certificate instead of using the wonderfully simple and convenient certificate manager.
I wonder if AWS would consider user feature-requests to be able to configure load balancers with iptables...
UPDATE: I just posted this in the AWS EC2 forum.
UPDATE 2: My feature request to AWS asking for a feature to configure iptables for the load balancer got answered with an explanation of how to use a network ACL to block requests originating from any CIDR in a list from reaching the load balancer. To me, that's just as good a solution. The OP was looking for a solution not specific to AWS, and this doesn't meet that criterion. If you have this problem with some server that is behind a reverse proxy, it simply isn't possible to use that server's iptables-style firewall to block incoming requests based on the original IP address - the firewall needs to decide whether to block a request long before it reads the headers, which is the only place that the original requesting address can be found. If you're on AWS, you can use a network ACL. Otherwise you'd need to have full control over the server performing the reverse proxy, and put the firewall rules on that server.
Looks like you can do pattern matching with IP Tables: http://wiztelsys.com/Article_iptables_bob2.html
So you'd have to do that for example:
iptables -I INPUT 1 -p tcp --dport <port> -m string --string "X-Forwarded-For: <ip>" --algo bm -j DROP
"-m": matching type = string
"--string": what string
"--algo bm": Boyer-Moore algorithm for pattern matching
Since you mention .htaccess it sounds like you're using Apache Webserver, so I'd recommend adding these rules there instead of in iptables. The basic way of blocking based on X-Forwarded-For in Apache is this:
RewriteCond %{HTTP:X-FORWARDED-FOR} ^171.42.6.123$
RewriteRule .* - [F,L]
Since the IP address is just a string being matched against then you can specify all sorts of regular expressions in your condition. See this question for an example of doing that.
I ran into a problem I'm not able to fix. I have a server with some applications (a ghost blog and gogs for example) that are listening on specific ports. I want apache to handle them via proxypass. So far so good, I can specify a subdomain and let the requests through to the applications. But all my applications are still reachable via the specific port they run on. I can't let apache listen to this ports because, well, the ports are in use by the applications.
I'm just wondering is there a way to let any apllications just listen on a port and be reachable from locahost (so that only apache can reach them with that port) or is there any other way to limit the access to my applications so that they are only reachable through apache? Is there a solution I can use for all applications or do I have to tweak every single app myself?
Googling it just didn't get me the rights answers (lots of port 80 to https and so on)
Thank you for every answer / tipp / nudge in the right direction you can give me.
Best regards.
Allright, the biggest problem is always in front of the computer :)
I never thought about iptables, I don't know why, because I'm quite familiar with it. For anyone else having the same stupidity problem I had:
Make a rule that allows localhost to access this port:
iptables -A INPUT -p tcp -s localhost --dport 25 -j ACCEPT
Then just block every connection on that port with iptables
iptables -A INPUT -p tcp --dport 25 -j DROP
Don't forget to change 25 to your specific port.
Best regards.
I have a VPS server with a domain example.com, with apache2 listening port 80
Then, I have a web app in jetty server (running with mvn jetty:run), listening in port 8080
When I type example.com in a browser, I get a apache example page "it works!"
If I write example.com:8080 I get my webapp
Question is simple, how can I redirect for when I write example.com so that I get to my webapp?
I cant change port jetty to 80, its error.
command "sudo iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080" does not anything effect
So, how can i make apache redirect 80 to 8080? in sites-enabled/default-000?
Please explain carefully, I'm a newbie with systems ;(
Thank you
EDIT
I solved it with this:
http://czetsuya-tech.blogspot.com.es/2012/07/how-to-port-forward-apaches-80-to.html#.VImt1XvyOPU
But last line:
RewriteRule ^/(.*) ......:8080/0,81 € [P,L]
Makes error at restart apache
I deleted it and works fine. Any problem with this? What is RewriteRule?
Using IPTABLES is one possible solution. I don't know much about IPTABLES - but there are a lot of tutorials out there, like this one: http://proghowto.com/iptables-redirect-port-80-to-port-8080
I don't know if that works if you have a running daemon (apache) on the destination port.
The other solution is to use a proxy module in apache to pass requests through to your webapp. On Linux only root users are allowed to use ports below 1000. On Windows you should be able to simply change the port in the jetty configuration.
There are two tutorials I often use, they apply to apache and tomcat but that makes no difference for the apache side:
https://confluence.atlassian.com/display/DOC/Using+Apache+with+virtual+hosts+and+mod_proxy
https://confluence.atlassian.com/display/STASH/Integrating+Stash+with+Apache+HTTP+Server
This is quite a common setup. Also there is almost no performance impact due to the proxying. Not that a user would notice anything.