I enable Squid transparent in windows using this method (youtube link). But after enabled, pages with HTTPS is showing error.
In Chrome this message is: SSL Connection Error (ERR_SSL_PROTOCOL_ERROR)
In Firefox: Security Connection Fail (Error code: ssl_error_rx_record_too_long)
IE: Check if TLS and SSL Protocols has enabled.
Is possible disable the SSL / HTTPS in squid?
Or solve this problem in another way.
Tks.
Yes, I didn't watch the video clip - but simply tell your browser to not use the proxy for HTTPS or port 443.
Alternately, if you're using the transparent firewall method, you can either tell the firewall to skip port 443, or to ONLY redirect port 80 through the proxy eg.
iptables -t nat -I PREROUTING -p tcp --dport 443 -j ACCEPT
the above will just accept HTTPS-port traffic and ignore all the other firewall rules for it
or
iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to 3128
which will only redirect port 80 to your transparent squid.
PS It's a really bad idea to try and proxy SSL - it completely defeats the purpose of SSL.
According to this link: http://wiki.squid-cache.org/KnowledgeBase/Windows
Squid features not operational:
DISKD: still needs to be ported
Transparent Proxy: missing Windows non commercial interception driver
SMP support: Windows equivalent of UDS sockets has not been implemented
So it might not be possible to use squid as transparent proxy on window.
Related
I have 3 machines:
1. An application which uses different databases and other services.
2. Proxy (mitmproxy) (192.168.56.51)
3. Server with all databases and services which are required for the application. (192.168.56.50)
All 3 machines are in the same local network running Centos 7.
Right now machine 1 is using databases and services on machine 3.
My task to use the machine 2 as it would be a machine 3 and show all the traffic. I.e. I need to be able to listen to all ports on machine 2 and redirect traffic on equivalent ports on machine 3.
I made port redirects to mitmproxy port (8080) on machine 2 in iptables:
-A PREROUTING -i eth0 -p tcp -m multiport --dports 23:8079 -j REDIRECT --to-ports 8080
-A PREROUTING -i eth0 -p tcp -m multiport --dports 8081:65000 -j REDIRECT --to-ports 8080
Also, added forwarding to machine 2:
/etc/sysctl.d/mitmproxy.conf :
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv4.conf.all.send_redirects=0
Then I started mitmproxy on machine 2:
mitmproxy --rawtcp
Then I tried to run an application, but mitmproxy shows a warning when something is trying to connect to a database. An example:
Warn: 192.168.56.1:51204: HTTP protocol error in client request: Bad HTTP request line: b'\x04\x00\x00\x00\x01...
What am I doing wrong?
I've confugured Dante 1.4on Ubuntu 16.04 as a socks5 proxy for Telegram.
Chats are working, but voice calls are not, failing at "Connecting".
Is there something special I need to configure in order to proxy Telegram voice traffic?
I'm using a single non priveleged (>1024) TCP/UDP port + login + password for connection.
Thanks!
UPD: Thats piece of log while i am trying to call somebody:
Apr 15 23:05:38 (1523736338.510915) danted[22977]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.36562
Apr 15 23:08:33 (1523736513.020190) danted[22989]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.49065
I can answer the call at destination device but connection is looping and getting error after 30 seconds.
Proxying UDP with socks is a bit more complex than it might seem, so let's start from the beginning.
Telegram calls use UDP with socks. Socks5 RFC1928 defines the following sequence for relaying UDP:
Client instantiates a TCP socks5 connection.
Client sends a UDP ASSOCIATE request, containing the client's source address and port, which will be used to send UDP datagrams to the socks5 Server. They might be zeros (in Telegram they are) (section 4).
Socks5 Server binds a random UDP port for relaying datagrams for this TCP socks5 connection and sends a UDP ASSOCIATE response, containing the address and port where the client should send the datagrams to be relayed (section 6).
To send a datagram, the Client must add a header to the payload, containing a destination address and port, where the server should relay that datagram (section 7).
Server will keep the UDP port bound until the TCP socks5 connection terminates.
As you can see, opening a single TCP port is not enough. For UDP to work correctly, the automatically bound UDP port must be reachable by client. NATs and Firewalls might further complicate the situation.
UDP relaying configuration with Dante
Telegram calls are Peer-to-Peer, so the udpassociate command should be allowed to 0/0:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
# udp.portrange: 40000-45000
command: udpassociate
log: error connect disconnect
}
udpreply (that's for the actual relaying, the 4'th step above) should also be allowed to everyone as well:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
command: udpreply
log: error connect disconnect
}
If your socks5 Server is behind a firewall, open a range of UDP ports (say 40000-45000) and add the udp.portrange: 40000-45000 line to the udpassociate block (see the commented out example in the first point). Then Dante would bind UDP ports in that range only.
If your socks5 Server is behind a NAT, then the returned destination address in the response to UDP ASSOCIATE request would be a local IP, rather than the external one. That local IP is unlikely to be reachable by the client, so the sent datagrams would be silently dropped.
Unfortunately, Dante uses the destination address of the TCP connection as the one where the client should send UDP datagrams to (see the comment in the source code). NAT mangles this address from an external to a local one, so the Dante's assumption that the client can reach the proxy using that destination address is broken.
A possible solution, which doesn't involve patching Dante, would be to use iptables to change the destination address from a local to the external one (assuming that it's known and doesn't change):
# 203.0.113.12 – the external IP
# 1080/tcp - Dante TCP port
# 40000:45000 – Dante UDP portrange
iptables -t nat -A PREROUTING -p tcp --dport 1080 -j DNAT --to-destination 203.0.113.12
iptables -t nat -A PREROUTING -p udp --dport 40000:45000 -j DNAT --to-destination 203.0.113.12
# If external address is not added to any network device on that
# machine, then add it to the loopback interface, so the kernel
# would know where to route the DNATed packets:
ip addr add 203.0.113.12/32 dev lo
I had the same problem. Found the solution.
You have to add udpassociate bindreply udpreply commands to conf file. here is my conf file that works with voice calls.
logoutput: syslog /var/log/danted.log
internal: ip port = 1080
external: ip
socksmethod: username
user.privileged: root
user.unprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bind connect udpassociate bindreply udpreply
log: error connect
}
Allow clients' voice traffic
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: udpreply
log: connect disconnect error
socksmethod: username
}
iptables -A INPUT -p udp -m multiport --dports 1024:65535 -j ACCEPT
You should enable calls via proxy in your telegram settings.
I have a squid3 proxy server with 2 squid process running on dfferent port, as following:
one squid running on "http_port 808"
another running on "http_port 809 transparent" and has an iptable rule running as iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 809
I use proxy in 2 way:
set proxy ip:808 into Internet Explorer option
set proxy server as gateway in Windows network settings
These 2 mode works well.
Now I have a Linksys 1900AC router and have flashed openwrt 15.05. I want it to work as a transparent proxy so that every computer connected to this router could surf the Internet without setting Internet Explorer option.
After some search, I found this Wiki link, but it doesn't work.
If I set option dest_port 809, my chrome browser shows "access denied" or something like that. If I set option dest_port 808, the squid "cuts off" my website URL. Say that I enter http://www.bing.com/images, squid just tells me that it "cannot find URL '/images'".
Has anyone succeeded on this transparent proxy stuff?
I'm trying to set up a transparent proxy on my Mac OS X Lion (10.7.5), so I can use mitmproxy (to intercept SSL traffic from android applications). I followed the steps in the mitmproxy docs for setting up port forwarding with pf on Mac OS X, and they all went without any errors:
$ sudo sysctl -w net.inet.ip.forwarding=1
Password:
net.inet.ip.forwarding: 0 -> 1
$ sudo pfctl -f pf.conf
No ALTQ support in kernel
ALTQ related functions disabled
$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
But it doesn't seem to have had any effect. When I go to websites in my browser, it makes a direct request, and doesn't go through the port I specified. Here is the pf.conf file (en1 is my wifi):
rdr on en1 inet proto tcp to any port 80 -> 127.0.0.1 port 4500
rdr on en1 inet proto tcp to any port 443 -> 127.0.0.1 port 4500
Thanks for stopping by the IRC channel today. I've tracked this down, and the basic issue is that the rdr rules apply to inbound traffic. This means that they will NOT redirect traffic coming from the box itself. If you think about it, this is inevitable: we can't distinguish between an outbound connection from a non-mitmproxy app, and an outbound connection from mitmproxy itself. We can use route-to to send the traffic to lo0 and then redirect it, but that causes an infinite loop where mitmproxy's own outbound connections are also redirected back to mitmproxy.
Because I know a bit about your use case, I would suggest exploring ways to do this with VirtualBox. A plan of attack would be to set the VirtualBox network up in bridge mode, and then use a pf rule with a match on the source address to redirect traffic to mitmproxy. That should do what you want, and not cause singularities in time and space due to infinite redirection.
Please drop by the IRC channel again if you need a further hand with this.
Did you try net.inet.ip.scopedroute=0? From http://lucumr.pocoo.org/2013/1/6/osx-wifi-proxy/:
Now currently if you finish that above setup you will notice that
nothing actually works. The cause for this is a Bug in the OS X kernel
that requires flipping the net.inet.ip.scopedroute flag to 0. I am not
entirely sure what it does, but the internet reports that it breaks
network sharing through the user preferences. In any case it fixes
ipfw based forwarding so you can flip it with sysctl:
$ sudo sysctl -w net.inet.ip.scopedroute=0
Unfortunately in OS X Lion this flag can actually not be flipped from
userspace so you need to set it as boot parameter and then restart
your computer. You can do this by editing the
/Library/Preferences/SystemConfiguration/com.apple.Boot.plist file
(continued...)
You are using the port 4500 instead the default port 8080.
Do you start mitmproxy with the port specification?: mitmproxy -T --host -p 4500
Did you follow the steps to set the certificate in the Android device? http://mitmproxy.org/doc/certinstall/android.html
Another problem could be the gateway on your android phone: Preferences - Wifi - Hold on the network you are using - Edit network - Advanced options - Set as gateway the ip of your machine with mitmproxy.
By the way I have the same warning with No ALTQ function but it works.
This is a very basic Amazon EC2 question, but I'm stumped so here goes.
I want to launch an Amazon EC2 instance and allow access to HTTP on ports 80 and 8888
from anywhere. So far I can't even allow the instance to connect to on those ports using
its own IP address (but it will connect to localhost).
I configured the "default" security group for HTTP using the standard HTTP option on the management console (and also SSH).
I launched my instance in the default security group.
I connected to the instance on SSH port 22 twice and in one window launch an HTTP server
on port 80. In the other window I verify that I can connect to HTTP using the "localhost".
However when I try to access HTTP from the instance (or anywhere else) using either the public DNS or the Private IP address I het "connection refused".
What am I doing wrong, please?
Below is a console fragment showing the wget that succeeds and the two that fail run from the instance itself.
--2012-03-07 15:43:31-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31-- http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”
[ <=>
] 7,512 --.-K/s in 0.03s
2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]
[ec2-user#ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17-- http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:
Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08-- http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$
The standard tcp sockets interface requires that you bind to a particular IP address when you send or listen. There are a couple of somewhat special addresses: localhost (which you're probably familiar with) which is 127.0.0.1. There's also a special address, 0.0.0.0 or INADDR_ANY (internet protocol, special shorthand for ANY ADDRESS). It's a way to listen on ANY or more commonly, ALL addresses on the host. This is a way to tell the kernel/stack that you're not interested in a particular IP address.
So, when you're setting up a server that listens to "localhost" you're telling the service that you want to use the special reserved address that can only be reached by users of this host, and while it exists on every host, making a connection to localhost will only ever reach the host you're making the request from.
When you want a service to be reachable everywhere (on a local host, on all interfaces, etc.) you can specify 0.0.0.0.
(0) It's silly but the first thing you need to do is to make sure that your web server is running.
(1) You need to edit your Security Group to let incoming HTTP packets access your website. If your website is listening on port 80, you need to edit the Security Group to open access to port 80 as mentioned above. If your website is listening on some other port, then you need to edit the Security Group to access that other port.
(2) If you are running a Linux instance, the iptables firewall may be running by default. You can check that this firewall is active by running
sudo service iptables status
on the command line. If you get output, then the iptables firewall is running. If you get a message "Firewall not running", that's pretty self-explanatory. In general, the iptables firewall is running by default.
You have two options: knock out the firewall or edit the firewall's configuration to let HTTP traffic through. I opted to knock out the firewall as the simpler option (for me).
sudo service iptables stop
There is no real security risk in shutting down iptables because iptables, if active, merely duplicates the functionality of Amazon's firewall, which is using the Security Group to generate its configuration file. We are assuming here that Amazon AWS doesn't misconfigure its firewalls - a very safe assumption.
(3) Now, you can access the URL from your browser.
(4) The Microsoft Windows Servers also run their personal firewalls by default and you'll need to fix the Windows Server's personal firewall, too.
Correction: by AWS default, AWS does not fire up server firewalls such iptables (Centos) or UAF (Ubuntu) when you are ordering the creation of new EC2 instances - That's why EC2 instances that are in the same VPC can ssh into each other and you can "see" the web server that you fired up from another EC2 instance in the same VPC.
Just make sure that your RESTful API is listening on all interfaces i.e. 0.0.0.0:portID
As you are getting connection refused (packets are being rejected) I bet it is iptables causing the problem. Try to run
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
and test the connection.
You will also need to add those rules permanently which you can do by adding the above lines into ie. /etc/sysconfig/iptables if you are running Red Hat.
Apparently I was "binding to localhost" whereas I needed to bind to 0.0.0.0 to respond to port 80 for the all incoming TCP interfaces (?). This is a subtlety of TCP/IP that I don't fully understand yet, but it fixed the problem.
Had to do the following:
1) Enable HTTP access on the instance config, it wasn't on by default only SSH
2) Tried to do nodejs server, so port was bound to 80 -> 3000 did the following commands to fix that
iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush
Amazon support answered it and it worked instantly:
I replicated the issue on my end on a test Ubuntu instance and was able to solve it. The issue was that in order to run Tomcat on a port below 1024 in Ubuntu/Unix, the service needs root privileges which is generally not recommended as running a process on port 80 with root privileges is an unnecessary security risk.
What we recommend is to use a port redirection via iptables :-
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
I hope the above information helps.