Re: [LARTC] Interesting article about punching holes in firewalls...
On Thursday 21 December 2006 09:37, Grant Taylor wrote: > I have read the article. I suspect that my uncertainty has to do > with lack of how the SPI portion of the code works. I am not > qualified to read the source code to make an informed opinion. I was > (mis)believing that the SPI was very simple in the fact that it would > classify any returning traffic coming back from a host as related. > Now, I'm getting the impression that this is not the case and that > only specific packets are considered related. > > Can / will someone that is more versed in programming / reading > source code please give me a brief overview of how the kernel decides > what is and is not related. That is not me, but I have in the past had the same question answered on the netfilter list. The protocol-specific helper drivers such as ip_conntrack_$PROTOCOL are the ones that defined state "RELATED". If you're not using a "helped" protocol, you will have no RELATED packets. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] OpenVPN, proxy ARP for an entire subnet (Linux endpoints)
: mtu 1500 qdisc noop link/ether ce:23:26:b7:ef:0c brd ff:ff:ff:ff:ff:ff 3: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:56:ed:12 brd ff:ff:ff:ff:ff:ff inet 192.168.6.1/24 brd 192.168.6.255 scope global eth0 inet 72.9.234.117/32 scope global eth0 inet 72.9.234.115/32 scope global eth0 inet 72.9.234.119/32 scope global eth0 valid_lft forever preferred_lft forever 4: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:80:c8:1b:72:4c brd ff:ff:ff:ff:ff:ff inet my.ip.add.ress/nm brd isp.brd.cast.ip scope global eth1 valid_lft forever preferred_lft forever [EMAIL PROTECTED]:~# ip route list 192.168.6.0/24 dev eth0 proto kernel scope link src 192.168.6.1 isp.su.bn.et/nm dev eth1 proto kernel scope link src my.ip.add.ress 127.0.0.0/8 dev lo scope link default via isp.rou.ter.ip dev eth1 [EMAIL PROTECTED]:~# ip rule list 0: from all lookup local 32763: from 72.9.234.119 lookup vpn 32764: from 72.9.234.115 lookup vpn 32765: from 72.9.234.117 lookup vpn 32766: from all lookup main 32767: from all lookup default [EMAIL PROTECTED]:~# ip route list table vpn default via 192.168.6.4 dev eth0 > I tested the routing by using my own IP in an iptables -j LOG rule, > followed by an nmap -sP of the range. This time I did it from a third site, but to get a better picture I added logging in raw/PREROUTING too. This time the logging was at the RemoteVPNpeer rather than the local one, but anyway, it shows everything moving as expected. (LocalVPNpeer, being a 2.4.31 host, doesn't have iptable_raw.) > [EMAIL PROTECTED] ~]# iptables-save > # Generated by iptables-save v1.2.11 on Mon Dec 11 09:10:27 2006 > *filter > > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > :LogVpn - [0:0] > > -A FORWARD -d y.y.y.32/255.255.255.224 -j LogVpn > -A FORWARD -s y.y.y.32/255.255.255.224 -j LogVpn > -A LogVpn -s my.IP.add.ress -j LOG --log-prefix "5Vpn IN: " > -A LogVpn -d my.IP.add.ress -j LOG --log-prefix "5Vpn OUT: " > COMMIT > # Completed on Mon Dec 11 09:10:27 2006 Here I'll only show the significant parts of iptables-save on RemoteVPNpeer: # Generated by iptables-save v1.2.11 on Wed Dec 13 04:17:29 2006 *raw :PREROUTING ACCEPT [149316:38901352] :OUTPUT ACCEPT [155833:112104141] -A PREROUTING -s 72.9.234.112/29 -d 3rd.par.ty.IP -j LOG --log-prefix "3-raw OUT: " -A PREROUTING -s 3rd.par.ty.IP -d 72.9.234.112/29 -j LOG --log-prefix "3-raw IN: " COMMIT [ ... ] # Generated by iptables-save v1.2.11 on Wed Dec 13 04:17:29 2006 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] [ ... ] -A INPUT -j Reject -A FORWARD -s 3rd.par.ty.IP -j LogVpn -A FORWARD -d 3rd.par.ty.IP -j LogVpn [ ... ] -A LogVpn -s 3rd.par.ty.IP -d 72.9.234.112/29 -j LOG --log-prefix "3-filter IN: " -A LogVpn -s 72.9.234.112/29 -d 3rd.par.ty.IP -j LOG --log-prefix "3-filter OUT: " -A LogVpn -j ACCEPT [ ... ] So, every packet is logged twice, once in raw and once in filter. And to ensure that all requests are replied, everything from 3rd.par.ty.IP is accepted before any other filter/FORWARD rules. > Results of the scan: all but y.y.y.39 were up. Logs: um, rather than > ask you to pick through all that, I'll summarise: Results of the scan from 3rd.par.ty.IP of 72.9.234.115-119 showed all but .118 is up. And the logs were pristine: "raw IN:" and "filter IN:" for each ICMP echo and HTTP request in perfect numeric sequence. After those were similarly-arranged "raw OUT:" and "filter OUT:" logs for ICMP and HTTP replies. The IN: packets all came in eth0, the OUT: ones all went out tun0, and the filter ones showed both interfaces properly. What is the difference here? Mainly OS and kernel, I think. Did I miss anything? So, any input here at all? Could this be an obscure bug in the Centos (RHEL) kernels? How to proceed? -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] OpenVPN, proxy ARP for an entire subnet (Linux endpoints)
is beyond me. What am I missing here? What can I try? One idea I had, was possibly to do proxy ARP on the HOME site too. Tell the HOME machines to use 192.168.255.37 as the default route in their vpn tables. That takes HOME_VPN_ENDPOINT routing rules out of the equation. Trying that now, similar intermittent results. ARGH!! -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Ip Src rewite.
On Tuesday 2005-October-25 17:03, Daniel Frederiksen wrote: > Well, yes my ISP has assigned me the two "classes", however the > a.b.c.d/30 is a single IP through which the e.f.g.h/26 are routed > through. The ISP is not routing the e.f.g.h/26 directly to the line, > but through the single WAN IP a.b.c.e/30.. > This is why all traffic going through is touched and marked as coming > from the WAN instead of the External IP address. What you describe sounds like NAT. Your gateway should be forwarding that traffic with the source IP unchanged. Can you show us tcpdump or iptables -j LOG of some of these packets' source IP being changed? I think we are missing part of the picture here. iptables-save; ip r l; ip ru l; ip a l # all those might help. Munge consistently if you feel compelled to munge. > >>>>NB: Small diagram of the setup. > >>>> > >>>> DMZ GW/FW ISP/Internet > >>>>- > >>>>-- Server #1 --| > >>>> e.f.g.h3/26 | > >>>> > >>>> | Gateway/Firewall --- ISP WAN IP: a.b.c.d/30 > >>>> > >>>> Server #2 --| a.b.c.d1/30 Ext. IP: e.f.g.h/26 > >>>> e.f.g.h4/26 e.f.g.h1/26 "DMZ" implies there is a separate subnet, and perhaps a SNAT'ed LAN, correct? You have 3 interfaces: internal, DMZ and external? Whether or not there is an internal doesn't directly affect this, but anyway, that is how I would set it up. Your DMZ machines should have e.f.g.h1 as their default gateway. Your router machine should have whatever the ISP told you to use as its default gateway (probably a.b.c.d2, I bet.) -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IPP2P version 0.8.0 released
On Friday 2005-October-21 01:57, Klaus wrote: > www.ipp2p.com is something I have never tested until now and it > looks quite different from my website... A cyber-squatter by the looks of it, waiting for you to offer huge sums of money for that domain name. -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] VPN through PPP
On Tuesday 2005-October-11 07:40, Steve Comfort wrote: > The setup is as below : Your ASCII diagram was not clear. > I have basically followed the VPN Howto and done the following : Are you talking about the old one from TLDP? > Any suggestions would be greatly appreciated. Perhaps not much help, but I use http://openvpn.org/ -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problems with ipp2p
On Friday 2005-October-07 08:29, Carlos Rosero wrote: > Thanks for the advice, how do in know if kernel module is loaded?, lsmod(8) > and how I do I load the module?. modprobe(8) I *strongly* urge you to take some time to acquaint yourself with the OS. You're trying to secure your network against abuse from within; this is normally a problem best handled on the political/social level. If you want to try to address it as a technical issue, you absolutely must know more about it than your users do. Start with Fedora documentation and branch out into applications and generic documentation as needed. -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] need help on multiple isp routing
On Monday 2005-October-03 09:37, Anonymous wrote: > configure is how to make those 2 links to use their own DNS servers, Why? > as ISP's1 servers do not answer queries from ISP's2 ip address and So? They're answering queries from your ISP1 address, no? Is this a problem? > vise versa. i run BIND (as caching and also for my local zone) on my > router configured to forward requests to ISP's1 DNS servers. i really > don't want to run 2 copies of BIND with forwarders of ISP2 as the > only difference in configuration. would anybody come up with a more > elegant solution on that issue? i'm sure it is not nice to specify Just don't use forwarders at all. wget the latest root hints file or just use what you have, for "type hints" for the "." zone. Forwarding is rarely a good idea. It gains you nothing. You won't increase the load on the root servers. > both ISP's servers as forwarders for a single server as the server > itself uses default gateway of ISP1. So this is not a problem, but still, forwarders are not helping you. > and then about services > installed on a router machine itself - ftp, www. they do not seem to > listen on ISP's2 ip. any solution besides configuring virtual > servers? I prefer Julian's approach to dual gateway routing ... his routes patch and the nano.txt HOWTO. That provides more of what people tend to want from multiple ISP connections in a more transparent way. All services use both links equally (or as weighted.) I'm sure there are situations in which splitting traffic by service or destination makes sense ... just not at my 3 dual-ISP sites. -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] iproute2/nano-howto: dual external routing, a "virtual subnet"
A site I administer has dual T1's. We have this set up according to NANO-HOWTO[1] using Julian's routes patch on a late model 2.4 kernel. All is well, has been working well for a long time. Recently one of our T1 providers went belly up and we got something better. Now we have a /28 where previously we only used one IP per interface. Present interfaces: eth0 - T1#1, single IP, x.x.x.52/24 (gw x.x.x.1) eth1 (Gigabit) - internal / trusted LAN, 192.168.27.1 eth2 - isolated/restricted access LAN (including wireless) 192.168.37.1 hdlc0 - T1#2, y.y.y.54/30 (gw y.y.y.53) [new netblock, y.y.z.144/28, is routed to y.y.y.54 ] tunX - numerous OpenVPN point-to-point tunnels, 192.168.4.x pppX - pptpd/pppd for external MS Windows users (due to be replaced by an openvpn server), 192.168.26.x eth1 and hdlc0 are set up as dual gateways, equal weight, following nano-howto to the letter (because I didn't know any better.) The plan is to use the new /28 for a mix of virtual user-mode Linux installs and openvpn endpoints to offsite peers. What we now have as 192.168.4.x will be converted to y.y.z.144/28. It will be similar to a DMZ in some aspects. I'm not sure how to do that without breaking the routing we have now. First thing I'm trying is to bind the /28 to dummy0. # ip ad ls 145: eth0: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:75:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet x.x.x.52/24 brd x.x.x.255 scope global eth0 146: eth1: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:02:b3:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.27.1/24 brd 192.168.27.255 scope global eth1 147: hdlc0: mtu 1500 qdisc pfifo_fast qlen 100 link/hdlc inet y.y.y.54 peer y.y.y.53/32 scope global hdlc0 148: eth2: mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:5a:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet 192.168.37.1/24 brd 192.168.37.255 scope global eth2 843: dummy0: mtu 1500 qdisc noqueue link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet y.y.z.145/28 scope global dummy0 844: tun0: mtu 1400 qdisc pfifo_fast qlen 10 link/ppp inet 192.168.6.46 peer y.y.z.146/32 scope global tun0 [superfluous interfaces omitted] # ip ru ls 0: from all lookup local 50: from all lookup main 201:from x.x.x.0/24 lookup 201 202:from y.y.y.54 lookup 202 222:from all lookup 222 32766: from all lookup main 32767: from all lookup default # ip ro ls y.y.y.53 dev hdlc0 proto kernel scope link src y.y.y.54 y.y.z.146 dev tun0 proto kernel scope link src 192.168.6.46 y.y.z.144/28 dev dummy0 proto kernel scope link src y.y.z.145 192.168.27.0/24 dev eth1 proto kernel scope link src 192.168.27.1 192.168.37.0/24 dev eth2 proto kernel scope link src 192.168.37.1 x.x.x.0/24 dev eth0 proto kernel scope link src x.x.x.52 [superfluous routes omitted] Success!! I played around with this off and on all day, and now it works. I turned on /proc/sys/net/ipv4/conf/dummy0/proxy_arp (how can the interface be flagged NOARP and yet do proxy ARP?) on that end and set up a route table on the other end: echo "32 vpn" >> /etc/iproute2/rt_tables ip ru add add from y.y.z.146 table vpn ip ro add default via 192.168.6.46 table vpn The services which are exposed in the firewall are accessible through y.y.z.146. Very nice! But I'm still not sure about some things. I want to understand better. I'm also not sure it will work right. A lot of this is new to me, so please bear with me. Is the use of dummy0 needed? ISTM it was just a simple way to get the routing tables set up. And it's probably wasting 3 IP's: .144 network, .145 dummy0, and .159 broadcast. With these IP's all coming through y.y.y.54 as they are, is there any reason why I can't use the network and broadcast addresses for (virtual) hosts? With proper routes and an "ip neigh add ..." command I shouldn't need dummy0 here, right? But I don't know what to do. Do I need a similar route table on the dual-T1 end? Do I need to do something to force y.y.z.144/28 out hdlc0? I guess it might not matter depending on the eth0 ISP's upstream router x.x.x.1; if it lets the packets from the hdlc0 ISP's netblocks pass, no one downstream is likely to know or care, right? Numerically, where should such a table go? And now, here's the biggie ... if we got a netblock from the other ISP, could we set up these virtual hosts to bind to one IP from each ISP, and thus gain the redundancy? Having lots of fun; I hope you are too. :) [1] http://www.ssi.bg/~ja/nano.txt -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] how to configure linux in production line
Gonn Star wrote: I am new in linux world,basically I'm using red hat 9 kernel 2.4.20-8. I need to build a trusted gateway. my Whoa! You are starting out with something very old and bug-ridden. You should scrap that and switch to a current release, whatever distro you may choose. Quite a few of those old bugs can bite very hard, including root compromises. Being new, did you know how to update for security? Sure, there's Fedora Legacy which may or may not be supporting the old stuff with updates, but that is intended for people who have long-running stable servers ... not to entice new users to RH 9. linux box will be the gateway for several machine PCs to go to the desired server. there will be several subnets under the linux box, I've already assigned static IPs for the PCs . Now my problem is I only need 2 PCs from each subnets to connect to certain servers, and those 2 PCs can only have transaction(open) to the specified servers, for others it will drop(firewalled). for other PCs, they can't log on to the outside world. should I use only iptable rules or with the help of squid(ACL) as well ? You do not seem to understand that HTTP is just one of many TCP/IP protocols, and yet you want to set up complex networking controls. Anyone who knows more than you do would likely find it a trivial task to get around your controls. please add up the commands as well. Thanks. Specific questions which show that you have tried will tend to be better-received than generalised requests for spoonfeeding. I do things like this for a living, and I do not have time to earn your living as well. You mention "production" which implies that this is needed in a business setting. If so it's probably worth it to the business owners to pay for expertise. You can't learn everything you need to know, overnight. For you, I would recommend starting with the basics. There are good HOWTOs at netfilter.org which might help. -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] NAT over 2 providers (not load balance)
On Monday 14 February 2005 14:27, Mihai Vlad wrote: > Hi guys, > > Can you take a look at this? :) > > I need to selectively SNAT clients in the LAN to ISP_IP_1 or > ISP_IP_2. > > That would be something like: > $IPTABLES -t nat -A POSTROUTING -s 172.17.31.5 -j SNAT --to-source > $ISP_IP_1 > $IPTABLES -t nat -A POSTROUTING -s 172.17.31.7 -j SNAT --to-source > $ISP_IP_2 > > This does not work since all the packets are forwarded to the default > GW which is ISP_GW_1. I think you still need the patches and routing commands as described in the nano.txt file. You'd just plug in your customised SNAT rules in place of the load-balancing ones. I have a nano.txt'ed site with some special SNAT like this. I think some of my $ISP2_IP_2 (2nd and subsequent IP's on ISP2) packets are going out over ISP1's physical interface. I have not bothered to check because it's working fine. :) -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Connection tracking flush
On Wednesday 12 January 2005 10:07, Mpourtounis Dimitris wrote: > Is there a way i can flush the connection tracking on my box (after a > restart in iptables)? > If the connection tracking module is unloaded and reloaded, my job > will be accomplished i think. Only way I know of, other than reboot. > The bad thing is i want this tracking > module to exist in kernel code and not loaded as a module. Why? What's the advantage in that? Maybe if it's a tiny embedded device, but in that case the reboot options sounds viable. -- mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
