|
|:( iptabels with ipv6
![[nl]](/s/countries/nl.gif) Carmen Sandiego on Saturday, 15 April 2006 11:05:16
Can any body tell me how i can filter trafic with iptabel.
I want to allow trafic from inside to outside
but no trafic from outside to the inside.
if posebol can give aplication exampel for a filter like http
|:( iptabels with ipv6
There is currently no stateful firewalling in the Linux kernels (assuming you meant Linux as you said 'iptabel', but most likely meant ip6tables).
One can get stateful firewalling when applying the USAGI patches though.
But to solve your question, which will break most likely a large number of things like DNS etc:
# Allow localnetwork connecting to port 80 on any network
ip6tables -s 2001:db8::/32 --proto tcp --dport 80 -j ACCEPT
# Allow any network to send back packets from port 80 to our local network
ip6tables -d 2001:db8::/32 --proto tcp --sport 80 -j ACCEPT
ip6tables -j DROP
The above doesn't handle the case where sport == 80 && dport == 22 or something, thus they still can connect inbound as long as the sport == 80. You need the ESTABLISHED stuff to make that work properly. Thus patch up to USAGI for it.
As mentioned the above breaks DNS and a lot of other things.
Where 2001:db8::/32 is the prefix of your local network.
Using -i eth0, -o eth1 or something is of course also possible, but might get you into other loopholes.
|:( iptabels with ipv6
Shadow Hawkins on Saturday, 22 April 2006 14:15:06
To make it slightly less insecure one may assume the http session will have a source port of 1024 or above. This will at least not expose telnet, ftp, and smtp to the world.
|:( iptabels with ipv6
![[de]](/s/countries/de.gif) Shadow Hawkins on Monday, 08 May 2006 23:08:19
Hmm.
My last information was that 2.6.15 added state match support to the kernel, iptables 1.3.5 to the userland.
Unfortunately it doesn't really work here :-D
All packets are classified with state INVALID:
IN=ppp0 OUT=eth0 SRC=2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX DST=2001:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX LEN=80 TC=0 HOPLIMIT
=55 FLOWLBL=0 PROTO=TCP SPT=7374 DPT=10110 WINDOW=4880 RES=0x00 SYN URGP=0 OPT (020404C40402080A4EBF38860000000001030302)
|:( iptabels with ipv6
![[gb]](/s/countries/gb.gif) Carmen Sandiego on Friday, 12 May 2006 02:09:48
An improvement to those rules would be to simply replace the lot with:
# default DROP
ip6tables -P FORWARD DROP
# reject incoming connection requests to 80/tcp but allow all other traffic
ip6tables -A FORWARD -s 2001:db8::/32 --proto tcp --dport 80 -j ACCEPT
ip6tables -A FORWARD -d 2001:db8::/32 --proto tcp --sport 80 ! --syn -j ACCEPT
# log stuff, you might want to DROP/REJECT early to trim 'guff'
ip6tables -A FORWARD -j LOG
The later kernels support REJECT which is far better. If you have compiled in support then you should replace DROP with REJECT.
The advantage by adding the '--syn' part means than you can rely on the statefulness of TCP to deal with security issues of the remote host bypassing your firewalling by making their source port 80. If they send 'bad' ACK packets all that will happen is that the host will send back a message effectively saying 'reset connection'.
As Jeroen said, this will only allow you HTTP traffic, DNS and everything else you will need to construct similar seperate rules for. IPv6 firewalling is difficult, especially when you start playing with the INPUT/OUTPUT chains as you need to make sure you do not block a lot of needed ICMPv6 and general local link multicast traffic.
Stick with the FORWARD chain if you are unsure and then rely on locking down the firewall machine to not run any services....which is good practice anyway. 'netstat -lp' is you friend for that one.
Cheers
Alex
|:( iptabels with ipv6
Shadow Hawkins on Friday, 12 May 2006 12:13:27
Some notes here because I happen to disagree.
DROP is better then REJECT. No point in giving away details to anyone probing your network. So DROP them quit instead of sending out information that you are filtering with REJECT. Unfortunatly not all systems allow you to make this distinction. (A major issue I have with Cisco IOS.)
Always filter early. So filter on the INPUT chain whenever possible. No point in parsing it any further if you can drop it in an earlier stage.
Both basic rules are in just about every firewall book you will find out there.
|:( iptabels with ipv6
Carmen Sandiego on Saturday, 13 May 2006 15:59:55
Hi,
DROP is better then REJECT. No point in giving away details to anyone probing your network. So DROP them quit instead of sending out information that you are filtering with REJECT. Unfortunatly not all systems allow you to make this distinction. (A major issue I have with Cisco IOS.) No DROP is not better :) The amount you sacrific in your ability to use conventinal diagnostics tools is far higher than any security through obscurity you get. How do you plan on remotely exploiting a service on a machine that says "Connection refused", the socket is closed...there is nothing you can do...don't bother.
Working both from an ISP background and now as sysadmin at a university is was damn annoying people using DROP instead of REJECT as diagnostics were impossible.
I have sen really braindead firewall rule sets that block ICMP echo traffic but then permit port 80 traffic to flow...I mean why? If you wanted to exploit a port 80 service oyu simply send a bunch of SYN packets directly to port 80. If something is open, you will get a SYN/ACK otherwise you assume the service is unavailable.
Some might say "ahh but it slows down portscans, etc", this point has not been valid for at least 2 years since the even of stateless portscanning where regardless of the remote firewall policy you can scan as fast as your Internet connection will let you.
Sorry to go on, but it makes my blood boil when people spread this. DROP should *only* be used for packets you think have spoofed source addresses and also in the case of extremely low speed Internet connections.
I have had to diagnose too many problems and it takes ten times longer to fix a problem when people use DROP exclusively, violating RFC's and the abilitity to use kosher testing tools. By using DROP you making the details of a portscan part of your 'secret' and that is security through obscurity; time should be invested in shutting down unwanted services.
Just because 95% of the traffic that triggers these rules are bad guys, does not mean its worth killing the remaining 5% for no reason.
Blocking ping and 'stealthing' ports is akin to destroying ll the maps in the world in fear that burglars will find your home and break into it.
</rant>
Always filter early. So filter on the INPUT chain whenever possible. No point in parsing it any further if you can drop it in an earlier stage. Traffic going to FORWARD does not pass through INPUT/OUTPUT.... I thought the reference was to forwarding traffic?
Both basic rules are in just about every firewall book you will find out there. I agree with the second rule, but the first rule....eugh... :)
Cheers
Alex
|:( iptabels with ipv6
Shadow Hawkins on Wednesday, 19 April 2006 14:53:14
Have search for 6wall, it's a ipv6 firewall, it's a bit old but makes handling ip6tables easier.
|:( iptabels with ipv6
Shadow Hawkins on Saturday, 22 April 2006 14:12:40
Just about any google hit on 6wall hits a brickwall of 404's.
|:( iptabels with ipv6
Shadow Hawkins on Saturday, 22 April 2006 18:37:17
It seems Leaf project's had a clean up you can find it for download in http://sourceforge.net/project/showfiles.php?group_id=13751&package_id=67534 in the Bering-uClibc_2.4_ipv6.tar package.
|
![[ch]](/s/countries/ch.gif)
on Saturday, 15 April 2006 11:34:59
Posting is only allowed when you are