Decent iptables script

[Gordon]

My bad; won't do it again.

Still something good has come out of this. I learned some new Swedish words and am intrigued by surströmming. Should definitely try to get my hands on some.

[johannes]

My bad; won't do it again.

Still something good has come out of this. I learned some new Swedish words and am intrigued by surströmming. Should definitely try to get my hands on some.

No worries, h*core can mean many things. It was added to the list a long time ago when this forum was full of gargamell spam. And well, hmm, surströmming can be an experience, you should try it.

Did you guys agree on a feature request here, that I should add to my list? I briefly read up on shorewall, but coming from a hardware background I can't say i understand the benefits for users other than the tech savvy like you, who would take advantage of the under-the-hood capabilities. Do I misunderstand? I mean, iptables is doing a good job as it is now, right? (Apart from the braindead scripts then, but that's not really iptables fault).

[Gordon]

Did you guys agree on a feature request here, that I should add to my list? I briefly read up on shorewall, but coming from a hardware background I can't say i understand the benefits for users other than the tech savvy like you, who would take advantage of the under-the-hood capabilities. Do I misunderstand? I mean, iptables is doing a good job as it is now, right? (Apart from the braindead scripts then, but that's not really iptables fault).

Shorewall is still iptables.

Consider a simple setup for the B3. We have a logical LAN interface br0 and we name the network connected to it "local". We are connected to the internet on interface eth0, so we'll name this "internet". The B3 needs a name as well and we'll call it "bubba". Using these names (they're called zones) you can identify directions in which a packet travels and Shorewall will create user tables for each of them (at least the old version did - the current version will only create user tables that will have meaningful content). The autogenerated result for the INPUT table will then look like this:

Code: Select all

~ # iptables -S INPUT
-P INPUT DROP
-A INPUT -m conntrack --ctstate INVALID,NEW -j dynamic
-A INPUT -i br0 -j local2bubba
-A INPUT -i eth0 -j internet2bubba
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j Reject
-A INPUT -g reject

See what happens here? We now have separate tables for incoming traffic on the two interfaces and we can manage both of them individually without influencing the other one. Compare the result of the following two commands if you were to enter these when connected through SSH (don't!):

Code: Select all

~ # iptables -I INPUT 1 -p tcp -m tcp --dport 22 -j DROP

Code: Select all

~ # iptables -I internet2bubba 1 -p tcp -m tcp --dport 22 -j DROP

The first one will shut you out completely, whereas the second one does not change your possibility to access SSH on the LAN port (of course if you disabled that before, you'll still be completely locked out )

[johannes]

@Gordon, thanks for explaining the benefits, this makes it clearer. For B3 I'd say that a public upgrade isn't doable, it's too risky business making those changes on peoples running firewalls. However, it's now on my list and we'll consider it for future products.

@Ubi, regarding the save-on-shutdown it appears to be unneccessary, and I have scheduled it for removal in the 2.5 release. Thanks for pointing it out!

[Ubi]

thanks,

as for the shorewall thing, I think it adds stability and functionality to the B3, and is probably a good decision in the long run from a business perspective. AFAICT it can be developed as a package and applied on top of a current B3 setup. After this it may replace the current iptables setup.

[Ubi]

Apart from all this. replacing my firewall.conf with those supplied does not yield me a functional system
Please tell me I don't need to re-install just for a borked iptables script?

:EDIT: crap, it *does* come up, but only if I connect it to my network over the WAN port, which of course does not give admin access to the web-config.

:EDIT2: is there an easy way from command to set it in that mode (i forgot the name) where it connects to DHCProuter over the LAN port (the middle one), but still acts as a router on the Wifi?

tnx

[Gordon]

If you have SSH you can try the following:

On the B3:

Code: Select all

ip route replace [WAN-net] dev eth0 src [LAN-IP]

On the Windows workstation:

Code: Select all

route add [B3-LAN-IP] mask 255.255.255.255 [B3-WAN-IP]

This should enable you to access the admin page by accessing [B3-LAN-IP] with your web browser.

[Ubi]

Well I figures I may be still able to connect to the admin pages via wifi instead, which I could, but then I wanted to reset the server settings by putting it to "WAN + firewall + something" and then my Wifi died, never to be heard from again.

I can't believe I spent three evenings already on this shit just because of one bloody typo.

[Ubi]

No, the wifi seems to be lost. No connectivity even if I place my laptop next to the B3.

I'm sure its a router thing, but I never really understood the fine details of lowlevel routing, especially when it comes to bridges. Here's my ifconfig

Code: Select all

br0       Link encap:Ethernet  HWaddr 00:0b:6b:7d:5c:47
          inet addr:192.168.0.20  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20b:6bff:fe7d:5c47/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:12151 (11.8 KiB)

eth0      Link encap:Ethernet  HWaddr 00:22:02:00:15:12
          inet addr:192.168.1.96  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::222:2ff:fe00:1512/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:12077 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9169 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1478804 (1.4 MiB)  TX bytes:3145404 (2.9 MiB)
          Interrupt:11

eth1      Link encap:Ethernet  HWaddr 00:22:02:00:15:13
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:311 errors:0 dropped:0 overruns:0 frame:0
          TX packets:315 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:39041 (38.1 KiB)  TX bytes:58756 (57.3 KiB)
          Interrupt:15

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:52 errors:0 dropped:0 overruns:0 frame:0
          TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5700 (5.5 KiB)  TX bytes:5700 (5.5 KiB)

mon.wlan0 Link encap:UNSPEC  HWaddr 00-0B-6B-7D-5C-47-01-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:820 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:58238 (56.8 KiB)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:0b:6b:7d:5c:47
          inet6 addr: fe80::20b:6bff:fe7d:5c47/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:159 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1070 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:23647 (23.0 KiB)  TX bytes:265306 (259.0 KiB)

my interaces script

Code: Select all

iface br0 inet static
        address 192.168.0.20
        bridge_fd 0
        bridge_maxwait 0
        bridge_ports eth1 wlan0
        netmask 255.255.255.0

iface eth0 inet dhcp

auto lo
iface lo inet loopback

and my firewall script

Code: Select all

# Generated by iptables-save v1.4.8 on Sat Nov 19 20:56:43 2011
*filter
:INPUT DROP [86:21538]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [763:115391]
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -m icmp --icmp-type 3/4 -j ACCEPT
COMMIT
# Completed on Sat Nov 19 20:56:43 2011
# Generated by iptables-save v1.4.8 on Sat Nov 19 20:56:43 2011
*nat
:PREROUTING ACCEPT [11:858]
:INPUT ACCEPT [6:698]
:OUTPUT ACCEPT [23:3136]
:POSTROUTING ACCEPT [6:2158]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Nov 19 20:56:43 2011

the setup that I had before I reset iptables was a fixed IP on the LAN interface, no use of the WAN interface, and a dhcp router on the wifi bridge. How it's possible that all this disappeared upon resetting some INPUT rules in iptables i don't know, but debugging routing issues without a console is a PITA. If anyone can spot the problem in these scripts please let me know.

thanks

[Ubi]

@gordon: sorry did not work.

[Gordon]

@gordon: sorry did not work.

Strange, it should have.

But your firewall script is wrong. I'm guessing this one belongs to B2 or B3 withouth WiFi since it has a rule for eth1, but this interface doesn't have an IP of its own since it's paired with wlan0 to form bridge br0. It's the bridge interface to which the IP is assigned and that's the one that should be in your firewall script, not eth1.

[Ubi]

You mean the INPUT -i eth0 -j accept?
I added the eth1 hoping *something* would improve

EDIT: I dunno but the thing is now completely unreachable on any nic. I'll just turn the thing off and hope someone will post the correct settings for a B3 with wifi.

thanks for all the help

[Gordon]

You mean the INPUT -i eth0 -j accept?
I added the eth1 hoping *something* would improve

Nope. eth0 is the WAN interface. You need to add br0 for LAN (and wireless) access. Adding eth1 does nothing.

[Ubi]

ah yeah, i meant that... *dumb*

Kinda weird: the last time i did a ifdown br0; ifup br0 it started looking for a dhcp server, even though there is no mention of dhcp in interfaces for br0 or eth1.

[Gordon]

ah yeah, i meant that... *dumb*

Kinda weird: the last time i did a ifdown br0; ifup br0 it started looking for a dhcp server, even though there is no mention of dhcp in interfaces for br0 or eth1.

I recognize that. Can be quite confusing and I am currently struggling with a rather important server at work with just this particular issue.

Thing with Linux is that at one point you (think you) know stuff and then the next moment you feel like you're some kind of blabbering idiot. So here's the way I get this: there are two main methods for configuring networking. The corresponding commands for these are 'ifconfig' and 'ip'. The confusing thing is that the newer 'ip' command (which is the one used for the B3) also implements the ifup/ifdown methods, but if you're actually executing ifup/ifdown you're calling on ifconfig. Since ifconfig is not aware of the configuration used by 'ip', it doesn't recognize the static configuration of br0 and defaults to dhcp client mode.