# Do these iptables rules look right?

## FcukThisGame

This is my first time using iptables, so I don't have anything to compare my current configs to. I use a script to write my iptables rules. Here's the script:

```
#!/bin/bash

# /etc/scripts/reset-iptables-rules.sh

# This script flushes current iptables rules, creates new ones as specified below, then saves them.

# First we flush our current rules

iptables -F

iptables -X

iptables -t nat -F

# Setup default policies to handle unmatched traffic

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

# export interface variables

export LAN1=eth1

export LAN2=eth2

export WAN=eth3

# Lock services so they only work from the LAN

#iptables -I INPUT 1 -i ${LAN1} -j ACCEPT

iptables -I INPUT 1 -i ${LAN2} -j ACCEPT

iptables -I INPUT 1 -i lo -j ACCEPT

#iptables -A INPUT -p UDP --dport bootps ! -i ${LAN1} -j REJECT

#iptables -A INPUT -p UDP --dport domain ! -i ${LAN1} -j REJECT

iptables -A INPUT -p UDP --dport bootps ! -i ${LAN2} -j REJECT

iptables -A INPUT -p UDP --dport domain ! -i ${LAN2} -j REJECT

# Allow access to ssh server from the WAN

iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT

iptables -A INPUT -p TCP --dport ssh -i ${LAN1} -j ACCEPT

iptables -A INPUT -p TCP --dport ssh -i ${LAN2} -j ACCEPT

# Drop TCP / UDP packets to privileged ports

#iptables -A INPUT -p TCP ! -i ${LAN1} -d 0/0 --dport 0:1023 -j DROP

#iptables -A INPUT -p UDP ! -i ${LAN1} -d 0/0 --dport 0:1023 -j DROP

iptables -A INPUT -p TCP ! -i ${LAN2} -d 0/0 --dport 0:1023 -j DROP

iptables -A INPUT -p UDP ! -i ${LAN2} -d 0/0 --dport 0:1023 -j DROP

# NAT (for internet access)

iptables -A FORWARD -i ${LAN1} -o ${WAN} -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i ${LAN2} -o ${WAN} -m state --state NEW,ESTABLISHED -j ACCEPT

# Rules for NAT 

   #eth1, 10.1.1.X (My room)

#iptables -I FORWARD -i ${LAN1} -d 192.168.1.0/255.255.255.0 -j DROP

#iptables -A FORWARD -i ${LAN1} -s 192.168.1.0/255.255.255.0 -j ACCEPT

   #eth2 vlan1, 10.1.2.X (Roommate's room)

iptables -I FORWARD -i ${LAN2} -d 192.168.2.0/255.255.255.0 -j DROP

iptables -A FORWARD -i ${LAN2} -s 192.168.2.0/255.255.255.0 -j ACCEPT

   #eth2 vlan2, 10.1.3.X (Living room)

iptables -I FORWARD -i ${LAN2} -d 192.168.3.0/255.255.255.0 -j DROP

iptables -A FORWARD -i ${LAN2} -s 192.168.3.0/255.255.255.0 -j ACCEPT

   #eth2 vlan3, 10.1.4.X (Home Wireless)

iptables -I FORWARD -i ${LAN2} -d 192.168.4.0/255.255.255.0 -j DROP

iptables -A FORWARD -i ${LAN2} -s 192.168.4.0/255.255.255.0 -j ACCEPT

   #eth2 vlan4, 10.1.5.X (Guest Wireless)

iptables -I FORWARD -i ${LAN2} -d 192.168.5.0/255.255.255.0 -j DROP

iptables -A FORWARD -i ${LAN2} -s 192.168.5.0/255.255.255.0 -j ACCEPT

iptables -A FORWARD -i ${WAN} -d 192.168.0.0/255.255.0.0 -j ACCEPT

iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

# DNS rules

iptables -A INPUT -p udp --sport 53 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p udp --dport 53 -j ACCEPT

iptables -A INPUT -p tcp --sport 53 -j ACCEPT

iptables -A INPUT -p tcp --dport 53 -j ACCEPT

# Port forwarding

# (haven't done this yet)

# Save that shit!

/etc/init.d/iptables save
```

