Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
About home router wiki
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
psychoteur
n00b
n00b


Joined: 26 Jul 2006
Posts: 34

PostPosted: Tue Apr 22, 2014 8:09 pm    Post subject: About home router wiki Reply with quote

Hello everyone.

I know it will seems silly but is the home router wiki documentation correct ?

https://wiki.gentoo.org/wiki/Home_Router

If if I follow the guide for the iptables set. My clients don't have web access.

If I inverse Wan and lan from the wiki it works.

But it makes no sense then when you watch the nat rules.

If someone can give me some light on what's happening I will be happy. No web it's a nightmare, you can't search for any answer.

Maybe a good book about iptables ...
Back to top
View user's profile Send private message
windex
n00b
n00b


Joined: 09 Dec 2012
Posts: 70

PostPosted: Wed Apr 23, 2014 7:45 pm    Post subject: iptables Reply with quote

Actually, that guide looks decent.

To be honest, you might want to consider installing an IDS on your network, but that would probably be overkill for what I suspect that you're trying to do.

Regarding web traffic, if you want to allow that into your network, you'll need to set an iptables rule, perhaps using something like:

Code:
vi /etc/sysconfig/iptables


should work. Please let me know if it doesn't. Inside of the config file, you'll want to add a line such as:

Code:
 -A PREROUTING -t nat -i eth1 -p tcp --dport 80 -j DNAT --to 192.168.1.50:80
-A INPUT -p tcp -m state --state NEW --dport 80 -i eth1 -j ACCEPT


Although you might need to add a rule for port 443 as well if you wish to permit encrypted traffic.

Regarding a good iptables tutorial - there aren't any, although this one by the Centos gang seems better than average:

http://wiki.centos.org/HowTos/Network/IPTables

Please let me know if you have any further questions! Congratulations on your interest in security!



Code:


Code:


Code:


Code:


Code:


Code:


Code:
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13505

PostPosted: Wed Apr 23, 2014 10:31 pm    Post subject: Reply with quote

That guide has some bad advice in a few key places. I recommend against using a default ACCEPT policy in your iptables chains. Instead, use default DROP and rely on the conntrack helper to permit legitimate traffic. Using REJECT for public facing interfaces is usually not worthwhile. Stateless ACCEPT for WAN->LAN traffic is only acceptable if your upstream performs proper egress filtering. Some do not, so again, you should use conntrack.

The rule for permitting access to sshd is correct, but I would not apply it if avoidable. There are many bots scanning for open services, including ssh.
Back to top
View user's profile Send private message
windex
n00b
n00b


Joined: 09 Dec 2012
Posts: 70

PostPosted: Thu Apr 24, 2014 4:06 pm    Post subject: Reply with quote

Hu wrote:
That guide has some bad advice in a few key places. I recommend against using a default ACCEPT policy in your iptables chains. Instead, use default DROP and rely on the conntrack helper to permit legitimate traffic. Using REJECT for public facing interfaces is usually not worthwhile. Stateless ACCEPT for WAN->LAN traffic is only acceptable if your upstream performs proper egress filtering. Some do not, so again, you should use conntrack.

The rule for permitting access to sshd is correct, but I would not apply it if avoidable. There are many bots scanning for open services, including ssh.


This might be correct.

If psychoteur is willing to publish his eventual ruleset, I'd be willing to peer review it with Hu. If it passes peer review, I'll volunteer to post the updated ruleset at the aforementioned wiki for other people to use.

Please advise.


Edited for : Formatting
Back to top
View user's profile Send private message
psychoteur
n00b
n00b


Joined: 26 Jul 2006
Posts: 34

PostPosted: Thu Jul 03, 2014 3:57 pm    Post subject: Reply with quote

Hello,

sorry, I had so many things to do. I didn't have time to come back to my post.

So I'm willing to post my settings and my iptables rules. It has so many holes at this time ;)

What I didn't get is why my rules were functionning with my old hardware and not with the new one.

My settings :

I've got a modem BBox 2 from my isp (belgacom - Belgium). I set DMZ on the ip of my server ( enp1s0)
enp1s0 receives fixed ip via dhcp from the box.
I've got bond0 with manual ip set and dnsmasq has dhcp server for it.

