I finally got around to switching to SuSEfirewall2. Installation and setup were straightforward, and my testing sems to indicate it's doing what I expect... However, I'm now seeing the following messages in /var/log/messages as I bring up, and again as I terminate a ppp session (using kppp): /etc/ppp/ip-down: ip-down: Loading of module ipchains was not successful. /etc/ppp/ip-down: Aborting. No action taken. A search of /etc/ppp/ip-up, ip-up.local, and SuSEFirewall2 shows the only reference to the ipchains module is an attempt to `rmmod` it. Is this message simply an obfuscated way of saying that it couldn't be removed because it wasn't loaded? -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
I finally got around to switching to SuSEfirewall2. Installation and setup were straightforward, and my testing sems to indicate it's doing what I expect...
However, I'm now seeing the following messages in /var/log/messages as I bring up, and again as I terminate a ppp session (using kppp):
/etc/ppp/ip-down: ip-down: Loading of module ipchains was not successful. /etc/ppp/ip-down: Aborting. No action taken.
This output is from the SuSEpersonal-firewall (which works with ipchains in SuSE-7.2 only). It tried to load the ipchains module, which does not work if the iptables framework has been loaded before. SuSEfirewall and SuSEpersonal-firewall can work together, but SuSEfirewall2 needs iptables. By consequence, you must disable the SuSEpersonal-firewall in /etc/rc.config.d/security.rc.config (Set REJECT_ALL_INCOMING_CONNECTIONS="no"). SuSE-7.3 comes with a personal-firewall package that can work with both iptables and ipchains. None of the scripts should remove modules from a running kernel since this is inherently racy, and SuSEpersonal-firewall does not remove modules at all. SuSEfirewall2 does, the version in 7.3 is a bit more careful and will not remove loaded iptables modules any more because of the likelyness of a kernel crash (fixed in the last beta phase of 7.3).
A search of /etc/ppp/ip-up, ip-up.local, and SuSEFirewall2 shows the only reference to the ipchains module is an attempt to `rmmod` it. Is this message simply an obfuscated way of saying that it couldn't be removed because it wasn't loaded?
No, the other way around.
Please add a line for SuSEfirewall2 to ip-up that resembles the one for
SuSEfirewall so that the fw-script is being executed upon dial-in.
Thanks,
Roman.
--
- -
| Roman Drahtmüller
On Fri, 5 Oct 2001, Roman Drahtmueller wrote:
/etc/ppp/ip-down: ip-down: Loading of module ipchains was not successful. /etc/ppp/ip-down: Aborting. No action taken.
This output is from the SuSEpersonal-firewall (which works with ipchains in SuSE-7.2 only). It tried to load the ipchains module, which does not work if the iptables framework has been loaded before. SuSEfirewall and SuSEpersonal-firewall can work together, but SuSEfirewall2 needs iptables. By consequence, you must disable the SuSEpersonal-firewall in /etc/rc.config.d/security.rc.config (Set REJECT_ALL_INCOMING_CONNECTIONS="no"). Oops. I thought I had replaced the personal-firewall package with the SuSEfirewall package. I hadn't - it was still installed. `rpm -e personal-firewall` took care of the problem.
SuSE-7.3 comes with a personal-firewall package that can work with both iptables and ipchains. None of the scripts should remove modules from a running kernel since this is inherently racy, and SuSEpersonal-firewall does not remove modules at all. SuSEfirewall2 does, the version in 7.3 is a bit more careful and will not remove loaded iptables modules any more because of the likelyness of a kernel crash (fixed in the last beta phase of 7.3). Why would one want to run both personal-firewall and SuSEfirewall(2)? The latter gives much finer-grained control, and is capable of blocking all connections, if so configured.
Please add a line for SuSEfirewall2 to ip-up that resembles the one for SuSEfirewall so that the fw-script is being executed upon dial-in. It was already there. SuSEfirewall2 is getting loaded, and apears to be working. It was just that unexpected ipchains message caused by the vestiges of personal-firewall that prompted my question.
Thanks for your help. -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
Recently, a friend of mine (who actually runs BSD, and has one windows box behind his firewall) observed something and warned me about it, and I thought I should pass the warning along. My friend Chris had set up his windows box, but, being more than usually sensible, he configured his firewall to check *OUTGOING* packets and filter them on content -- specifically, not allowing packets to go out if they contained identifying information about his windows machine or the software installed on it, or cleartext passwords. This is good practice simply because if something behind your firewall gets infected, odds are that it's going to try to send out lots and lots of packets, or report configuration/passwords/etc back to its creator, and a well-configured firewall is supposed to stop it. But when he started up Media Player, the firewall, in his words, "lit up like a christmas tree." As it turns out there are some windows applications that "phone home" with information you'd really rather not have people outside your firewall pawing through, including passwords in cleartext, lists of software installed, etc. And media player is one such. Increasingly, as commercial and closed-source software for linux becomes available, monitoring for this kind of abuse will become even more relevant. It seems that it's already quite a problem if you run windows boxes behind your firewall. So set up a good firewall that filters outgoing packets on content, as well as incoming packets on port number. Bear
how did he do this? i mean, how did he configure it to not send clear text passwords? I can understand if he blocked outgoing ports 21 and 23 as these (ftp and telnet) use clear text passwords, but that will create problems because you could not even get to anonymous ftp sites then. What about web forms - these are usually clear text, how did he block that? I have setup firewalls before, but have never tried to get the to block based on content. i just dont see how it could be done. you would be adding rules to the firewall constantly. im sure media player and some other programs do phone home when they are fired up, media player and winamp do this (along with some other instant messaging programs) to see if newer programs are available. i would be interested to know how your friend is firewalling based on content. On Fri, 5 Oct 2001, Ray Dillinger wrote:
Recently, a friend of mine (who actually runs BSD, and has one windows box behind his firewall) observed something and warned me about it, and I thought I should pass the warning along.
My friend Chris had set up his windows box, but, being more than usually sensible, he configured his firewall to check *OUTGOING* packets and filter them on content -- specifically, not allowing packets to go out if they contained identifying information about his windows machine or the software installed on it, or cleartext passwords.
This is good practice simply because if something behind your firewall gets infected, odds are that it's going to try to send out lots and lots of packets, or report configuration/passwords/etc back to its creator, and a well-configured firewall is supposed to stop it.
But when he started up Media Player, the firewall, in his words, "lit up like a christmas tree." As it turns out there are some windows applications that "phone home" with information you'd really rather not have people outside your firewall pawing through, including passwords in cleartext, lists of software installed, etc. And media player is one such.
Increasingly, as commercial and closed-source software for linux becomes available, monitoring for this kind of abuse will become even more relevant. It seems that it's already quite a problem if you run windows boxes behind your firewall.
So set up a good firewall that filters outgoing packets on content, as well as incoming packets on port number.
Bear
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Chad Whitten Network/Systems Administrator neXband Communications chadwick@nexband.com
On Fri, 5 Oct 2001, Ray Dillinger wrote:
But when he started up Media Player, the firewall, in his words, "lit up like a christmas tree." As it turns out there are some windows applications that "phone home" with information you'd really rather not have people outside your firewall pawing through, including passwords in cleartext, lists of software installed, etc. And media player is one such.
So set up a good firewall that filters outgoing packets on content, as well as incoming packets on port number. I, too, would like to know how to go about creating such a filter using iptables. The ZoneAlarm package for Windows filters based on program name for outgoing connections, but I have not seen anything short of a sniffer or tcpdump that will look at the packet content itself. I can't even imagine the processor overhead required to parse the content of every outgoing packet! Does iptables have access to the pid of the originating process? Would a filter which used the pid, looked at /proc/<pid>/cmdline, and checked an 'allowed program' list like ZoneAlarm does, incur too much overhead to be
This is a well-known phenomenon. See the writeup on www.grc.com about 'Trojan Spyware'. Much of the objection to WinXP is that it forces this behaviour, under the guise of 'verifying the license'. If you don't connect to the internet, and allow it to phone home periodically, the OS simply shuts down. If you're running a business, your entire business is effectively held hostage until you get 'validated' by microsoft... practical? Of course, this approach works only for a 'personal firewall' where the originating process and the firewall are on the same machine, and is meaningless on a standalone firewall protecting a LAN. -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
This is a well-known phenomenon. See the writeup on www.grc.com about 'Trojan Spyware'. Much of the objection to WinXP is that it forces this behaviour, under the guise of 'verifying the license'. If you don't connect to the internet, and allow it to phone home periodically, the OS simply shuts down. If you're running a business, your entire business is effectively held hostage until you get 'validated' by microsoft...
You don't have to run XP. If you don't like a product don't use it. I'm so sick and tired of people bitching about MS, especially on non MS security mailing lists!
I, too, would like to know how to go about creating such a filter using iptables. The ZoneAlarm package for Windows filters based on program name for outgoing connections, but I have not seen anything short of a sniffer or tcpdump that will look at the packet content itself. I can't even imagine the processor overhead required to parse the content of every outgoing packet!
IPTables allows you to filter based on uid/gid. for example most users will probably only ever go out to port 25, 53, 80, maybe 110/143, 6667, etc. As for parsing packets, uhh, you ever heard of snort? or any other NIDS for that matter? It's actually a reasonable amount of overhead if done right. And yes, you can do it at gigabit speeds.
Does iptables have access to the pid of the originating process? Would a filter which used the pid, looked at /proc/<pid>/cmdline, and checked an 'allowed program' list like ZoneAlarm does, incur too much overhead to be practical?
Uhhh well that would be a lot of overheard. And I would just write a script called netscape that invokes something else. Unlike Windows it is much harder to subvert a Linux box, assuming people do not log in as root and do stupid things like run/install software from untrusted sources. OTOH some popular Linux apps "phone home" and no-one seems to complain (like pine for example).
Of course, this approach works only for a 'personal firewall' where the originating process and the firewall are on the same machine, and is meaningless on a standalone firewall protecting a LAN.
I could answer this, but I'm writing a rather large paper on the subject and am sick to death of it already =). BTW MS proxy allows you to do stuff like this (i.e. group sales is only allowed http and https access, no irc for those naughty little monkeys).
-- Rick Green
Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
On Sat, 6 Oct 2001, Rick Green wrote:
I, too, would like to know how to go about creating such a filter using iptables. The ZoneAlarm package for Windows filters based on program name for outgoing connections, but I have not seen anything short of a sniffer or tcpdump that will look at the packet content itself. I can't even imagine the processor overhead required to parse the content of every outgoing packet!
iptables/ipchains doesn't have the ability to look into packets, so it can't really be used for this. I quizzed him about it yesterday. The packet filter provided by zeroknowledge (which runs on the windows box) has the capabilities to look into the packets and match against regular expressions provided by the operator, and that was the one that lit up when he started media player. On the BSD firewall, he's using BPF (Berkeley Packet Filter), which bounces packets through a user-supplied filtering program. The user-supplied filtering program, in this case, is a ten-line "main" routine plus a parser created by lex (flex, to linux systems). The parser is a routine called yylex, which efficiently implements a search for any of the regular expressions provided by the operator. So, it's not actually protocol-parsing, but it is looking for packets that contain regular expressions he's provided, which include such things as program names, passwords, email addresses, etc. Obviously there is overhead, but the outgoing packets stream is quite small compared to the incoming packet stream, and he says it's not a problem. Ray Dillinger
iptables/ipchains doesn't have the ability to look into packets, so it can't really be used for this.
Now I am starting to get annoyed. Yes, IPTables can inspect packets. Suggestion: get a recent version and check out the "string" keyword.
I quizzed him about it yesterday. The packet filter provided by zeroknowledge (which runs on the windows box) has the capabilities to look into the packets and match against regular expressions provided by the operator, and that was the one that lit up when he started media player.
Moot point, ZK is dead. Dead'er then a flat squirrel. Something else you can do: use snort to inspect packets and then use a snort add on to block the packets dynamically (not that I strongly advocate this as it can lead to potential DoS). -Kurt
On Sat, 6 Oct 2001, Kurt Seifried wrote:
Yes, IPTables can inspect packets. Suggestion: get a recent version and check out the "string" keyword.
Cool! I wasn't aware of that.
I quizzed him about it yesterday. The packet filter provided by zeroknowledge (which runs on the windows box) has the capabilities to look into the packets and match against regular expressions provided by the operator, and that was the one that lit up when he started media player.
Moot point, ZK is dead. Dead'er then a flat squirrel.
Rumors of their death have been exaggerated. They no longer provide the anonymous browsing/pseudonymous email service they were known for, but they do still provide their firewall software, including the packet filter.
Something else you can do: use snort to inspect packets and then use a snort add on to block the packets dynamically (not that I strongly advocate this as it can lead to potential DoS).
.... hmmm... bear@www:~>man snort No manual entry for snort bear@www:~>apropos snort snort: nothing appropriate. bear@www:~>rpm -qa | grep snort bear@www:~>info snort [top level directory node of info...] I have 7.1 and installed nearly everything; is snort a part of SuSE new with 7.2, or is it from somewhere else? It sounds very useful. Ray
On Sat, 6 Oct 2001, Ray Dillinger wrote:
.... hmmm...
bear@www:~>man snort No manual entry for snort bear@www:~>apropos snort snort: nothing appropriate. bear@www:~>rpm -qa | grep snort bear@www:~>info snort [top level directory node of info...] how about
markus@gaugusch:/root/suse > zgrep snort INDEX.gz ./suse/sec2/snort.rpm ./suse/setup/du/snort.fil ./suse/zq1/snort.spm ? :) Markus -- ________________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus@gaugusch.dhs.org X Against HTML Mail / \
god forbid people should look for it: hint: .org. like www.snort.org. As someone else pointed out suse ships a package of it. Kurt
participants (6)
-
dog＠intop.net -
Kurt Seifried -
Markus Gaugusch -
Ray Dillinger -
Rick Green -
Roman Drahtmueller