The other day I had to manually add rules for internal ssh access. I'd set it externally, but internally it didn't work until i explicitly told it to. Can someone point me at the rule that's causing that? Or is internal traffic like ssh rejected by default??

EDIT: You can ignore everything about LAN2. It's not in use yet.

----------

## d2_racing

Hi, first you need to think like a sysadmin  :Razz: 

```

# Setup default policies to handle unmatched traffic

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

```

Should be like this instead :

```

iptables -P INPUT DROP

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

```

Protect your box by default and then let only exit or enter the trafic that you want.Last edited by d2_racing on Wed Oct 20, 2010 1:03 am; edited 1 time in total

----------

## d2_racing

You should  protect all your interface with that :

```

$iptables -A INPUT -p ALL  -m state --state ESTABLISHED,RELATED -j ACCEPT

$ptables -A INPUT -i $WAN  -p TCP --dport ssh  -j ACCEPT 

```

With that, you limit your ssh access over the net and you protect your trafic from a lot of ports knocking.

Since, nmap and other scanner will initialize a NEW connection each time.

----------

## d2_racing

```

iptables -F

iptables -X

iptables -t nat -F

iptables -P INPUT DROP

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP

# export interface variables

export LAN1=eth1

export WAN=eth3

export lo=127.0.0.1

iptables -A INPUT -i $lo -j ACCEPT

#protect your WAN interface

iptables -A INPUT -p all -i $WAN -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow access to ssh server from the WAN

iptables -A INPUT -p TCP --dport ssh -i $WAN -m state --state NEW -j ACCEPT

# Forward your valid trafic from your WAN interface

iptables -A FORWARD -p all -i $WAN -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -p TCP --dport ssh -i $WAN -j ACCEPT 

# NAT to the outside

iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE

# NAT to the outside

iptables -A FORWARD -i $LAN1 -o $WAN  -j ACCEPT

```

Do you use your own dns server ?

----------

## FcukThisGame

 *d2_racing wrote:*   

> Do you use your own dns server ?

 

Yes, on the same box. Bind for DNS and dhcpd for DHCP.

Got those iptables rules from the Gentoo Bind guide.

...DNS isn't working though. See a couple posts down "DNS not working with bind".

----------

## d2_racing

Did you try this :

```

iptables -A INPUT -p tcp --dport 53 -i $WAN   -j ACCEPT

iptables -A INPUT -p udp --dport 53 -i $WAN  -j ACCEPT

```

----------

## d2_racing

I never builded a gateway firewall, so basically I never needed to use the forward statement.

I hope to learn a lot from that thread.

----------

## FcukThisGame

 *d2_racing wrote:*   

> Did you try this :
> 
> ```
> 
> iptables -A INPUT -p tcp --dport 53 -i $WAN   -j ACCEPT
> ...

 

Just edited my last post, sorry about that. I've already got those lines in my script. My current issue with DNS is something bind related, I can't start /etc/init.d/named.

----------

## floppymaster

```
iptables -A INPUT -p TCP ! -i ${LAN2} -d 0/0 --dport 0:1023 -j DROP
```

This rule says: If the protocol is TCP, and the interface is NOT $LAN2, and the destination port is between 0 and 1023, drop the packet. SSH (port 22/tcp) coming in $LAN1 meets all of those criteria.

----------

## floppymaster

Here is my ruleset (annotated) in case it helps you with your's. This is output from iptables-save, so it is a little different in appearance from your shell script.

```
# Generated by iptables-save v1.4.4 on Wed Jul 14 00:32:37 2010

*filter

:INPUT DROP [424090:107341410]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [731532:98249799]

:UPNP_FORWARD - [0:0]

# Accept any established connection

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

# Allow anything over loopback

-A INPUT -i lo -j ACCEPT 

# Allow anything over eth1 (LAN)

-A INPUT -i eth1 -j ACCEPT 

# Allow anything over the tunnel to the office (tun0)

-A INPUT -i tun0 -j ACCEPT 

# Allow internet SSH access on a non-standard port

-A INPUT -i eth0 -p tcp -m tcp --dport 5022 -j ACCEPT 

# Allow internet access to OpenVPN running on this server

-A INPUT -i eth0 -p udp -m udp --dport 1194 -j ACCEPT 

# Allow the internet to "ping" me

-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -j ACCEPT 

# Reject IDENT requests; makes IRC connect faster

-A INPUT -i eth0 -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset 

# Forward any esablished connection

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 

# Forward anything originating from the LAN

-A FORWARD -i eth1 -j ACCEPT 

# Port forwarding for Bittorrent

-A FORWARD -d 192.168.0.4/32 -i eth0 -p tcp -m tcp --dport 30000:30009 -j ACCEPT 

-A FORWARD -d 192.168.0.4/32 -i eth0 -p udp -m udp --dport 30000:30009 -j ACCEPT 

-A FORWARD -d 192.168.0.4/32 -i eth0 -p udp -m udp --dport 49001 -j ACCEPT 

# Port forward ssh to my workstation

-A FORWARD -d 192.168.0.4/32 -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT 

# Special chain for upnpd dynamic port forwards

-A FORWARD -j UPNP_FORWARD 

COMMIT

# Completed on Wed Jul 14 00:32:37 2010

# Generated by iptables-save v1.4.4 on Wed Jul 14 00:32:37 2010

*nat

:PREROUTING ACCEPT [3728860:410648410]

:POSTROUTING ACCEPT [13485680:1620310482]

:OUTPUT ACCEPT [337447:30247479]

:UPNP_PREROUTING - [0:0]

# Port forward for Bittorrent

-A PREROUTING -i eth0 -p tcp -m tcp --dport 30000:30009 -j DNAT --to-destination 192.168.0.4 

-A PREROUTING -i eth0 -p udp -m udp --dport 30000:30009 -j DNAT --to-destination 192.168.0.4 

-A PREROUTING -i eth0 -p udp -m udp --dport 49001 -j DNAT --to-destination 192.168.0.4 

# Port forward ssh to my workstation (note the port number change from 4022 to 22)

-A PREROUTING -i eth0 -p tcp -m tcp --dport 4022 -j DNAT --to-destination 192.168.0.4:22 

# UPNP chain

-A PREROUTING -j UPNP_PREROUTING 

# Magic SNAT rule

-A POSTROUTING -o eth0 -j MASQUERADE 

COMMIT

# Completed on Wed Jul 14 00:32:38 2010
```

----------

## FcukThisGame

 *floppymaster wrote:*   

> 
> 
> ```
> iptables -A INPUT -p TCP ! -i ${LAN2} -d 0/0 --dport 0:1023 -j DROP
> ```
> ...

 

I don't currently have any issue with ssh, internal or external.

If you have two conflicting iptables rules, does the most recent one take precedence?

----------

## floppymaster

iptables processes rules in order, and stops processing as soon as it hits a "terminal" jump target. Terminal jump targets include ACCEPT, DROP, REJECT, and several others.

----------

## cach0rr0

it would be much easier to have a default DROP on each chain at the tail end of your rulesets, and beforehand explicitly ACCEPT certain ports. 

I'll try to prune my ruleset for a quickie example - hope it's useful

```

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

#you probably don't want to DROP your FORWARD stuff

iptables -P FORWARD DROP

#you dont need these next three really, i do it for readability in logs

iptables -N LOGDROP

iptables -A LOGDROP -j LOG --log-level debug --log-prefix "[DROPPED] - "

iptables -A LOGDROP -j DROP

# check connection state and allow already-initiated connections to proceed

# if that makes sense

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# allow loopback

iptables -A INPUT -i lo -j ACCEPT

# allow all on LAN port

iptables -A INPUT -i eth1 -j ACCEPT 

# allow these and drop everything else but these

iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT

#denoising drops from logs by nuking dhcp

iptables -A INPUT -i eth0 -p udp --dport 67 -j DROP

#halfassed attempt at thwarting slowloris

#dont need this if you're not running a web server. 

iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 100 -j DROP

iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 100 -j DROP

#final 'drop everything else' rule

#anything not explicitly allowed before this for eth0 is dropped (and logged)

iptables -A INPUT -i eth0 -j LOGDROP

```

----------

## d2_racing

@floppymaster, can you explain me this :

```

# Allow internet SSH access on a non-standard port

-A INPUT -i eth0 -p tcp -m tcp --dport 5022 -j ACCEPT 

# Port forward ssh to my workstation

-A FORWARD -d 192.168.0.4/32 -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT

# Port forward ssh to my workstation (note the port number change from 4022 to 22)

-A PREROUTING -i eth0 -p tcp -m tcp --dport 4022 -j DNAT --to-destination 192.168.0.4:22

```

Your INPUT rules says that everything that hit your WAN interface on port 5022, you accept it. It's your ssh input port.

And I see that you have a forward statement that says that everything is forwarded is the destination is 192.168.0.4 on port 22.

This rule will work if you have a box inside your lan and you want to ssh to an another box inside your lan.

So basically, if you are at work, you won't be able to ssh your box at home, since your 5022 will not be route to your 192.168.0.4:22, since you use the 5022 from outside and your prerouting statement dnat the port 4022.

Am I right, or I off the track ?

Thanks !

----------

## floppymaster

d2_racing:

I suppose that might be a bit confusing. I'm actually allowing SSH access to two separate hosts on different ports. Here are some better comments:

```
# Allow internet SSH access to myself (the firewall box) on a non-standard port; sshd is listening on 5022

-A INPUT -i eth0 -p tcp -m tcp --dport 5022 -j ACCEPT 

# Port forward ssh to my workstation (note the port number change from 4022 to 22) 

-A PREROUTING -i eth0 -p tcp -m tcp --dport 4022 -j DNAT --to-destination 192.168.0.4:22 

# Let the ssh port forward through to my workstation 

-A FORWARD -d 192.168.0.4/32 -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
```

So, if I connect from anywhere on the internet to my public ip on port 5022, I get SSH access to the firewall. If I connect to port 4022, I get SSH access to my workstation, sitting behind the firewall.

----------

## floppymaster

cach0rr0:

```
#you dont need these next three really, i do it for readability in logs 

iptables -N LOGDROP 

iptables -A LOGDROP -j LOG --log-level debug --log-prefix "[DROPPED] - " 

iptables -A LOGDROP -j DROP
```

That's pretty slick -- I might borrow that.

----------

## d2_racing

 *floppymaster wrote:*   

> So, if I connect from anywhere on the internet to my public ip on port 5022, I get SSH access to the firewall. If I connect to port 4022, I get SSH access to my workstation, sitting behind the firewall.

 

Ok I see, man you know what you are doing  :Razz: 

I didn't see that the first time that I checked your script.

----------

## d2_racing

@floppymaster, how did you setup your internal dhcp ?

I see that you have this rule :

```

-A POSTROUTING -o eth0 -j MASQUERADE

```

So, I assume that you have a dhcp configuration.

And how do you handle the dns trafic ?

----------

## d2_racing

One more question for you my friend floppymaster:

```

-A FORWARD -d 192.168.0.4/32 -i eth0 -p tcp -m tcp --dport 30000:30009 -j ACCEPT

-A FORWARD -d 192.168.0.4/32 -i eth0 -p udp -m udp --dport 30000:30009 -j ACCEPT

-A FORWARD -d 192.168.0.4/32 -i eth0 -p udp -m udp --dport 49001 -j ACCEPT

```

About your firewall input statement :

You only need to add the forward statement that is use by your firewall box to route the trafic to the right network.

And your firewall will automagically accept these connections because of that line :

```
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
```

Since, one of the computers on your lan sended a connection over the net, so when the firewall receive a packet, it will be tag as RELATED or ESTABLISHED.

Is that right, because I think that you cannot receive a NEW connection from a bittorent....

About the 192.168.0.4/32, what does that mean ?

Finally, what is a tun interface ?

```

# Allow anything over the tunnel to the office (tun0)

-A INPUT -i tun0 -j ACCEPT 

```

Thanks again  :Razz: 

----------

## mv

 *cach0rr0 wrote:*   

> it would be much easier to have a default DROP on each chain at the tail end of your rulesets, and beforehand explicitly ACCEPT certain ports.

 

It is a bad habbit to not send proper REJECT packages back: This is non-conformal behavior and can lead to unnecessary retries from the other side. I would recommend to DROP only unknown protocols but properly REJECT known protocols (with a hashlimit to avoid DOS-attackers).

----------

## floppymaster

 *d2_racing wrote:*   

> @floppymaster, how did you setup your internal dhcp ?
> 
> And how do you handle the dns trafic ?

 

I actually have both dhcpd and bind (DNS server) running on my firewall box. There are many tutorials for setting both of these up, but if you have any specific questions let me know.

Note that my LAN is allowed unrestricted internet access by virtue of these rules:

```
# Forward anything originating from the LAN 

-A FORWARD -i eth1 -j ACCEPT

# Magic SNAT rule 

-A POSTROUTING -o eth0 -j MASQUERADE
```

If I wanted to configure my LAN to use an external DNS server, that would not be a problem.

----------

## floppymaster

Also, in case it isn't clear: My firewall box is both a DHCP server and a client.

dhcpd listens on eth1 and hands out addresses to my LAN.

dhclient configures eth0 and grabs a public IP from my ISP.

----------

## floppymaster

 *Quote:*   

> Is that right, because I think that you cannot receive a NEW connection from a bittorent.... 
> 
> About the 192.168.0.4/32, what does that mean ? 
> 
> Finally, what is a tun interface ?

 

The relevant rules for bittorrent are these:

```
# Forward any established connection 

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 

# Forward anything originating from the LAN 

-A FORWARD -i eth1 -j ACCEPT 

# Port forward for Bittorrent 

-A PREROUTING -i eth0 -p tcp -m tcp --dport 30000:30009 -j DNAT --to-destination 192.168.0.4 

-A PREROUTING -i eth0 -p udp -m udp --dport 30000:30009 -j DNAT --to-destination 192.168.0.4 

-A PREROUTING -i eth0 -p udp -m udp --dport 49001 -j DNAT --to-destination 192.168.0.4 

# Port forwarding for Bittorrent 

-A FORWARD -d 192.168.0.4/32 -i eth0 -p tcp -m tcp --dport 30000:30009 -j ACCEPT 

-A FORWARD -d 192.168.0.4/32 -i eth0 -p udp -m udp --dport 30000:30009 -j ACCEPT 

-A FORWARD -d 192.168.0.4/32 -i eth0 -p udp -m udp --dport 49001 -j ACCEPT
```

The first two rules allow outgoing bittorrent connections. The last 6 allow incoming connections.

192.168.0.4 is the static IP address assigned to my workstation. The /32 tells iptables to filter using the full address, rather than a partial (network) address. If I specified 192.168.0.4/24, it would allow traffic to any IP in the range 192.168.0.0 to 192.168.0.255.

A tun interface is a virtual network interface that the OpenVPN software uses. VPNs are a little out of scope for this discussion.  :Smile: 

----------

## d2_racing

```

# Allow anything over the tunnel to the office (tun0)

-A INPUT -i tun0 -j ACCEPT 

