| 1 |
On Mon, Dec 30, 2013 at 6:07 PM, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
| 2 |
> |
| 3 |
|
| 4 |
[-- LE SNIP --] |
| 5 |
|
| 6 |
> Ok, well, maybe I should have posted my entire ruleset... |
| 7 |
> |
| 8 |
> I have this above where I define my chains: |
| 9 |
> |
| 10 |
> # |
| 11 |
> *filter |
| 12 |
> :INPUT DROP [0:0] |
| 13 |
> :FORWARD DROP [0:0] |
| 14 |
> :OUTPUT DROP [0:0] |
| 15 |
> # |
| 16 |
> |
| 17 |
> Does it matter where this goes? |
| 18 |
> |
| 19 |
|
| 20 |
Yes. Chain declarations must come before the rules themselves. |
| 21 |
|
| 22 |
> And then above that, I have something else that I've never understood: |
| 23 |
> |
| 24 |
> *mangle |
| 25 |
|
| 26 |
Begin declaration of the "mangle" table. |
| 27 |
|
| 28 |
> :PREROUTING ACCEPT [1378800222:449528056411] |
| 29 |
> :INPUT ACCEPT [1363738727:447358082301] |
| 30 |
> :FORWARD ACCEPT [0:0] |
| 31 |
> :OUTPUT ACCEPT [1221121261:1103241097263] |
| 32 |
> :POSTROUTING ACCEPT [1221116979:1103240864155] |
| 33 |
|
| 34 |
The numbers within [brackets] are statistics/countes. Just replace |
| 35 |
them with [0:0], unless you really really really have a good reason to |
| 36 |
not start counting from 0... |
| 37 |
|
| 38 |
The second word is the 'policy' of the chain, i.e., the default action |
| 39 |
taken if no rules match in the chain |
| 40 |
|
| 41 |
> -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG |
| 42 |
> -j DROP |
| 43 |
> -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP |
| 44 |
> -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP |
| 45 |
> -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP |
| 46 |
|
| 47 |
Alright, the `--tcp-flags` option takes two parameters: |
| 48 |
<flags_to_check> and <expected_flags> |
| 49 |
|
| 50 |
These 4 rules collectively block 'well-known TCP Attacks', which I've |
| 51 |
listed here: |
| 52 |
|
| 53 |
http://serverfault.com/a/245713/15440 |
| 54 |
|
| 55 |
NOTE: In that ServerFault posting, I suggested using the anti-attack |
| 56 |
rules in -t raw -A PREROUTING. This saves a great deal of processing, |
| 57 |
becase the "raw" table is just that: raw, unadulterated, unanalyzed |
| 58 |
packets. The CPU assumes nothing, it merely tries to match well-known |
| 59 |
fields' values. |
| 60 |
|
| 61 |
You *do* have to make sure that you don't forget to compile kernel |
| 62 |
support for RAW tables ;-) |
| 63 |
|
| 64 |
> COMMIT |
| 65 |
|
| 66 |
End of "mangle" table declaration. Commit all chain definitions and |
| 67 |
chain rules in one atomic operation. |
| 68 |
|
| 69 |
>> ipset create ssh_in iphash |
| 70 |
>> ipset add ssh_in 1.2.3.4 |
| 71 |
>> |
| 72 |
>> and then this works: |
| 73 |
>> -A -m set --match-set ssh_in src -j ACCEPT |
| 74 |
>> |
| 75 |
>> ipset has the same save/load type things as ipt (minor differences |
| 76 |
>> with how you handle reload, but google or ask if you want to know). |
| 77 |
>> The set needs to be in place before the ipt rule is added, so ipset |
| 78 |
>> comes first in your boot sequence. |
| 79 |
> |
| 80 |
> |
| 81 |
> Thanks, looks interesting and useful... |
| 82 |
> |
| 83 |
> So much to learn, so little time... ;) |
| 84 |
> |
| 85 |
|
| 86 |
iptables is a powerful beast; learn it well, and you'll prosper :-) |
| 87 |
|
| 88 |
|
| 89 |
Rgds, |
| 90 |
-- |
| 91 |
FdS Pandu E Poluan |
| 92 |
~ IT Optimizer ~ |
| 93 |
|
| 94 |
• LOPSA Member #15248 |
| 95 |
• Blog : http://pandu.poluan.info/blog/ |
| 96 |
• Linked-In : http://id.linkedin.com/in/pepoluan |
Archives