# Wow, you really DO need iptables on a server...

## krovisser

I just replaced my Linksys WRT54 router with a Gentoo Box. Now my cable connection comes in on one NIC and my LAN is on another NIC. I've been wanting to do this for a while, but all the computers I had were loud, but I came across an Intel fanless mini-ITX board and a cheap newegg case for it, and a little HDParming later, it's very quiet!

Anyway, so this box has it's own domain name and does all the NAT, DHCP and DNS work, my WRT54 is just wireless AP and wired switch now, and everyday I get a couple weird people (or bots) trying to "get in". Most of the time it's just a dictionary attack on my ssh server (these people have the weirdest lists of names...), then the rest are attempts to compromise my webserver by "index.php?file=http://wear3sol33t.com/evil.php", or something similar. Good thing my index page doesn't do any GETting.

Anyway, so far, nothing's happened. I'm using that ipdrop script from gentoo.org, and check the logs every night and block anyone that gives an invalid username (There's about 2 people that use the server, and they know their usernames). I'm working on cron job that grep's all the repeat ssh failures and iptables dropped packets to block their ip's, which should be interesting.

So, I didn't think it would be bad, but I am amazed at how little time it takes for people to try and "hack" in, as much as I dislike using that word. One persons tried to get my webserver to load some "c99.txt", which was actually a php script to allow some crude shell access on the server. And, big surprise, the file was hosted on a .ru domain.

EDIT: Now, I suppose I should ask a question. How can I get my internet speed back how it was when I was using my Linksys router, 6500kbps? It's sitting at 3600 right now. It was at 1500kpbs or so until I opened up the UDP protocol for http traffic. This is using speedtest.net.

----------

## bunder

what are the specs on the gentoo router?

cheers

----------

## krovisser

 *bunder wrote:*   

> what are the specs on the gentoo router?
> 
> cheers

 

lspci:

```
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 662 Host (rev 01)

00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge)

00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] (rev 36)

00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01)

00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)

00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)

00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)

00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)

00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller

00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91)

00:05.0 IDE interface: Silicon Integrated Systems [SiS] SATA (rev 01)

00:06.0 Ethernet controller: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)

00:1f.0 PCI bridge: Silicon Integrated Systems [SiS] PCI-to-PCI bridge

01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter (rev 04)

```

It's an Intel Mini ITX board, with a 64 bit celeron at 1.2 gHz.

http://www.newegg.com/Product/Product.aspx?Item=N82E16813121326

I think it's been superseded by a newer model with a fan on the proc, but that defeats the purpose I have for it.

/proc/cpuinfo

```

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 22

model name      : Intel(R) Celeron(R) CPU          220  @ 1.20GHz

stepping        : 1

cpu MHz         : 1200.037

cache size      : 512 KB

fpu             : yes

fpu_exception   : yes

cpuid level     : 10

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm

bogomips        : 2401.75

clflush size    : 64

cache_alignment : 64

address sizes   : 36 bits physical, 48 bits virtual

power management:

```

Supports 1x2GB stick, I have 1GB on it.

Has an 80GB SATA drive for gentoo, and a 250GB IDE drive for all my media. It all barely fit into the case I got, an Apex MI-008. http://www.newegg.com/Product/Product.aspx?Item=N82E16811154091

----------

## bunder

hardware sounds more than sufficient.  how's your cabling?

could we maybe get a dump of your iptables?

----------

## krovisser

 *bunder wrote:*   

> hardware sounds more than sufficient.  how's your cabling?
> 
> could we maybe get a dump of your iptables?

 

Well, at 6800kbps, I was coming from a different room, the only noticeable difference being a twist on connection on 5-way splitter coming from the cable company's junction box. At my new location, I'm on a crimped connection (and about 20 ft. less of cable, if that makes a difference).

iptables -L -n -v

```

Chain INPUT (policy ACCEPT 4039K packets, 3517M bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DROP       all  --  *      *       221.192.199.36       0.0.0.0/0

    0     0 REJECT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpts:137:139 reject-with icmp-port-unreachable

    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:80

    0     0 REJECT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:631 reject-with icmp-port-unreachable

    1    40 REJECT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable

    0     0 REJECT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:445 reject-with icmp-port-unreachable

    1    40 REJECT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 reject-with icmp-port-unreachable

    0     0 DROP       all  --  *      *       210.70.130.6         0.0.0.0/0

    0     0 DROP       all  --  *      *       74.251.133.170       0.0.0.0/0

    0     0 DROP       all  --  *      *       36.195.149.62        0.0.0.0/0

 4515 3044K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0

  16M  667M ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0

    0     0 REJECT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:67 reject-with icmp-port-unreachable

    0     0 REJECT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 reject-with icmp-port-unreachable

30168 2836K ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22

11443  736K ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80

    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:49152

    0     0 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1900

  158  8336 DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpts:0:1023

 109K   42M DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpts:0:1023

Chain FORWARD (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DROP       all  --  *      *       221.192.199.36       0.0.0.0/0

    0     0 DROP       all  --  *      *       0.0.0.0/0            221.192.199.36

    0     0 DROP       all  --  *      *       210.70.130.6         0.0.0.0/0

    0     0 DROP       all  --  *      *       0.0.0.0/0            210.70.130.6

    0     0 DROP       all  --  *      *       74.251.133.170       0.0.0.0/0

    0     0 DROP       all  --  *      *       0.0.0.0/0            74.251.133.170

    0     0 DROP       all  --  *      *       36.195.149.62        0.0.0.0/0

    0     0 DROP       all  --  *      *       0.0.0.0/0            36.195.149.62

    6   288 DROP       all  --  eth1   *       0.0.0.0/0            192.168.0.0/16

 473K  106M ACCEPT     all  --  eth1   *       192.168.0.0/16       0.0.0.0/0

 469K  296M ACCEPT     all  --  eth0   *       0.0.0.0/0            192.168.0.0/16

Chain OUTPUT (policy ACCEPT 30M packets, 39G bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DROP       all  --  *      *       0.0.0.0/0            221.192.199.36

    0     0 DROP       all  --  *      *       0.0.0.0/0            210.70.130.6

    0     0 DROP       all  --  *      *       0.0.0.0/0            74.251.133.170

    0     0 DROP       all  --  *      *       0.0.0.0/0            36.195.149.62

```

I just retested, I'm at 4800 now. I'm starting to think that this is less and less of a hardware/software problem, and more of a neighbors usage problem. I'll try again around when I start my homework (midnight).

----------

## bunder

 *Quote:*   

> 5-way splitter coming from the cable company's junction box.

 

i don't like that, and i bet some cable installers wouldn't either.   is it possible to split them down in groups? (ie: one into two, then one of those into three and the other into two, should give 5 outputs)

splitting a coax down into five is bound to give considerable signal interference, normally evidenced by the modem dropping out randomly, high bit error rates at the modem, and fuzzy tv channels, typically from 2-20.

if it was set up that way to begin with, it might help a bit regardless.  a bad signal is never good.   :Cool: 

i'm no iptables-guru, so i'm afraid i can't help you there...  but someone here should be able to.   :Wink: 

cheers

----------

## Hu

There are already scripts to search for failed ssh attempts and ban the incoming user using iptables filtering rules.  Look up fail2ban and denyhosts.  There may be others.

I will look at the iptables rules later.  As a general hint, it is better to use iptables-save -c to dump the rules when you want to share.  It produces output that is more complete and often more readable.

----------

## krovisser

 *Hu wrote:*   

> There are already scripts to search for failed ssh attempts and ban the incoming user using iptables filtering rules.  Look up fail2ban and denyhosts.  There may be others.
> 
> I will look at the iptables rules later.  As a general hint, it is better to use iptables-save -c to dump the rules when you want to share.  It produces output that is more complete and often more readable.

 

I've taken a look at them, but I'd rather try my own to practice my scripting.

I didn't think of that, thanks.

And as for the cable splitter, I don't like them either, but that's how it was when we got here. However, I have a left over 2-way splitter that I can pop right in there since I no longer need all but two lines. I'm curious to see if it will help, I read somewhere that splitters aren't good for the signal, but I figured one 5-way was as bad as one 2-way.

----------

## DawgG

 *Quote:*   

> check the logs every night and block anyone that gives an invalid username (There's about 2 people that use the server, and they know their usernames). I'm working on cron job that grep's all the repeat ssh failures and iptables dropped packets to block their ip's, 

 

that sounds like A LOT of work for you and your box (even if it's sometimes fun to "counterhack").  :wink: 

if you only have two users why don't you make the servers listen on "unconventional" ports? this will take your services out of the aim of 99%+ of the bots. personally, i only use DROP with iptables so the attacker does not get any info from my boxes at all (well, almost none).

i used to have lot of "attacks" on the standard ports, but since i started using non-standard ports there has not been one.

i use a very old c3-epia-board with a cf/ram-disk as a firewall-box and i cannot afford to let the logs fill and stop sthe system (and i don't want to rotate them)

also, i don't think any of those "speed-tests" are very accurate.

----------

## sam_i_am

 *krovisser wrote:*   

>  I'm working on cron job that grep's all the repeat ssh failures and iptables dropped packets to block their ip's, which should be interesting.
> 
> 

 

There was a thread in Tips and Tricks forum that talked about a easy to use script. I modified it for a few of my servers and posted the mods there.

----------

## Hu

My commentary will be incomplete without seeing the rules from your other tables, but I can give you an initial analysis.

 *krovisser wrote:*   

> 
> 
> ```
> Chain INPUT (policy ACCEPT 4039K packets, 3517M bytes)
> ```
> ...

 

Prefer a default DROP policy, so that omissions do not leave holes in your firewall. *krovisser wrote:*   

> 
> 
> ```
>     0     0 REJECT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpts:137:139 reject-with icmp-port-unreachable
> ```
> ...

 

Prefer DROP over REJECT for external denial rules. *krovisser wrote:*   

> 
> 
> ```
>     0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:80
> ```
> ...

 

This rule has never been hit.  Port 80 is typically HTTP, but HTTP is TCP-based.  Why did you add this rule? *krovisser wrote:*   

> 
> 
> ```
> 30168 2836K ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
> ```
> ...

 

Consider using a limit or hashlimit match to restrict the rate at which this rule allows new traffic to arrive.  This can cripple brute force attacks without substantially impacting normal usage.  You will need a separate rule to allow ESTABLISHED connections.

 *krovisser wrote:*   

> 
> 
> ```
>  469K  296M ACCEPT     all  --  eth0   *       0.0.0.0/0            192.168.0.0/16
> ```
> ...

 

You should add rules before this one to filter out RFC1918 reserved addresses arriving on the external interface.  A conforming public ISP would not route such traffic, but many ISPs are sloppy.

You could simplify some of your blacklisting if you drop the traffic in the nat or mangle tables, so that you can cover both local connections and forwarded connections with a single rule.

----------

## Simba7

 *krovisser wrote:*   

> It's an Intel Mini ITX board, with a 64 bit celeron at 1.2 gHz.
> 
> http://www.newegg.com/Product/Product.aspx?Item=N82E16813121326

 

That's decent. Only 1 PCI slot, though? I'm running mine with Dual P3's @ 1GHz and 640MB of RAM on an Asus CUR-DLS Motherboard.

Here's my cards:

1: Blitzz BWI-715 802.11g Atheros WiFi Card

2: Kingson KNE100TX 10/100mbit PCI Card

3: Digital DE504 Quad 10/100mbit PCI Card

4: Digital DE504 Quad 10/100mbit PCI Card

5: Compaq NC3131 Dual 10/100mbit PCI-X Card

6: Intel Pro/1000 MT Dual 10/100/1000mbit PCI-X Card

7: Allied Telesyn AT-2560FX 10/100mbit Fiber PCI Card

..I'm also having to do ALOT more things than just be a router..

----------

## krovisser

 *Hu wrote:*   

> My commentary will be incomplete without seeing the rules from your other tables, but I can give you an initial analysis.
> 
> Prefer a default DROP policy, so that omissions do not leave holes in your firewall.

 

Changing it right now.

 *Quote:*   

> Prefer DROP over REJECT for external denial rules.

 

Okay, it's updated.

 *Quote:*   

> This rule has never been hit.  Port 80 is typically HTTP, but HTTP is TCP-based.  Why did you add this rule?

 

Meh, I thought HTTP traffic was TCP only, but I saw it on someone elses table and tried it. It's off now.

 *Quote:*   

> Consider using a limit or hashlimit match to restrict the rate at which this rule allows new traffic to arrive.  This can cripple brute force attacks without substantially impacting normal usage.  You will need a separate rule to allow ESTABLISHED connections.

 

Sounds like a plan. I'll look into it when I get home.

 *Quote:*   

> You should add rules before this one to filter out RFC1918 reserved addresses arriving on the external interface.  A conforming public ISP would not route such traffic, but many ISPs are sloppy.

 

I thought that was covered by the DROP rule two lines up:

```
DROP   all  --  eth1  *  0.0.0.0/0  192.168.0.0/16
```

But I'll also look into it. I suppose if I changed that to the eth0 (wan) instead of eth1 (lan) interface, it would make more sense.

 *Quote:*   

> You could simplify some of your blacklisting if you drop the traffic in the nat or mangle tables, so that you can cover both local connections and forwarded connections with a single rule.

 

I'll also look into this.

----------

## krovisser

 *Simba7 wrote:*   

>  *krovisser wrote:*   It's an Intel Mini ITX board, with a 64 bit celeron at 1.2 gHz.
> 
> http://www.newegg.com/Product/Product.aspx?Item=N82E16813121326 
> 
> That's decent. Only 1 PCI slot, though? I'm running mine with Dual P3's @ 1GHz and 640MB of RAM on an Asus CUR-DLS Motherboard.
> ...

 

What do you do that needs so many NICs? One PCI slot? It's an ITX board... and keep in mind mine is in a room where I like to watch movies/read/sleep without having hard drives thrashing and fans whirring.

----------

## krovisser

I just fixed the mess of cables at the junction on the side of the house. The previous owners had digital cable (and satellite [but didn't pay his bills...], too bad I can't reach that god awful thing on the roof) and although it was working fine with a twist-on connection and a five-way splitter, I decided to tidy up things. I remove the Arris digital cable box (which looks interesting to dissassemble), removed the five-way split, and used crimp connectors on a 2-way split.

Now my internets are at 6700kbps. As my friend would say, "There's your problem".

----------

## Hu

 *krovisser wrote:*   

> 
> 
>  *Quote:*   You should add rules before this one to filter out RFC1918 reserved addresses arriving on the external interface.  A conforming public ISP would not route such traffic, but many ISPs are sloppy. 
> 
> I thought that was covered by the DROP rule two lines up:
> ...

 

No, the rule you quote here rejects LAN traffic that goes to your gateway and then reflects back into the LAN.  Although useful, it does not achieve the goal I intended.  Changing it to eth0 would drop traffic coming from the Internet to systems on your LAN.  The idea is that traffic which comes from the Internet, but has an address claiming that it is already on your LAN is bogus, and should be dropped.  Such traffic, if permitted, could confuse your LAN systems into offering service to what they believe, based on IP address, is a trusted peer on the LAN, when in fact it is a malicious peer on the Internet.  Do this with a rule like: -i eth0 -s 192.168.0.0/16 -j DROP.  Repeat for other reserved address ranges.  Be sure to place it above the rule that accepts eth0 traffic destined for the LAN.

----------

## Anarcho

 *Hu wrote:*   

>  *krovisser wrote:*   
> 
>  *Quote:*   You should add rules before this one to filter out RFC1918 reserved addresses arriving on the external interface.  A conforming public ISP would not route such traffic, but many ISPs are sloppy. 
> 
> I thought that was covered by the DROP rule two lines up:
> ...

 

You don't need iptables for this. The kernel has a build-in check mechanism for this. You can check if it is enabled by

```
server ~ # cat /proc/sys/net/ipv4/conf/all/rp_filter 

1
```

1: enabled, 0: disabled

You can permanently enable it by adding the following lines in /etc/sysctl.conf

```
net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.all.rp_filter = 1
```

(Temparily: echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter)

BTW: It is always a better solution to just disable a serivce (or change the listining interfaces to only local ones) than hide it using iptables. A well setup server does NOT need iptables!

E.g. for ssh: Just disable password authentication and just enable public key authentication. This alone will disarm 99% of all bruteforce attacks.

A router is a different thing. Here you most probably need at least the NAT/MASQUERADING from iptables.

----------

## Hu

 *Anarcho wrote:*   

> You don't need iptables for this. The kernel has a build-in check mechanism for this. You can check if it is enabled by
> 
> ```
> server ~ # cat /proc/sys/net/ipv4/conf/all/rp_filter 
> 
> ...

 

In principle, I agree.  However, this splits policy enforcement between the routing rules and the firewall rules.  More importantly, your solution assumes that every reserved address is routed via an internal interface.  Most home users have only a tiny subsection of the RFC1918 reserved address space routed to their internal interface.  The rest of those addresses will use the default interface, and try to go out the external interface.

----------

## Anarcho

 *Hu wrote:*   

>  *Anarcho wrote:*   You don't need iptables for this. The kernel has a build-in check mechanism for this. You can check if it is enabled by
> 
> ```
> server ~ # cat /proc/sys/net/ipv4/conf/all/rp_filter 
> 
> ...

 

Thats true and there were already a discussion on the mailinglist to move this functionality into netfilter. But for the moment it is part of the routing settings.

 *Hu wrote:*   

> More importantly, your solution assumes that every reserved address is routed via an internal interface.  Most home users have only a tiny subsection of the RFC1918 reserved address space routed to their internal interface.  The rest of those addresses will use the default interface, and try to go out the external interface.

 

Could you give me an example where this would be critical as I don't fully understand your concern? Maybe I add some rules to my iptables script then.

----------

## Hu

 *Anarcho wrote:*   

>  *Hu wrote:*   More importantly, your solution assumes that every reserved address is routed via an internal interface.  Most home users have only a tiny subsection of the RFC1918 reserved address space routed to their internal interface.  The rest of those addresses will use the default interface, and try to go out the external interface. 
> 
> Could you give me an example where this would be critical as I don't fully understand your concern? Maybe I add some rules to my iptables script then.

 

Consider the typical home network: Gentoo machine dual-homed with a WAN IP address and 192.168.0.1 as the LAN IP address, with a netmask of 255.255.255.0.  This means that traffic to 192.168.1.2 does not match the LAN route, and so would be sent to the WAN by default.

As a related attack, you should place a rule in the PREROUTING chain in the nat table to disallow NEW traffic which arrives with its destination IP address already set to an RFC1918 reserved address.  In the context of the PREROUTING chain considering NEW traffic, the destination IP match uses the value from the IP header, before considering any rewrites caused by DNAT rules or connection tracking.

----------

## think4urs11

 *Hu wrote:*   

> This means that traffic to 192.168.1.2 does not match the LAN route, and so would be sent to the WAN by default.

 

...and should be dropped by the upstream router. At least as long as we're talking about ISPs which do proper ingress and egress filtering.

So basically we do egress filtering on our side as we don't trust the ingress filters on ISP side. Not directly/solely a security thing, more of a bw-saver as traffic which can/will not be handled (correctly) upstream anyways will not leave our premises.

Annother option which doesn't need iptables but getting similar results would be a blackhole route to a non-existant ip in our own network for destinations 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

Iptables is only really needed on the gateway and should drop all traffic coming in via WAN-Interface with Dest.IP set to != our WAN IP (typical home setup with one IP given by the ISP and NAT in use on our GW).

----------

## Simba7

 *krovisser wrote:*   

> What do you do that needs so many NICs? One PCI slot? It's an ITX board... and keep in mind mine is in a room where I like to watch movies/read/sleep without having hard drives thrashing and fans whirring.

 

That's why it's in the "Server room" (actually, in the basement). Along with 4 other servers. My "Media Center" actually connects to the network and fetches the files from the "Server room".

Why I have so many cards? Well, it acts like a Wireless and a Wired Router as well as a load balancer.

The BWI-715 acts as "Master Mode" with a DHCP server attached to it (My Access Point), The pair of DE504's are for Internet connectivity (Overkill, yes.. But hey.. They were dirt cheap) and the Dual Intel Pro/1000 is for the local network.

As for the NC3131, the KNE100TX, I'm not sure as of right now. The AT-2560FX will be for a fiber drop in the future.

I have it setup to load balance across the DE504's (if I *EVER* fill them up). That's 8 ports and so far, I'm using 1 (soon 2).

The router also acts as a Cacti, Squid and OpenVPN server so I can monitor the ENTIRE network, cache part of the Internet locally, and allow my laptop access to the network securely when I'm away.

----------

## Anarcho

 *Think4UrS11 wrote:*   

>  *Hu wrote:*   This means that traffic to 192.168.1.2 does not match the LAN route, and so would be sent to the WAN by default. 
> 
> ...and should be dropped by the upstream router. At least as long as we're talking about ISPs which do proper ingress and egress filtering.
> 
> So basically we do egress filtering on our side as we don't trust the ingress filters on ISP side. Not directly/solely a security thing, more of a bw-saver as traffic which can/will not be handled (correctly) upstream anyways will not leave our premises.
> ...

 

That's exactly what I was thinking about. Besides the bandwith beeing used to the next router by the ISP there is no critical thing about source IP faking for networks that are not connected to the router. On the other side iptables may have a bug which could be exploited by an attacker.

In general it is always better for security to reduce complexity.

----------

## Hu

 *Think4UrS11 wrote:*   

>  *Hu wrote:*   This means that traffic to 192.168.1.2 does not match the LAN route, and so would be sent to the WAN by default. 
> 
> ...and should be dropped by the upstream router. At least as long as we're talking about ISPs which do proper ingress and egress filtering.

 

I have seen reserved addresses sending ICMP echo requests to me via my WAN connection.  Therefore, I cannot trust my ISP to filter things properly, so I write my ingress and egress filters to be paranoid.  As far as I know, I lose nothing by doing this, so I encourage others to do the same, in case they run into a similarly negligent ISP.

----------

## think4urs11

 *Hu wrote:*   

> As far as I know, I lose nothing by doing this, so I encourage others to do the same, in case they run into a similarly negligent ISP.

 

You only add a bit of complexity to your setup which can be acceptable.

Hopefully you're not only filtering based on RFC1918 but RFC3330? Or if we're talking about real paranoid setups i'd implement filters for RFC330 + all bogons (unallocated IP's in internet), as listed e.g. here: http://www.cidr-report.org/bogons/freespace-prefix.txt

But still this is no 'must' for a server, it is a 'should' for a gateway.

----------

## Hu

 *Think4UrS11 wrote:*   

> 
> 
> Hopefully you're not only filtering based on RFC1918 but RFC3330? Or if we're talking about real paranoid setups i'd implement filters for RFC330 + all bogons (unallocated IP's in internet), as listed e.g. here: http://www.cidr-report.org/bogons/freespace-prefix.txt

 

Yes.  However, my primary concern when posting firewall advice here is that internal applications that expect reserved addresses to be used only by trusted peers on the internal network can rely on that assumption.  Recommending the older RFC1918 block covers that, and avoids going into explanations of which categories in RFC3330 should or should not be added to filtering rules.  I do not advocate that new users filter bogons, since that would require more active attention to when such addresses are assigned and cease being bogus.  On the off chance that a bogon gets assigned to a service used by that user, he could suddenly lose access to it.  I do not mind monitoring bogons on the filters I administer, but I would prefer not to put other people in a situation where they must actively maintain a list of filtered addresses.  :Smile:   I have never heard of any incident where an attacker spoofing a bogon address had an advantage over an attacker using a valid IP address.  I could start mentioning bogons so that the more active firewall administrators can pick it up if they are interested.  Most users do not seem that active, so I try for a configuration that lets people prepare the firewall and then forget about it.

 *Think4UrS11 wrote:*   

> But still this is no 'must' for a server, it is a 'should' for a gateway.

 

True.  The original poster seemed to be using his Gentoo machine as both a gateway and a server, so I treated it as a gateway to a hostile network with potentially negligent filtering by the upstream administrator.  This is safer and not significantly more work once he had decided to use a packet filter at all.

----------

## think4urs11

 *Hu wrote:*   

> so I try for a configuration that lets people prepare the firewall and then forget about it.

 

As we both seem to know this is the wrong approach on the long(er) run. Better not support bad habits from the start and get people aware about (firewall) security beeing no 'set and forget'-thingie which works out of the box and needs no attendance afterwards.

OTOH bogon-filters are of course really advanced paranoia; i'm yet to see something like that on a corporate production firewall  :Wink: 

----------

