LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (http://www.linuxquestions.org/questions/linux-networking-3/)
-   -   IPTABLES: Give access to my LAN to IMAPS server in the Internet (http://www.linuxquestions.org/questions/linux-networking-3/iptables-give-access-to-my-lan-to-imaps-server-in-the-internet-4175483040/)

bypper 11-01-2013 10:10 AM

IPTABLES: Give access to my LAN to IMAPS server in the Internet
 
Hi everybody:
I'm sure this is a trivial problem for any Iptables'es expert, but I can't find the solution.

Gateway with Linux Debian Stable (DEBGW from now) with 2 netcards
eth0: 192.168.1.10 with access to internet
eth1: 192.168.2.10 with access to LAN


LAN: 192.168.2.0/24 with the only access to Internet through Squid proxy in the DEBGW.


DEBGW has a iptables rules with INPUT & FORWARD policy DROP by default.

Now, I need give IMAPS/SMTP access from LAN to IMAPS server(111.111.111.111) in the Internet, and no more.

I know, if I set MASQUERADE for LAN, and open FORWARD access to ports, it runs. This is the way...

$ iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -d 0.0.0.0/0 -j MASQUERADE
$ iptables -A FORWARD -p tcp --dport 993
$ iptables -A FORWARD -p tcp --dport 567


But, the LAN's users can now browse the web without set proxy config in theirs browsers.

what rules must I define to setup this correctly?
Thank you

Ser Olmy 11-01-2013 02:42 PM

Quote:

Originally Posted by bypper (Post 5056610)
DEBGW has a iptables rules with INPUT & FORWARD policy DROP by default.

Now, I need give IMAPS/SMTP access from LAN to IMAPS server(111.111.111.111) in the Internet, and no more.

I know, if I set MASQUERADE for LAN, and open FORWARD access to ports, it runs. This is the way...

$ iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -d 0.0.0.0/0 -j MASQUERADE

This rule will cause all forwarded traffic to be NATed behind the outgoing interface. You may want to add "-o eth0" and even "-i eth1" to avoid unintended consequences (security issues).

Quote:

Originally Posted by bypper (Post 5056610)
$ iptables -A FORWARD -p tcp --dport 993
$ iptables -A FORWARD -p tcp --dport 567

These rules do nothing at all, as there's no target.

Quote:

Originally Posted by bypper (Post 5056610)
But, the LAN's users can now browse the web without set proxy config in theirs browsers.

If these are the only rules and the FORWARD policy is DROP, that should be impossible. You need to check your ruleset (iptables -S FORWARD).

bypper 11-01-2013 06:05 PM

Quote:

Originally Posted by Ser Olmy (Post 5056708)
This rule will cause all forwarded traffic to be NATed behind the outgoing interface. You may want to add "-o eth0" and even "-i eth1" to avoid unintended consequences (security issues).

What do you want to say??
As this?

$ iptables -t nat -A POSTROUTING -o eth0 -s 192.168.2.0/24 -d 0.0.0.0/0 -j MASQUERADE

The result is the same, and if I add "-i eth1" nothing runs. The browser can't browse without proxy, but the conection to 993 port does not work.

Quote:

These rules do nothing at all, as there's no target.
Sorry, I forgot write the final "-j ACCEPT" in the post.

Quote:

If these are the only rules and the FORWARD policy is DROP, that should be impossible. You need to check your ruleset (iptables -S FORWARD).
These are...
-P FORWARD DROP
-A FORWARD -s 130.193.126.125/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 99.24.186.236/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 64.60.169.59/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 79.125.19.127/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 114.44.101.60/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 85.174.231.98/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 184.80.13.252/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 80.240.200.206/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 190.2.16.134/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 98.207.90.250/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 220.130.85.181/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 60.217.235.5/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 70.52.248.153/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 213.27.158.45/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 25 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 135:139 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 993 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 5800 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 5900:5910 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 25 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 135:139 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 993 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 5800 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 5900:5910 -j ACCEPT
-A FORWARD -p udp -m udp --dport 135:139 -j ACCEPT
-A FORWARD -p udp -m udp --sport 135:139 -j ACCEPT
-A FORWARD -s 192.168.2.26/32 -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -s 192.168.2.26/32 -j logeo


Can you find the cause?

Best Regards

bypper 11-01-2013 06:09 PM

Quote:

Originally Posted by bypper (Post 5056782)
$ iptables -t nat -A POSTROUTING -o eth0 -s 192.168.2.0/24 -d 0.0.0.0/0 -j MASQUERADE

The result is the same, and if I add "-i eth1" nothing runs. The browser can't browse without proxy, but the conection to 993 port does not work.

Oh, wait
it give me an error...

iptables v1.4.14: Can't use -i with POSTROUTING

Ser Olmy 11-01-2013 06:15 PM

Quote:

Originally Posted by bypper (Post 5056785)
Oh, wait
it give me an error...

iptables v1.4.14: Can't use -i with POSTROUTING

You're right; the "-i" parameter should be used in the corresponding FORWARD rule(s). The idea is to block connections from the outside using spoofed IP addresses.

bypper 11-01-2013 06:18 PM

Quote:

Originally Posted by Ser Olmy (Post 5056790)
You're right; the "-i" parameter should be used in the corresponding FORWARD rule(s). The idea is to block connections from the outside using spoofed IP addresses.

Sorry, I don't undestand you :-(
Can you write some example?

Ser Olmy 11-01-2013 06:41 PM

Quote:

Originally Posted by bypper (Post 5056782)
-P FORWARD DROP

"Implicit deny" is always a good start.
Quote:

Originally Posted by bypper (Post 5056782)
-A FORWARD -s 130.193.126.125/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 99.24.186.236/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 64.60.169.59/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 79.125.19.127/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 114.44.101.60/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 85.174.231.98/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 184.80.13.252/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 80.240.200.206/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 190.2.16.134/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 98.207.90.250/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 220.130.85.181/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 60.217.235.5/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 70.52.248.153/32 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 213.27.158.45/32 -j REJECT --reject-with icmp-port-unreachable

FWIW, if you're trying to block IP addresses that attempt to spread malware or log in using various automated/scripted techniques, there are better ways to do it than creating a rule for every single address.
Quote:

Originally Posted by bypper (Post 5056782)
-A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Here's your problem. You're allowing all NEW connections, regardless of protocol or port number. All rules below this point will make absolutely no difference. Remove NEW, and the rule will allow only active sessions that have already been allowed through by other rules, which is what you want.

Once you've fixed this rule, you should probably keep it at the very top of the chain, to keep the kernel from having to parse a long list of single-IP rules for each and every incoming packet.
Quote:

Originally Posted by bypper (Post 5056782)
-A FORWARD -p tcp -m tcp --dport 25 -j ACCEPT

This one is probably going to bite you hard once a PC gets infected with a spamming trojan. Almost no mail providers use port 25 for outbound mail, they use authenticated SMTP with STARTTLS over the "mail submission" port (TCP/587).

If you're running a mail server, then by all means allow outbound SMTP for that IP, but not for the entire network.
Quote:

Originally Posted by bypper (Post 5056782)
-A FORWARD -p tcp -m tcp --dport 135:139 -j ACCEPT

Why are you allowing Microsoft SMB over the Internet?
Quote:

Originally Posted by bypper (Post 5056782)
-A FORWARD -p tcp -m tcp --dport 993 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 5800 -j ACCEPT
-A FORWARD -p tcp -m tcp --dport 5900:5910 -j ACCEPT

If you're using VNC, it might be a good idea to specify directionality (source and/or destination IPs) or ingress/egress interfaces. As things stand, anyone on the Internet can send spoofed packets to the VNC ports of hosts on your LAN.
Quote:

Originally Posted by bypper (Post 5056782)
-A FORWARD -p tcp -m tcp --sport 25 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 135:139 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 993 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 5800 -j ACCEPT
-A FORWARD -p tcp -m tcp --sport 5900:5910 -j ACCEPT
-A FORWARD -p udp -m udp --sport 135:139 -j ACCEPT

None of these are needed. Reply packets are handled by the state rule.

bypper 11-02-2013 05:02 AM

Quote:

Originally Posted by Ser Olmy (Post 5056800)
"Implicit deny" is always a good start.

Yes, of course ;-)
Quote:

FWIW, if you're trying to block IP addresses that attempt to spread malware or log in using various automated/scripted techniques, there are better ways to do it than creating a rule for every single address.
Well, I have a file with the banned IPs, really, but perhaps isn't very professional :-P
Can you give a track about it?
Quote:

Here's your problem. You're allowing all NEW connections, regardless of protocol or port number. All rules below this point will make absolutely no difference. Remove NEW, and the rule will allow only active sessions that have already been allowed through by other rules, which is what you want.

Once you've fixed this rule, you should probably keep it at the very top of the chain, to keep the kernel from having to parse a long list of single-IP rules for each and every incoming packet.
YES, You are GREAT! ;-)
I have removed the "NEW" and the users can't browse directly, but the conection to 993 port runs.
Quote:

This one is probably going to bite you hard once a PC gets infected with a spamming trojan. Almost no mail providers use port 25 for outbound mail, they use authenticated SMTP with STARTTLS over the "mail submission" port (TCP/587).

If you're running a mail server, then by all means allow outbound SMTP for that IP, but not for the entire network.
Well, the rule is bad, I need open the 587 port, really. They have to auth to SMPT server for send mail, but the used port is 587, not 25. You get every single thing. :-D
Quote:

Why are you allowing Microsoft SMB over the Internet?

If you're using VNC, it might be a good idea to specify directionality (source and/or destination IPs) or ingress/egress interfaces. As things stand, anyone on the Internet can send spoofed packets to the VNC ports of hosts on your LAN.

None of these are needed. Reply packets are handled by the state rule.
Really, these rules are probes. it aren't used, and I'm going to remove it.

Thank you so much, Ser Olmy.


All times are GMT -5. The time now is 06:30 AM.