April 2002 - openSUSE Security - openSUSE Mailing Lists

suse firewall and VPN
by Wagner, Uwe 26 Apr '02

26 Apr '02

Hi, I want to use a VPN connection from my windows pc through my suse firewall to another pc in the internet. Is there the need to install freeswan on my firewall or can I just open the needed ports ? (which ports must be opened ?) thanks uwe <<Wagner, Uwe.vcf>>

4 7

proftpd
by Thomas Neukirch 26 Apr '02

26 Apr '02

hi list, can someone please tell me how to configure the proftpd.conf that only one user (with password) can login via ftp and the other users (i.e. ftp, anonymous) are disabled ? thanks --------------------------------------------------------------------------- Thomas Neukirch (Systemadministrator) email: thomas.neukirch(a)dtvtabak.de tel.: 02234-96310-26 fax: 02234-96310-22 www.dtvtabak.de

2 1

RE: [suse-security] SuSE personal Firewall 1.1-4 / ppp*
by Reckhard, Tobias 26 Apr '02

26 Apr '02

> I've been lurking around for a while and followed this > discussion with > interest. I have the problem here that reloading the firewall > rules after > connecting to mu ISP takes so long (about 12-15 seconds), > that for instance > my DNS times out and gives up because the firewall is > dropping the responses > which it should get. Yes, I know that upgrading to a more > powerfull computer > might also fix this delay, but I hate to upgrade the 'ol > Pentium 133 which > handles internet traffic via ISDN, just because reloading the > firewall rules > takes too long, while it is running idle most of the time > (even once the > connection is established and the firewall rules are reloaded). If you have many rules then iptables' and current way of modifying the chains will cause long delays when manipulating chains. The problem a colleague of mine found in the source code and that Rusty et al. are well aware of is that for each and every iptables [-A|-D|-I|-R] operation, the chain in question in memcopied as two halves, separated by the space where the manipulation is taking place. That is applied and then everything is memcopied into kernel memory (or maybe they merely change a pointer, I don't know). The point is that for each and every iptables line in a script, this procedure takes place. iptables-restore doesn't suffer from this drawback, BTW. You'll notice the COMMIT statement at the end of the output of a file created with iptables-save. However, I think you need to have a considerable number of rules for the effect to become as noticeable as you say, even on a P133.. But I haven't checked it out on that kind of a machine yet. >From a security point of view, though, you're safer the way it is than if the box would be open during those 15 seconds. > What puzzles me, is how filtering based on information > received from my ISP > (the local IP) might give additional protection against a > spoofing via the > same ISP. If someone manages to attack the servers at my ISP > and manages to > spoof an address, how can I trust ANYTHING which is coming > from there. In > this case, the local IP which is handed out via DHCP. Oh, I wouldn't trust anything (purportedly) coming from the ISP. You don't have a choice but to accept their DHCP lease, though. There is no alternative other than to get a fixed IP address[1]. > I bluntly changed the SuSEfirewall2 script to allow traffic > with a local > destination for any of the local IPs I might get (a query to > whois gave me > all local addresses I may get from my ISP) even before the > connection is > made. As long as the destination is within this range, this > prevents me from > having to reload the firewall rules when I connect to my ISP. > I don't expect > my ISP to change this range very frequently, so this should > (and does so far) > work most of the time. Am I missing something important here? Define important. But you're probably not risking terribly much more. I believe you could filter based on the exact destination address and not experience dropouts simply by inserting the entire rulebase with the modified IP address in front of the old one, then deleting the 'old' rules. You'd have to be careful not to miss any, since you can't use the flush command. I guess this may not be possible with SuSEFirewall2, but I can't say -- I haven't used it myself yet, up to now I've always rolled my own. Cheers Tobias [1] This general statement if, of course, not entirely true. It is absolutely possible to create 'secure' mechanisms for functionality equivalent to DHCP. But you probably won't find any ISP who will cooperate.

1 0

postfix regexp in body_checks
by Philipp Snizek 25 Apr '02

25 Apr '02

Hi, I hope I hit the right list with my request. I'm trying to set up a filter for postfix to filter malicious stuff like all windows executables. For MIME encoded headers I had no problem, this works fine. But if the header is uuencode, the attachment is only visible in the e-mail's body. I tried a regexp like /.*\.(bat|exe|cmd|vbs|vba)/ REJECT in /etc/postfix/body_checks which should filter all *.bat|and so on. But nothing at all happens. Mails go thru as if there wasn't an obstacle. If there is some postfix & regexp pro on this list, please tell me what I am doing wrong. Thanx, Philipp