```

What are you doing with that interface ?

The tun0 refer to a ssh tunnel or something else ?

----------

## floppymaster

 *mv wrote:*   

> It is a bad habbit to not send proper REJECT packages back: This is non-conformal behavior and can lead to unnecessary retries from the other side. I would recommend to DROP only unknown protocols but properly REJECT known protocols (with a hashlimit to avoid DOS-attackers).

 

Why should I care if the other side is retrying? They shouldn't be trying to connect to my network anyway.

In a corporate setting, where it may aid in troubleshooting, I agree that proper rejects (ICMP rejects, not TCP resets) make sense. For a home network behind NAT, it is a bit pointless.

----------

## floppymaster

 *d2_racing wrote:*   

> What are you doing with that interface ?
> 
> The tun0 refer to a ssh tunnel or something else ?

 

tun0 was being used by OpenVPN, which creates a VPN by encapsulating encrypted IP packets inside of UDP packets.

I don't think that rule actually does anything useful. It is probably an experiment from my initial efforts to get OpenVPN running.

----------

## mv

 *floppymaster wrote:*   

> Why should I care if the other side is retrying?

 

To be conformal to the rules and to lower the traffic.

 *Quote:*   

> They shouldn't be trying to connect to my network anyway.

 

And this is exactly what you tell them with the reject ("this machine is not offering this service"). Not replying tells the other side only that their package was lost somehow (since the standard is to reply) and so they might retry.

 *Quote:*   

> For a home network behind NAT, it is a bit pointless.

 

NAT is not related with this at all. And how can it be pointless to follow the defined standard instead of violating it for no purpose (except for lazyness to write correct rules)?

----------

## floppymaster

 *Quote:*   

> And how can it be pointless to follow the defined standard instead of violating it for no purpose (except for lazyness to write correct rules)?

 

You hit the nail on the head here: I am being lazy because I really don't care if internet hosts sending traffic to my home network get a valid reply. The possible increase in retransmissions is negligible.

Hypothetically, assume that I am not lazy: I can think of only 2 reasons I might get inbound traffic from the internet not covered by one of my ACCEPT rules:

1. Someone is port scanning.

2. Somebody mistyped an IP address.

In the first case, a DROP rule is preferable since it will slow down the port scan. If the scanner gets a reject, it will likely move on to the next host.

In the second case, a reject would likely be helpful to Mr. Butterfingers. However, I would rather slow down a port scanner than help a network admin who can't type.

If you can come up with another possible reason for internet hosts to be sending traffic my way, I may change my tune.

----------

## mv

 *floppymaster wrote:*   

> 1. Someone is port scanning.
> 
> 2. Somebody mistyped an IP address.
> 
> In the first case, a DROP rule is preferable since it will slow down the port scan. If the scanner gets a reject, it will likely move on to the next host.

 

There are several reasons that someone is port scanning: It can be some malicious person or virus who intends to attack some vulnerability, or it can be somebody who expects a certain machine in some certain range and wants to reach it (e.g. a friend's gaming server or similar things). In the first case, a drop will not slow down the attacker (unless he is very stupid), since he will just continue scanning no matter whether he gets a reject or not. If somebody has a valid interest to find "his" machine, why should you try to slow him down (which you will also probably not do anyway, since many machines are misconfigured with DROP instead of reject meanwhile, so he will probably also scan many machines at once)? The only thing which you obtain by dropping is to cause more traffic for the honest people.

Especially in times of dynamic (or often changing) IPs there is also

3. the machine contacting you actually means one of the machines who had this IP before your machine received it. So a lot of packets might still hit you, since the machine sending it expects that you actually still want to receive all these packats and they are just lost somehow on the way...

----------

## floppymaster

What sort of reject rules would you suggest for my ruleset (see above)?

----------

## FcukThisGame

Guys, I just made a booboo.

I cat'd my rules script via ssh and forgot that text copies to clipboard on leftmouseup, not right click -> copy.

Here's what ran before my ssh died:

```
# (Definitely ran)

iptables -F

iptables -X

iptables -t nat -F

iptables -t nat -X

# Default filter policies (probably ran?)

iptables -P INPUT DROP

iptables -P OUTPUT ACCEPT

iptables -P FORWARD DROP
```

I've got the router set up as headless. My roommate relies on that router for internet. Do I have any other options to fix this than hooking up a monitor/keyboard and re-running the script?

EDIT: assuming all those rules ran, my roommate should still have internet access. right?

----------

## mv

 *floppymaster wrote:*   

> What sort of reject rules would you suggest for my ruleset (see above)?

 

Something like 

```
LIMIT="-m hashlimit --hashlimit 10/minute --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name limreject"

$iptables -A INPUT -p icmp $LIMIT -j REJECT --reject-with icmp-admin-prohibited

$iptables -A INPUT -p udp $LIMIT -j REJECT --reject-with icmp-port-unreachable

$iptables -A INPUT -p tcp $LMIIT -j REJECT --reject-with tcp-reset
```

 The limits are chosen rather low, of course...

Edit: Fix case of INPUTLast edited by mv on Fri Oct 22, 2010 5:12 pm; edited 1 time in total

----------

## floppymaster

Thanks for the suggestion. I have a couple questions though:

Any particular reason to use port-unreachable and tcp-resets for UDP and TCP? Wouldn't icmp-admin-prohibited be more accurate in all cases, since I am in fact making an administrative decision to block the traffic? The protocol-specific rejects make it look like the traffic is making it to the host unhindered, which is simply not true.

For the ICMP rule, I could see this causing problems if the other host's firewall is mis-configured. For instance, say the other side has an identical icmp reject rule in their firewall config, but does not have a rule to allow "RELATED" traffic through. Wouldn't that cause the two firewalls to continuously bounce icmp rejects at each other? Or am I missing something?

----------

## mv

 *floppymaster wrote:*   

> For the ICMP rule, I could see this causing problems if the other host's firewall is mis-configured.

 

If the other host's firewall is misconfigured everything can be wrong - it depends on how it is misconfigured. I think it is rather unlikely that a firewall does not allow RELATED traffic. And this is exactly why I think that icmp-admin-prohibited might not be the best solution for UDP and TCP: AFAIK icmp-admin-prohibited makes sense only on the icmp level; so perhaps the other side would not recognize the REJECT as related to the "higher level protocol" and take wrong consequences (e.g. retry on TCP level, since only some lower level failed).

----------

## floppymaster

 *mv wrote:*   

> AFAIK icmp-admin-prohibited makes sense only on the icmp level; so perhaps the other side would not recognize the REJECT as related to the "higher level protocol" and take wrong consequences (e.g. retry on TCP level, since only some lower level failed).

 

FYI, I did a little test for this. I added the following rule:

-A INPUT -i eth1 -p tcp --dport 12345 -j REJECT --reject-with icmp-admin-prohibited

Then, on another host, I ran the following: (192.168.0.1 being the IP attached to eth1 on the firewall)

telnet 192.168.0.1 12345

telnet: connect to address 192.168.0.1: No route to host

This is a different message than what you would get with a tcp-reset:

telnet: connect to address 192.168.0.1: Connection refused

The response was immediate with both reject types, and the REJECT rule was only triggered once for each connection attempt. So, both reject types seem to work, but the application does get a different response back.

----------

## Hu

 *FcukThisGame wrote:*   

> 
> 
> ```
> iptables -F
> 
> ...

 You could hook up a serial line and fix it over serial, assuming you have enabled serial support in the kernel and configured init to place a getty on ttyS0.  Since it is headless, you really ought to do this at some point, if you have not already.

 *FcukThisGame wrote:*   

> EDIT: assuming all those rules ran, my roommate should still have internet access. right?

 No.  You disabled that when you set the FORWARD policy to DROP.

 *floppymaster wrote:*   

> Any particular reason to use port-unreachable and tcp-resets for UDP and TCP? Wouldn't icmp-admin-prohibited be more accurate in all cases, since I am in fact making an administrative decision to block the traffic? The protocol-specific rejects make it look like the traffic is making it to the host unhindered, which is simply not true.

 Yes, that would be more accurate.  Sometimes, people prefer to design firewalls that make it look like the request hit an unprotected but uninteresting system, rather than sending a response which clearly states that a firewall is present.

----------