# Generated by iptables-save v1.4.21 on Thu Jul 3 17:55:39 2014
*security
:INPUT ACCEPT [4125218304:1159516641811]
:FORWARD ACCEPT [194890559:164291603681]
:OUTPUT ACCEPT [1486896137:4805636977523]
COMMIT
# Completed on Thu Jul 3 17:55:39 2014
# Generated by iptables-save v1.4.21 on Thu Jul 3 17:55:39 2014
*raw
:PREROUTING ACCEPT [4512269975:1572979685485]
:OUTPUT ACCEPT [1486896137:4805636977523]
COMMIT
# Completed on Thu Jul 3 17:55:39 2014
# Generated by iptables-save v1.4.21 on Thu Jul 3 17:55:39 2014
*nat
:PREROUTING ACCEPT [433855:555438333]
:INPUT ACCEPT [2590:250086]
:OUTPUT ACCEPT [2689:542752]
:POSTROUTING ACCEPT [1327:413618]
-A PREROUTING -i enp1s0 -p udp -m udp --dport 445 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p udp -m udp --dport 137:138 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 445 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 139 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 135 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p udp -m udp --dport 13674 -j DNAT --to-destination 10.0.0.11
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 13674 -j DNAT --to-destination 10.0.0.11
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 51413 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p udp -m udp --dport 51413 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 32400 -j DNAT --to-destination 10.0.0.1
-A POSTROUTING -o enp1s0 -j MASQUERADE
COMMIT
# Completed on Thu Jul 3 17:55:39 2014
# Generated by iptables-save v1.4.21 on Thu Jul 3 17:55:39 2014
*mangle
:PREROUTING ACCEPT [4512269975:1572979685485]
:INPUT ACCEPT [4125218995:1159516686786]
:FORWARD ACCEPT [194890559:164291603681]
:OUTPUT ACCEPT [1486896137:4805636977523]
:POSTROUTING ACCEPT [1682321117:4970126561191]
COMMIT
# Completed on Thu Jul 3 17:55:39 2014
# Generated by iptables-save v1.4.21 on Thu Jul 3 17:55:39 2014
*filter
:INPUT ACCEPT [951:132107]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [412383:2718876677]
-A INPUT -i lo -j ACCEPT
-A INPUT -i bond0 -j ACCEPT
-A INPUT ! -i bond0 -p udp -m udp --dport 67 -j REJECT --reject-with icmp-port-unreachable
-A INPUT ! -i bond0 -p udp -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i enp1s0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i enp1s0 -p tcp -m tcp --dport 1024 -j ACCEPT
-A INPUT -i enp1s0 -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -p udp -m udp --sport 123 --dport 123 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 32400 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32400 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32410 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32413 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32414 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32469 -j ACCEPT
-A INPUT -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A FORWARD -d 10.0.0.0/16 -i bond0 -j DROP
-A FORWARD -s 10.0.0.0/16 -i bond0 -j ACCEPT
-A FORWARD -d 10.0.0.0/16 -i enp1s0 -j ACCEPT
-A OUTPUT -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
COMMIT
# Completed on Thu Jul 3 17:55:39 2014
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13505

PostPosted: Thu Jul 03, 2014 10:40 pm    Post subject: Reply with quote

psychoteur wrote:
I've got a modem BBox 2 from my isp (belgacom - Belgium). I set DMZ on the ip of my server ( enp1s0)
enp1s0 receives fixed ip via dhcp from the box.
As I understand this, enp1s0 is your WAN interface, correct? Is bond0 connected to your LAN?
psychoteur wrote:
iptables-save:
# Generated by iptables-save v1.4.21 on Thu Jul  3 17:55:39 2014
# Generated by iptables-save v1.4.21 on Thu Jul  3 17:55:39 2014
*nat
:PREROUTING ACCEPT [433855:555438333]
:INPUT ACCEPT [2590:250086]
:OUTPUT ACCEPT [2689:542752]
:POSTROUTING ACCEPT [1327:413618]
-A PREROUTING -i enp1s0 -p udp -m udp --dport 445 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p udp -m udp --dport 137:138 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 445 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 139 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 135 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p udp -m udp --dport 13674 -j DNAT --to-destination 10.0.0.11
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 13674 -j DNAT --to-destination 10.0.0.11
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 51413 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p udp -m udp --dport 51413 -j DNAT --to-destination 10.0.0.1
-A PREROUTING -i enp1s0 -p tcp -m tcp --dport 32400 -j DNAT --to-destination 10.0.0.1
Assuming as above that enp1s0 is your WAN interface, which seems to be confirmed by your use of MASQUERADE below, then you are offering a surprising number of services to the Internet. I would not offer SMB/CIFS service to the Internet at all. As I said earlier in the thread, I dislike offering ssh service if avoidable, but it can be done with some care.
psychoteur wrote:
iptables-save:
# Generated by iptables-save v1.4.21 on Thu Jul 3 17:55:39 2014
*filter
:INPUT ACCEPT [951:132107]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [412383:2718876677]
You should use DROP for your INPUT chain as well. As written, you accept almost all traffic from anywhere. Your reject rules drop specific forms of traffic, then everything else is accepted either by a specific rule or by falling through and using the default policy of ACCEPT.
psychoteur wrote:
iptables-save:

-A INPUT ! -i bond0 -p udp -m udp --dport 67 -j REJECT --reject-with icmp-port-unreachable
-A INPUT ! -i bond0 -p udp -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable
I suggest using -j DROP here. There is little value in explicitly informing Internet users that you refuse to offer these services. If you switch the INPUT chain to default DROP, you can remove these two rules and rely on the default to drop these packets.
psychoteur wrote:
iptables-save:
-A INPUT -i enp1s0 -p tcp -m tcp --dport 1024 -j ACCEPT
-A INPUT -i enp1s0 -p tcp -m tcp --dport 8080 -j ACCEPT
Do you need to offer these services? I do not recognize port 1024. Port 8080 is popular for a variety of http-like services.
psychoteur wrote:
iptables-save:
-A INPUT -p udp -m udp --sport 123 --dport 123 -j ACCEPT
This appears to be an NTP rule, but you could get most of the value by using connection tracking instead. I suggest adding -m conntrack --ctstate ESTABLISHED to this rule, so that unsolicited NTP traffic is dropped. My suggestion assumes you are acting purely as an NTP client, rather than providing NTP service to other users.
psychoteur wrote:
iptables-save:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 32400 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32400 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32410 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32413 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32414 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 32469 -j ACCEPT
I do not know what these are. I will assume you added them on purpose for a specific application and that it only works correctly when the application can receive traffic from anywhere.
psychoteur wrote:
iptables-save:
-A FORWARD -d 10.0.0.0/16 -i enp1s0 -j ACCEPT
As I said earlier in the thread, this rule is dangerous if your upstream provider does not perform proper egress filtering. It would be safer to use connection tracking here, too.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum