| View previous topic :: View next topic |
| Author |
Message |
streamkid
Tux's lil' helper
Joined: 17 Jul 2007
Posts: 82
Location: Greece
|
 Posted: Mon Jul 21, 2008 6:47 am Post subject: Comment my iptables ruleset |
 |
|
http://streamkid.net/~streamkid/iptables_init
Beware that's my first attempt into iptables.
On the bottom, I am explaining what I want to achieve. Through testing, seems that this works ok. Don't know if this is generally a "good" ruleset.
So, comment on it 
Last edited by streamkid on Mon Jul 21, 2008 4:40 pm; edited 1 time in total |
|
| Back to top |
|
 |
ranger719
Tux's lil' helper
Joined: 16 May 2006
Posts: 92
Location: Germany
|
| Posted: Mon Jul 21, 2008 9:41 am Post subject: |
|
|
Hi,
I think you do not allow "icmp type 3', so if someone rejects/forbids/etc a connection you try to establish you won't recognize it? And, 'icmp type3 code 4 (fragmentation needed)' is crucial, afaik? I once filtered it, and had bad problems.. Small mail works, big ones not. Some websites just stop loading, connections suddenly die... Took me a while to figure that out. 'type 11 (time exceeded)' is worth not filtering, too?
I would add rules like these:
| Code: | IPTABLES -A INPUT -p TCP -m state --state INVALID -j REJECT --reject-with tcp-reset
IPTABLES -A INPUT -p ALL -m state --state INVALID -j REJECT
#BAD TCP
IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "New not syn "
IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j REJECT --reject-with tcp-reset
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "Stealth scan "
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j REJECT --reject-with tcp-reset
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "Stealth scan "
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL ALL --j REJECT --reject-with tcp-reset
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "Stealth scan "
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j REJECT --reject-with tcp-reset
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "Stealth scan "
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j REJECT --reject-with tcp-reset
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "Stealth scan"
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT --reject-with tcp-reset
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "Stealth scan "
IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j REJECT --reject-with tcp-reset
Of course, you can DROP them instead of a REJECT. |
And, if you're using Bittorrent 
| Code: | | IPTABLES -A bad_tcp_packets -p tcp --tcp-flags RST RST -j DROP |
on your BT-port.
And I think a good rule is: Block anything incoming, allow only that what is needed. I do not filter outgoing traffic at all, but thats up to you And I think you should log something, so you can see whats going on/wrong. Use ulog for this, otherwise iptables will spam your 'dmesg' output. You have to install this. Do not forget to set some log-limits, you can find some in the rules I posted. Otherwise something like 'ping -f' will be a DOS-attack to you |
|
| Back to top |
|
|
streamkid
Tux's lil' helper
Joined: 17 Jul 2007
Posts: 82
Location: Greece
|
| Posted: Mon Jul 21, 2008 10:00 am Post subject: |
|
|
Hello,
thanks for your comments.
I was concerned about fragmentation needed (from my own experience  ), and was planning to add it. Didn't know about the rest. I will allow all three.
For the rules about bad tcp packets, I think I have to create the chain bad_tcp_packets, right? (Did some rtfm the otherday
I have to read more to understand all the tcp flags.
I think I implement the general rule of blocking anything and then unblocking what needed, don't you think? At least I get it so by reading the rules. |
|
| Back to top |
|
|
ranger719
Tux's lil' helper
Joined: 16 May 2006
Posts: 92
Location: Germany
|
| Posted: Mon Jul 21, 2008 10:31 am Post subject: |
|
|
No, you can name it whatever you like to. You just have to jump into the table. If a packet does not match a rule in a table it will proceed to the next table in the ruleset. The last rule is the default-rule, set with -P.
I have something like this (at the beginning):
| Code: | # Trusted network (LAN, lo)
$IPTABLES -A INPUT -i $if_lan1 -p all -j ACCEPT
$IPTABLES -A INPUT -i lo -p all -j ACCEPT
# Rest is from the outside -> Order: check, allow known "connections", check all others against services
$IPTABLES -A INPUT -p all -j bad_source <- check for spoofed sources
$IPTABLES -A INPUT -p tcp -j bad_tcp_packets <- scans, new not syn, ...
$IPTABLES -A INPUT -p udp -j bad_udp_packets <- broadcast, windows-spam..
$IPTABLES -A INPUT -p icmp -j icmp_packets <- only needed icmp is allowed
#$IPTABLES -A INPUT -p ALL -m state --state INVALID -m limit --limit 10/minute --limit-burst 5 -j ULOG --ulog-prefix "Invalid packet "
$IPTABLES -A INPUT -p TCP -m state --state INVALID -j REJECT --reject-with tcp-reset <- filter invalid packets
$IPTABLES -A INPUT -p ALL -m state --state INVALID -j REJECT
$IPTABLES -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT <- established connections are ok
$IPTABLES -A INPUT -p tcp -j services_tcp <- allowed services here
$IPTABLES -A INPUT -p udp -j services_udp <- allowed services here
# Log packets that do not match anything (default DROP)
$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j ULOG --ulog-prefix "INPUT pckt died " |
Some other things you might want add. You can google them for more information.
| Code: | echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route |
| Quote: | | I think I implement the general rule of blocking anything and then unblocking what needed, don't you think? At least I get it so by reading the rules. |
| Code: | # Default Policy
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT |
will forbid anything incoming and forewarded, as long as you do not allow it with a rule. The default-rule is the last one a packet is able to "see" when no other rule matched. |
|
| Back to top |
|
|
streamkid
Tux's lil' helper
Joined: 17 Jul 2007
Posts: 82
Location: Greece
|
| Posted: Mon Jul 21, 2008 11:30 am Post subject: |
|
|
| ranger719 wrote: | | No, you can name it whatever you like to. You just have to jump into the table. If a packet does not match a rule in a table it will proceed to the next table in the ruleset. The last rule is the default-rule, set with -P. |
I meant I have to create this chain, it's not predefined.
| ranger719 wrote: |
I have something like this (at the beginning):
| Code: | # Trusted network (LAN, lo)
$IPTABLES -A INPUT -i $if_lan1 -p all -j ACCEPT
$IPTABLES -A INPUT -i lo -p all -j ACCEPT |
|
My original intention was to allow everything from inside to the server and from inside to outside. But I finally went on creating something more restricted (ie limited connections from lan and lo). I don't really understand the point of rejecting/droping from lo, but I read this on the wiki, and till I have the time to analyse it in depth, I'm thinking of keeping it. What do you say?
| ranger719 wrote: | | Code: |
# Rest is from the outside -> Order: check, allow known "connections", check all others against services
$IPTABLES -A INPUT -p all -j bad_source <- check for spoofed sources
$IPTABLES -A INPUT -p tcp -j bad_tcp_packets <- scans, new not syn, ...
$IPTABLES -A INPUT -p udp -j bad_udp_packets <- broadcast, windows-spam..
$IPTABLES -A INPUT -p icmp -j icmp_packets <- only needed icmp is allowed
$IPTABLES -A INPUT -p tcp -j services_tcp <- allowed services here
$IPTABLES -A INPUT -p udp -j services_udp <- allowed services here |
|
I don't get this syntax. I though -j should follow an action. bad_source sounds like a condition. Mind explaining more?
| ranger719 wrote: |
# Log packets that do not match anything (default DROP)
$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j ULOG --ulog-prefix "INPUT pckt died "[/code]
|
With this, as I get it, packets will never reach the last, default policy rule (-P). Right?
Some other things you might want add. You can google them for more information.
| Code: | echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route |
Done all but log_martians. Have to check what this is.
|
|
| Back to top |
|
|
ranger719
Tux's lil' helper
Joined: 16 May 2006
Posts: 92
Location: Germany
|
| Posted: Mon Jul 21, 2008 11:56 am Post subject: |
|
|
| streamkid wrote: | | ranger719 wrote: | | No, you can name it whatever you like to. You just have to jump into the table. If a packet does not match a rule in a table it will proceed to the next table in the ruleset. The last rule is the default-rule, set with -P. |
I meant I have to create this chain, it's not predefined. |
Yes, you have to create them.
| streamkid wrote: | | ranger719 wrote: |
I have something like this (at the beginning):
| Code: | # Trusted network (LAN, lo)
$IPTABLES -A INPUT -i $if_lan1 -p all -j ACCEPT
$IPTABLES -A INPUT -i lo -p all -j ACCEPT |
|
My original intention was to allow everything from inside to the server and from inside to outside. But I finally went on creating something more restricted (ie limited connections from lan and lo). I don't really understand the point of rejecting/droping from lo, but I read this on the wiki, and till I have the time to analyse it in depth, I'm thinking of keeping it. What do you say? |
If have a default-DROP rule and do not allow traffic from/to the loopback-device, you might run into problems with some programms. But I am not sure about this.
| streamkid wrote: | | ranger719 wrote: | | Code: |
# Rest is from the outside -> Order: check, allow known "connections", check all others against services
$IPTABLES -A INPUT -p all -j bad_source <- check for spoofed sources
$IPTABLES -A INPUT -p tcp -j bad_tcp_packets <- scans, new not syn, ...
$IPTABLES -A INPUT -p udp -j bad_udp_packets <- broadcast, windows-spam..
$IPTABLES -A INPUT -p icmp -j icmp_packets <- only needed icmp is allowed
$IPTABLES -A INPUT -p tcp -j services_tcp <- allowed services here
$IPTABLES -A INPUT -p udp -j services_udp <- allowed services here |
|
I don't get this syntax. I though -j should follow an action. bad_source sounds like a condition. Mind explaining more? |
You have to create the tables and fill them with rules ($IPTABLES -N table-name creates, -A table_name adds a rule to this table/chain). With '-j' you can jump into tables, or use an action like ACCEPT, REJECT, DROP. If no rule in this table matches, the packet is returned and moves along the other defined tables, until it eventually reaches the default-rule (set with '-P').
| streamkid wrote: | | ranger719 wrote: |
# Log packets that do not match anything (default DROP)
$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j ULOG --ulog-prefix "INPUT pckt died "[/code]
|
With this, as I get it, packets will never reach the last, default policy rule (-P). Right? |
No, log-rules 'return' the packets. They just 'look' at them and then passes them back. |
|
| Back to top |
|
|
streamkid
Tux's lil' helper
Joined: 17 Jul 2007
Posts: 82
Location: Greece
|
| Posted: Mon Jul 21, 2008 12:16 pm Post subject: |
|
|
| ranger719 wrote: | | If have a default-DROP rule and do not allow traffic from/to the loopback-device, you might run into problems with some programms. But I am not sure about this. |
I am. I've already faced it when squirrelmail couldn't contact the local mysql and imap and smtp. I also couldn't access the local dns resolver. That's why I have a section called "Allowed services from localhost".
My question was: what do I get by blocking some traffic on the lo iface? Propably nothing. Just experience bacause of troubleshooting
| ranger719 wrote: | | You have to create the tables and fill them with rules ($IPTABLES -N table-name creates, -A table_name adds a rule to this table/chain). With '-j' you can jump into tables, or use an action like ACCEPT, REJECT, DROP. If no rule in this table matches, the packet is returned and moves along the other defined tables, until it eventually reaches the default-rule (set with '-P'). |
Missed the bit that -j also means jump.
| ranger719 wrote: | | No, log-rules 'return' the packets. They just 'look' at them and then passes them back. |
Aha.
Thanks for the clarifications. Helped a lot |
|
| Back to top |
|
|
streamkid
Tux's lil' helper
Joined: 17 Jul 2007
Posts: 82
Location: Greece
|
| Posted: Mon Jul 21, 2008 7:12 pm Post subject: |
|
|
I am about to begin improving my ruleset. I will apply the logic "specific accepted, the rest trashed".
Is there any benefit in creating custom chains that packets will pass through, and get dropped if they don't get matched till the end (apart from visual improvement of the script )?
Instead of writing stand-alone rules, they could be categorized, ie chain "tcp accepted incoming", if it doesn't match, trash. I don't know if I state my question correctly, but I'm sure you 'll understand it 
Thanks in advance
PS: ranger719, could you give more information on how you identify bad tcp packets and bad addresses? (for example, by listing the chain). I have a clue on bad addresses, but no on bad tcp packets. |
|
| Back to top |
|
|
ranger719
Tux's lil' helper
Joined: 16 May 2006
Posts: 92
Location: Germany
|
| Posted: Mon Jul 21, 2008 10:39 pm Post subject: |
|
|
| streamkid wrote: | Is there any benefit in creating custom chains that packets will pass through, and get dropped if they don't get matched till the end (apart from visual improvement of the script )?
Instead of writing stand-alone rules, they could be categorized, ie chain "tcp accepted incoming", if it doesn't match, trash. I don't know if I state my question correctly, but I'm sure you 'll understand it |
You can improve performance if you order your rules correctly. The earlier a rules matches, the less cpu consumption. But I doubt your CPU will get problems checking some iptables-rules Imho readability is fundamental if you run into trouble. The more rules, the harder it gets to see through you script.
| streamkid wrote: | | PS: ranger719, could you give more information on how you identify bad tcp packets and bad addresses? (for example, by listing the chain). I have a clue on bad addresses, but no on bad tcp packets. |
My TCP-filter-rule is already posted, see above. The rules in the bad_tcp_packets-chain/table. Bad-IP-adresses is something like incoming messages form an internal IP, or even 127.0.0.1-sources. Depends on your network. If you see such packets on the interface to the outside you can safely drop/reject it, and you should If you want to know more on TCP-flags you should google/wikipedia it. There are many constellations which should not occur in normal traffic. One Example.. A new connection is established through a 3-way handshake. Client sends SYN, server responds SYN,ACK and then the client sends back an ACK (and payload if applicable). You can now try to fool a firewall and send packets that seem to come from a connection which is in the state of getting established by sending a SYN,ACK. Eventually the firewall will let the message pass. With other malformed packets you can try to guess the operating system by sending such packets and evaluate the response (this even works with non-malformed-packets, linux and windows differ in some responses). TCP is a bad protocoll... The inventors did not know that it would become so widespread and that every OS would implement another tcp-stack with its on flaws.. But hey, it works.. most of the time |
|
| Back to top |
|
|
|
|
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
|
|
Networking & Security