9 16

boot option
by Thomas Futschek 25 Apr '02

25 Apr '02

Hi list! Recently I saw if you boot a kernel with a boot option like 'init=/bin/bash' (to example: linux init=/bin/bash) you become root without athentification. Can anybody tell me why it works and how I protect? Thanx! Thomas -- Have A Nice Day -- ________________________________________________________________ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13

8 8

RE: [suse-security] SuSE personal Firewall 1.1-4 / ppp*
by Reckhard, Tobias 25 Apr '02

25 Apr '02

> > The antispoofing rules, at least, need to be rewritten when the > > IP address changes. > > AFAIK "antispoofing" means to drop packets with source addresses > which come from the wrong interface. Not quite. Spoofed IP packets have false addresses, i.e. source or destination addresses or both. When talking about anti-spoofing, people usually use the terms 'egress filtering' and 'ingress filtering' to mean filtering of outbound and inbound packets respectively. When considered alone, it makes sense to check both source and destination addresses. The source addresses are of higher importance, though. > At least in a common > configuration (internal LANs with static addressing and a > dialup/DSL/cable uplink) I don't see why the antispoofing rules > should change when the local IP address changes. If you wish to use the IP address of local machines (including and sometimes restricted to the gateway) as qualifiers in your packet filtering rules, you need to update those along with the IP address. > And let me repeat, if you don't trust your ISP, you don't know if > you get the correct IP assigned, but if you do, you know that the > ISP router will route the correct packets (destination based). Have you never seen a confused or misconfigured router? What happens when someone breaks into the ISP and changes the configuration of their equipment? Break into an ISP router and configure it to establish GRE tunnels and you've got some very hefty potential problems. It's not about trusting or not trusting the ISP. The problem is that you have practically no influence on their security. OTOH, you have full control over your own systems and you can apply security measures to suit your degree of paranoia. With the ISP's equipment, your options are considerably fewer, very often none. > Well, and since the source addresses are unaffected by your local > IP, nothing changes. Usually you may get just *any* IP assigned, > and by that you can filter with any as local IP. That's possible and swinging the balance between security and ease of use towards the latter by some measure I don't wish to discuss. If you can't or are unwilling to do without the IP address information, you need to update the packet filter configuration whenever that changes. > Since at the last time we had such a thread and nobody had a > situation requiring rule rewriting (not counting very exotic > setups), I still think there is no need for such rewrites in a > clean configuration. As long as everything is properly configured, yes. But security has a concept called 'defense in depth'. If you follow that concept, you will have redundant, overlapping mechanisms. All but one are unnecessary as long as that one left doesn't fail. But what if it does? This, of course, leads to compromise. Those with the need for high security use many layers of defence, those with assets of lower value (or those that don't care or know better) employ fewer layers. In the end it's always a question of cost. Cheers Tobias

3 2

Re: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...which isbetter for firewall?
by Bill.Light＠kp.org 25 Apr '02

25 Apr '02

Hi Jeric Just an opinion.... I am right now playing with SuSE 8.0, the default kernel is 2.4.18. For your firewall - I believe iptables is the way to go....but get it from SuSE 7.3 and there is an update to 2.4.16 kernel for 7.3 This 8.0 seems to big and clumsy for a 486. - Bill "jeric" <jeric(a)mmcable.com> 04/24/02 04:40 PM To: <suse-security(a)suse.com> cc: Subject: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...which is better for firewall? Hi, Since SuSE 8.0 is coming out, I am toying with the idea of upgrading my firewall/router box. It is currently running 7.0 with kernel 2.2.19 and ipchains. Is the upgrade to the better iptables worth also porting over to the less mature 2.4.x kernel? At this point in those two kernel developments, is there still a security/maturity difference? And if I upgrade to 8.0 will I be able to still install it on an x486 with 64MB RAM, box using the minimal install option? I read that the default install GUI will not run on an old x486, but was not sure about the minimal install option. Also, if upgrading to SuSE 8.0, which kernel does it install by default? Thank you, jeric

5 6

RE: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...w hich is better for firewall?
by Reckhard, Tobias 25 Apr '02

25 Apr '02

The following is entirely personal opinion. > Since SuSE 8.0 is coming out, I am toying with the idea > of upgrading my firewall/router box. I prefer not to update distributions, but rather perform fresh installs, if tolerable. I've had a couple of problems when updating in the past, but I've forgotten the specifics. > It is currently running > 7.0 with kernel 2.2.19 and ipchains. Is the upgrade to the > better iptables worth also porting over to the less mature > 2.4.x kernel? It is debatable whether ipchains is *better* than iptables. Actually, you can never claim anything to be better than something else without specifying a metric. You will certainly find quite a number of people of the opinion that ipchains is more secure or even gives more security than iptables. You'll find a considerable number that say the opposite. It's up to you to form your own opinion. > At this point in those two kernel > developments, is there still a security/maturity difference? That depends on your measure. I prefer iptables to ipchains, but I'm not sure I trust it as much, especially the connection tracking code. There have been numerous bugs in the masquerading helpers and coding them isn't always exactly easy. Connection tracking modules are very similar to masquerading modules. I am convinced that there is a wide range of security between the different conntrack and masq modules... As far as the maturity of the kernels go, I haven't had any problems with the 2.4.10 or 2.4.16 kernels supplied by SuSE for the 7.3 distro yet. I did have some strange phenomena with earlier ones, but at least one of those was a Mantel kernel, which are clearly labelled as experimental-grade. I have pretty unspectacular machines, though, and don't use many of the fancy new kernel options. BTW, I know of a problem on a SuSE 7.0 machine with the reiserfs release on it. Seems that postfix relies on the kernel filesystem driver to report a certain error code when checking for maximum message size and some versions of reiserfs supply the wrong code. I don't know if there's an update from SuSE that rectifies the problem. I do know that the current iptables release in SuSE 7.3 has a buggy iptables-save, which creates '--reject-with reject-with' instead of '--reject-with tcp-reset'. I find this a very annoying bug and it rather unfortunate that SuSE haven't released an update yet. However, I have only informed Roman about this problem per email and haven't made any further efforts to get the problem solved -- I expected the iptables in SuSE 8.0 to be absent of this bug and have been waiting for it. But this is a problem I have with SuSE or, more specifically, with their policy of mostly patching the source code of packages they originally used when building a distro and not releasing more current versions of the original packages (i.e. the tarballs) as updates. Security-critical bugs are fixed, but my impression is that functional bugs aren't rectified as quickly, if at all. And you seldom get the features a new release of the tarball package contains. It's probably unreasonable to expect SuSE to provide updates to all software packages in the distro for its entire lifetime. I have a feeling RedHat RPMs are compatible across major version numbers, maybe this would be a beneficial compromise. However, that could also involve disadvantages I haven't though of. > And if I upgrade to 8.0 will I be able to still install it on > an x486 with 64MB RAM, box using the minimal install option? I suppose you should be able to install it. I can't say how well it'll run. I recommend against the use of KDE or Gnome, if X at all. > I read that the default install GUI will not run on an old > x486, but was not sure about the minimal install option. I don't know if it checks the CPU (don't think so), but it won't run on machines with less than 64 MB RAM. So it should attempt to run on your machine. > Also, if upgrading to SuSE 8.0, which kernel does it > install by default? 2.4.18, as someone else has also already said. Cheers Tobias

1 0

SuSEfirewall and licq 1.1.0
by curtain 25 Apr '02

25 Apr '02

hi list, i am using linux 7.1 pro with a 2.2-kernel. i masquerade my internal network with the firewall (ip range 192.168.0.1 to .4); and i use an isdn dialup connection. i thought that the firewall _really_ masquerades my lan; but when i watched myself being online from a friend's box running licq 1.1.0, licq told me - apart from the external ip beginning with 62. - my private ip :( if licq is capable in looking behind that firewall, how can i assure that _real_ hack programs cannot do this ... i suggest that icq delivers all ips that it can gather; but don't other apps also??? how can i tell the firewall not to submit internal ip names - well - is the fw able to do it? -- icq# 67532578; return 0;}

3 2

[suse-security] suse firewall and VPN
by Tobias Korb 25 Apr '02

25 Apr '02

Hi, > > I want to use a VPN connection from my windows pc through my suse firewall > to another pc in the internet. > Is there the need to install freeswan on my firewall No, you dont`t need but perhaps it is better to do so your hole lan can use this vpn connection freeswan is ipsec... do the vpn server in the internet use ipsec??? > or can I just open the needed ports ? (which ports must be opened ?) which vpn do you want to use?? ipsec??? pptp/chap??? there are so many vpn versions with so many difficult ports!! mfg tobi sorry my englisch isn`t so good

1 0