IRC Logs

Network: freenode Channel: #iptables

	Enter your search terms Submit search form
	Web www.irclog.org

[00:01]<s19g>It shows an arp lookup for the public address I pinged, then the packet going across, then a packet coming back
[00:04]<rnryv>s34n: can you pastebin it ?
[00:13]<s19g>Regit: http://www.rafb.net/paste/results/iGK5AB41.html
[00:15]<rnryv>s34n: no icmp in there
[00:20]<s19g>k
[00:23]<s19g>In repeated tests, I don't see any traffic that can be attributed to the ping
[00:39]<zr2nfrys>can anyone point me to information about the new netfilter xtables? I'm having trouble finding any documentation about it in the kernel doc or online
[00:40]<-- svgvsdyzgjvr xrs>/dev/null")
[02:05]<-- dyrnnprd wrs puyv> i mean the other left <-")
[03:45]<sxzjvvd_>gn8
[03:53]<zjdsvnz>when i do -p ! icmp it complains it dosn't know what -dport is... yet it says i can do this in the man pages i'm using iptables 1.3.5
[03:55]<mrrynfmr>you're reading the manpage wrong then
[03:55]<mrrynfmr>where does it say that?
[03:55]<mrrynfmr>you need to use -p tcp (or -p udp) to use --dport
[03:56]<zjdsvnz>-p, --protocol [!] protocol
[03:57]<zjdsvnz>! icmp, should mean to use tcp and udp but not icmp
[03:57]<mrrynfmr>um, no
[03:57]<mrrynfmr>there's more than 3 choices
[03:57]<zjdsvnz>instead of speficying 2 rules 1 for udp 1 for tcp
[03:57]<zjdsvnz>udp, tcp, icmp, all
[03:57]<zjdsvnz>hrmm
[03:57]<mrrynfmr>" or it can be a numeric value, representing one of these protocols or a different one."
[03:57]<zjdsvnz>well not icmp should mean only udp and tcp in my books
[03:58]<mrrynfmr>nope
[03:58]<mrrynfmr>not icmp means not icmp
[03:58]<zjdsvnz>as all wouldn't be valid if not icmp
[03:58]<zjdsvnz>oh hmm
[03:58]<zjdsvnz>i can't do -p tcp,udp can i?
[03:58]<mrrynfmr>all != tcp,udp,icmp
[03:58]<mrrynfmr>no you can't
[03:59]<zjdsvnz>so i'm stuck with making 2 rules todo udp and tcp...
[03:59]<mrrynfmr>yes
[03:59]<zjdsvnz>bugger
[03:59]<mrrynfmr>you can use multiport to group the TCP ports together
[03:59]<zjdsvnz>be nice if ya could do -s tcp,udp
[03:59]<zjdsvnz>erm -p*
[03:59]<zjdsvnz>ah
[03:59]<zjdsvnz>how do i go aobut that?
[04:00]<mrrynfmr>-A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
[04:00]<zjdsvnz>ah i see it in the man page
[04:00]<mrrynfmr>up to 15 ports in the list, you can use ranges
[04:01]<zjdsvnz>ah that answeres another thing i wasn't too sure on but there isn't such a thing for the port type
[04:02]<mrrynfmr>port type?
[04:02]<zjdsvnz>oh i ment to type protocol type sorry
[04:02]<zjdsvnz>i'm still half asleep here
[04:02]<mrrynfmr>you could make one, but then --dport wouldn't work
[04:03]<mrrynfmr>the --dport for UDP is a different function than the --dport for TCP
[04:03]<zjdsvnz>ah then i'm back to doing it the old way then.
[04:03]<zjdsvnz>jsut thought there be a less lines method but oviously not
[04:04]<zjdsvnz>thanks for that.
[15:36]<pyzn2rww>hi .. i figured for a VPN connection i need to source NAT my connections there ... e.g. change the source IP of the packets send to a certain IP.. how can i do that ? i'm pretty new to iptables
[15:53]<pyzn2rww>anyone here at all ?
[17:07]<rlraxne>i have been digging through the iptables docs at netfilter.org but I still didnt manage to find a solution for following question
[17:07]<rlraxne>if I want to filter out reserved addresses and my box has two network cards (eth0 for outside and eth1 to inside)... will I have to set drop rules on both INPUT and FORWARD chains ?
[17:08]<rlraxne>couldnt I just use for example some PREROUTING chain and set the drops in there ?
[17:08]<vzrllysv>Apachez: you could use PREROUTING
[17:08]<rlraxne>any disadvantage with that ?
[17:08]<rlraxne>I also have -i so Im checking that the package is originated from the outside device
[17:09]<vzrllysv>not that I know of. the netfilter guys say it "shouldn't" be done, but if you ask em why, it's because then it'll filter in both INPUT and FORWARD, but of course that's exactly what you want
[17:09]<rlraxne>will I have to use -t nat -A PREROUTING or can write just -A PREROUTING ?
[17:10]<vzrllysv>good question. I dunno if the filter table (the default table) has a PREROUTING chain. try and see.
[17:10]<rlraxne>hmpf :P
[17:10]<rlraxne>another note
[17:11]<rlraxne>since I altered my iptables rules to be strict and also check sourceport = 1024:65535 I have noticed some logs where some addresses try to ask my dns but they originate from sourceport 53
[17:11]<vzrllysv>I never-ever-ever match on source port.
[17:11]<rlraxne>shouldnt a dns lookup originate from sourceport 1024:65535 ?
[17:11]<vzrllysv>not necessarily
[17:12]<vzrllysv>a tcp request can pretty much originate from any port it wants
[17:12]<rlraxne>not according to rfc's :P
[17:12]<vzrllysv>well what they SHOULD do and what they can get away with doing, which is more like what they'll do in real life, are different
[17:13]<rlraxne>thats why I use a firewall :P
[17:13]<rlraxne>if machines and people just did what they SHOULD do they would be no need for firewalls ;)
[17:14]<-- 2yd2nzy xrs fuyv>http://iownmymusic.org/ http://iownmydvds.org/ .")
[17:14]<rlraxne>ohh finally my google skills are working
[17:14]<vzrllysv>well there are actually security benefits for you if you can randomize the source ports of your tcp connections, and things will still work fine unless there are source-port-filtering firewalls on the other end
[17:14]<rlraxne>seems like the case when a new connection to destport 53 originates from sourceport 53 it is most likely a hack attempt to try to bypass stateless firewalls
[17:15]<vzrllysv>also iptables-tutorial.frozentux.net has WAY better docs (IMHO) than netfilter.org
[17:15]<rlraxne>yup will try to read them through
[17:15]<vzrllysv>state has nothing to do with it
[17:15]<vzrllysv>I have a stateful firewall that doesn't care at all about source ports
[17:16]<vzrllysv>I'm concerned about where the packet wants to go, not so much where it came from
[17:19]<rlraxne>well its more of a sanity check
[17:19]<rlraxne>like pf's "scrub in all"
[17:20]<rlraxne>which I saw existed like a module in iptables until kernel 2.6 where it was being removed by some odd reasons
[17:21]<vzrllysv>well, that's why you're seeing possibly-legitimate dns traffic bouncing off your firewall
[17:21]<rlraxne>it was from south korea so I doubt it was even near legitimate traffic :P
[17:23]<vzrllysv>personally, I'd rather let a few illegitimate packets through than drop anything that ought to get through. that preference probably comes from my belief that if you follow security best practices behind your firewall, a firewall doesn't really do much for you anyway.
[17:28]<rlraxne>well thats not the case in here where I need to enforce strict policies
[17:42]<rlraxne>when dealing with custom chains... is it necessary to use -j RETURN in the end of the chain ?
[17:43]<rlraxne>or is that part added automagically by iptables ?
[17:50]<vyrn-vnzsr>Apachez: correct, custom chains will return to the caller if a rule is not matched
[17:52]<rlraxne>oki then I wont need it in the end of each custom rule :)
[17:54]<vzrllysv>no, just at the end of the chain - and maybe not even then. depends on what you're doing in that chain.
[17:57]<rlraxne>ehm
[18:02]<rlraxne>here is my example http://www.sqlpaste.com/?entry_id=1417

Back to #iptables
Or go to some related logs:
#netbsd
#gentoo
#suse
#debian
#php