# About home router wiki

## psychoteur

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 ...

----------

## windex

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:

```
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:

```
 -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!

```

```

```

```

```

```

```

```

```

```

```

```

```

```

----------

## Hu

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.

----------

## windex

 *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

----------

## psychoteur

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  :Wink: 

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

----------

## Hu

 *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:*   

> 
> 
> ```
> # Generated by iptables-save v1.4.21 on Thu Jul  3 17:55:39 2014
> 
> ...

 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:*   

> 
> 
> ```
> # Generated by iptables-save v1.4.21 on Thu Jul 3 17:55:39 2014
> 
> ...

 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:*   

> 
> 
> ```
> 
> -A INPUT ! -i bond0 -p udp -m udp --dport 67 -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:*   

> 
> 
> ```
> -A INPUT -i enp1s0 -p tcp -m tcp --dport 1024 -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:*   

> 
> 
> ```
> -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:*   

> 
> 
> ```
> -A INPUT -p tcp -m state --state NEW -m tcp --dport 32400 -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:*   

> 
> 
> ```
> -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.

----------

