I''ve kept this one on the back burner for a while, waiting for it to mature before attempting to use it, and now having seen OpenBSD ship with IPSec I''m getting a bit impatient =). What is the status of IPSec for Linux (and more specifically RedHat)? By this I mean I just did some www browsing/etc and found about a half dozen different implimentations, ranging from NRL, to a nist patch for RedHat 5.1, swan, ipnsec, etc, etc. Does RedHat have any official word on this? I know including IPSec would be a pain in the butt, being that they are in the US (OpenBSD moved their official head end distribution site to the local university, cared for by the guy who is also head of the local LUG... go fig). I''m going to be experiementing with the various IPSec packages for Linux (specifically under RedHat 5.1) and will post any positive results back to the list, I would also appreciate anyone else who has experiemented with IPSec under Linux to do likewise. It''s rather simplistic to say but basically true that using IPSec would solve many many security problems and risks that we currently suffer (have you ever tried implimenting kerberoes? not fun). -seifried
At 01:02 PM 8/5/98 -0600, seifried wrote:>What is the status of IPSec for Linux (and more specifically RedHat)? > >Does RedHat have any official word on this? I know including IPSec >would be a pain in the butt, being that they are in the US (OpenBSD >moved their official head end distribution site to the local university,Try impossible. RedHat would not be able to export RedHat IPSec from US/Canada, without a license, which US Dept of Commerce BXA doesn''t grant unless you''re a bank (basicly). But you could expect a rpm from replay.com. :) The OpenBSD project is based out of Canada, and so is not encumbered by the US''s export laws. I''m surprised at the lack of excitement over IPSec for Linux, back when I first read (circa ''96) John Gilmore''s swan page I figured within a year it would be in common usage. -mctaylor
M Taylor wrote:> > At 01:02 PM 8/5/98 -0600, seifried wrote: > >What is the status of IPSec for Linux (and more specifically RedHat)? > > > >Does RedHat have any official word on this? I know including IPSec > >would be a pain in the butt, being that they are in the US (OpenBSD > >moved their official head end distribution site to the local university, > > Try impossible. RedHat would not be able to export RedHat IPSec from > US/Canada, without a license, which US Dept of Commerce BXA doesn''t grant > unless you''re a bank (basicly). > > But you could expect a rpm from replay.com. :) > > The OpenBSD project is based out of Canada, and so is not encumbered by the > US''s export laws. > > I''m surprised at the lack of excitement over IPSec for Linux, back when I > first read (circa ''96) John Gilmore''s swan page I figured within a year it > would be in common usage.IPSEC isn''t done being standardized yet. It would be reasonable to track the standard, but it''s also reasonable to wait until you aren''t implementing a moving target. However, earlier today I saw the "post last call" internet draft announced, so it shouldn''t be long before IPSEC is finally an RFC. Does Debian have enough volunteers/resources outside the US to fully integrate an IPSEC implementation?
Hi, I have some questions concerning the ipfwadm and RedHat. I''m building a firewall for a small cie, and propose using a bare RedHat 5.1 (without any mean to connect to it, except through sshd) and have it acting as a firewall between the DMZ and the internal network. I plan to do this only using the ipfwadm utility (IP filtering + masquerading). No redirs inside the internal network, and permissions for everyone inside to contact anyone outside. No java, activex or javascript filtering. What are the downs/ups of such a config. How could someone gain access to a computer inside the firewall, is there any way? (most are NT Wks 4.0 in PDC BDC environment) Anything I should pay special attention? I''m planning to use a logchecker and tripwire to report anything unusual. Any comments will be appreciated. If someone else is interested, I''ll post a resume of all the answers I''ll be getting to the list. Thanks!
Andrew S. Prior wrote:> > > I know about how masq works, I already have built one network using it. I > > > have 15 computers inside my ip+masq firewall, with the fake ip c class > > > 192.168.x.x, and 5 computers in a normal class C on the outside. It works > > > great! My only concern really is that I want to know if there is any way > > > for a hacker to directly connect to one of my protected computers from the > > > outside. > > > > No, but one of the protected computers could connect to the hacker. > > And one of the protected computers can breach your firewall as well. If > somebody runs a port forwarder like ssh they can connect to a remote server > and ask for certain ports on that server to be re-routed via ssh to the > protected computer. The protected computer could then even be used as an > IP tunnel with a little creativity (I don't think ssh does that). > > I think with linux, ssh, masquerading, and routing tables I could set up > a machine inside a firewall that would give me full access to the inside > of the firewall (anything the linux box could talk to) from my chosen > arbitrary remote destination, just like I was there. Of course, you need > to get *in* first to set it up and it would be simpler to telnet in (via > a forwarded port) and run things locally.Sure. If you have sufficient permission on a host on the inside of the firewall which has any Internet connectivity whatsoever, then you can use that connectivity to run an IP tunnel. The only thing which will prevent that is total disconnection. -- Glynn Clements <glynn@sensei.co.uk>
Duncan Simpson wrote:> > That's the kind of questions I'm asking myself and haven't > > seen any answers about them. Some friend of mine says he heard of a way to > > circumvent a masq firewall and access a computer inside, but that's as far > > has he remembers. > > The probable method is some form of IP source routing.Source routing will enable you to get a packet to the masq firewall, even if the destination address is a private address. The route which you would need to specify from the masq firewall to the victim would usually be the route which the packet would take anyhow. If you are running a masq firewall, you would normally disallow any other forwarding (replies to masqueraded packets are demasqueraded and forwarded automatically), so even if you can get the packet to the masq firewall, you're unlikely to get it any further (even without the `drop source-routed packets' option. -- Glynn Clements <glynn@sensei.co.uk>
fire fire wrote:> > > > That's the kind of questions I'm asking myself and haven't > > > > seen any answers about them. Some friend of mine says he heard of a way to > > > > circumvent a masq firewall and access a computer inside, but that's as far > > > > has he remembers. > > > > > > The probable method is some form of IP source routing. > > > > Source routing will enable you to get a packet to the masq firewall, > > even if the destination address is a private address. The route which > > you would need to specify from the masq firewall to the victim would > > usually be the route which the packet would take anyhow. > > > > If you are running a masq firewall, you would normally disallow any > > other forwarding (replies to masqueraded packets are demasqueraded and > > forwarded automatically), so even if you can get the packet to the > > masq firewall, you're unlikely to get it any further (even without the > > `drop source-routed packets' option. > > Hey WHAT if: > 1. my inner net is 10.0.0.0/8 and I have *source route* enabled! Then a route of > this would be possible: > X.X.X.X > 10.0.0.1 > 10.0.0.Y > > Where X.X.X.X is the gateway the INTERNET sees and the 10.0.0.Y is the host in > question you want to > connect to! > The only thing a *person* would need to figure out is *somehow* to see what are > the numbers of IP used > in the inner net and try some things on your gateway!This would require the gateway to permit forwarding of inbound packets. Given that replies to masqueraded packets are automatically demasqueraded and forwarded, there is no reason to permit forwarding of inbound packets. Given that the poster described the gateway as a firewall, it seems reasonable to assume that it doesn't allow forwarding of inbound packets. Using: ipfwadm -Fp reject ipfwadm -Fma accept -S 10.0.0.0/8 would prevent this (assuming that you've also prevented IP spoofing), regardless of whether source routing is permitted. -- Glynn Clements <glynn@sensei.co.uk>