Re: tracking down i/o sucking process
Dan MacNeil wrote: > I can hear the discs on the server going wild, I run: > > sar -d 2 120 > > ...and disc utilization is indeed higher than normal. How do I find > what process is driving up the i/o load? Not sure about I/O load specifically... but try lsof and see what processes have which files open. You'll probably want to grep -v a lot of stuff- I get 664 lines on a pretty barebones NAT firewall box. :/ HTH, -kgd -- hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/lilo.conf and system.map mismatches -- my syntax ?
> An unidentified someone repsonded to the original question:
> > Try putting the map=... Line in the specific to kernel section.
Theodore Knab wrote:
[snip]
I think what the response at the top refers to is removing this line:
> map=/boot/map
and placing separate map= lines in *EACH* of the image= sections
below: (Making sure the kernel versions match in each section. )
> #2nd build try
> #smp himem xfs
> image=/boot/vmlinuz-2.4.19-xfs2
> label=Linux
> read-only
--> map=/boot/map-{kernel-version}
> #first build try
> #smp himem xfs
> image=/boot/vmlinuz-2.4.19
> label=Linux_older
> read-only
--> map=/boot/map-{kernel-version}
> #smp himem xfs
> #high mem with io stuff
> image=/boot/vmlinuz-2.4.22
> label=Linux_22_notest
> read-only
--> map=/boot/map-{kernel-version}
> image=/vmlinuz.old
> label=LinuxOLD
> read-only
> optional
--> map=/boot/map-{kernel-version}
However, a recent woody install I did with the 2.2 kernel, and later
installed 2.4, only seems to have the one map= line- and IIRC both
kernels boot cleanly. It is NOT an SMP machine however.
HTH,
-kgd
--
"Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
- Unknown
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How do you manage Perl modules?
I'm currently working on replacing a few RedHat 7.3 boxen with Debian systems- Debian primarily because it's what head office is using. Due to some of the software in Debian stable being really *badly* outdated (ie, SpamAssassin), and some just plain missing (ClamAV, MIMEDefang, and an assortment of Perl bits), I've set up apt sources pointing to backports.org, but there's nothing there for MIMEDefang. I've since managed to reasonably quickly and cleanly backport MIMEDefang from testing- with a few tweaks I consider NECESSARY- compile options, so post-install tweaking isn't really an option. :/ However, I've just discovered that there's also a bad version mismatch between the "default" libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules (or even just recompile the stable version against different libs). Among other things, I've very carefully made sure that there is NOT a C compiler on the new production boxen. Otherwise, I'd just use CPAN and put up with two package management systems instead of one. :( I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Angus D Madden wrote:
> Assuming you have a working cpan cofniguration, you can use
> dh-make-perl.
>
> dh-make-perl --cpan module
Ah! Excellent. (Actually, you need to do
dh-make-perl --build --cpan {module}
to get a .deb out of it.)
> I have used this before and it just worked. ymmv.
Looks good; that's one less problem to deal with... All I have to do
is make sure to not blindly upgrade the core Perl package. :/
-kgd
--
"Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
- Unknown
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Dan MacNeil wrote: > For you a (maybe painful) alternative to going to unstable is to > discard your older Bayes and automatic whitelist files. *shudder* And suffer a ~20% (or more) decrease in spam filter efficiency as seen by the people paying for the service? No thanks. :/ There's about a year's worth of autolearned ham in that db, and I don't have any convenient way to relearn most of that. > btw, the first time you ran sa-learn did you get an error? Never got that far; I'm still making sure the new box is set up and working "correctly" (ie, the same as the current RedHat box). For testing, I've just been feeding some test messages through the system and seeing what comes out, as well as running # spamassassin -D --lint 2>&1 |more to see what might be going toes-up. > something like like: > "whatsits_foo.a not in @INC --needed for Digest::SHA1" > I tried to make the problem go away with apt-get but got something > like: > "blah is already the current version" > I succeeded in making the problem go away w/ > /usr/bin/perl -MCPAN -e install Digest::SHA1 Hmm.. Just checked on this, and I don't get any errors about Digest::SHA1. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: managing quotas on Ext3 FS
Robert Cates wrote: > I'm hoping to get some insight on how to setup and manage account > quotas with Debian 3.0 in an ISP environment. > I have a Debian 3.0 server running, with ext3 file systems, and as I > understand it the quota (3.04-1) package does not or cannot fully > work with ext3 file systems. I'm in the process of migrating a server from RedHat to Debian, and this is something that is Required. I checked out the install I'm testing right now, and (after the usual hair-pulling to ACTIVATE the [EMAIL PROTECTED] quotas in the first place) they seem to be functioning correctly. This *may* be a kernel-2.2 vs kernel-2.4 issue; I very carefully installed with the bf2.4 kernel, and installed a "full" 2.4 kernel later. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do you manage Perl modules?
Michael Wood wrote: > Should have replied to one of your earlier messages, but I've deleted > them... .pag and .dir are not Berkeley DB 1, they're from dbm (or > ndbm or something.) In other words, not DB_File. I don't recall the reasoning exactly, but SA as of v2.6x REQUIRES DB_File vs any of the other hash-file types for the Bayes db. Anything else requires manual hacking of the SA code. :( > You could write a perl/python script to convert from the dbm files to > bdb4 (or whatever you like.) If I understood the hash structure used... Anyway, I've found the information I needed to fix that particular issue; so far as I can tell now the rest of the problems are just simple misconfiguration issues.(Or not-yet-configured issues.) -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sendmail & access restrictions
Stephen Gran wrote: > I think I'm being dense, but I can't figure out how to do something > like the following in /etc/mail/access: > > xxx.xxx.xxx.xxx: OK # front-end machine 1 > xxx.xxx.xxx.xxy: OK # front-end machine 2 OK. You'll want to add localhost and 127.0.0.1: localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY otherwise locally-generated mail will fail. Unless you've got a good reason NOT to trust localhost, any sendmail access map should include these or similar lines- the last one is probably all that's required. > AUTH: OK > *: REJECT But these aren't really valid. By default (at least with recent versions of sendmail), relaying is denied UNLESS you have told sendmail otherwise. To allow SMTP-AUTH users to relay mail, add the following to your sendmail.mc: TRUST_AUTH_MECH(`LOGIN PLAIN')dnl You may want to trust additional mechanisms (CRAM-MD5, DIGEST-MD5, there may be others). You'll *probably* also want TLS support, so that roaming users relaying through your server don't send password-ish information in the clear. If you go this route, you can also issue certificates to individual users and include that information in the access map. I set this up on my personal server, but not the ISP servers I admin. User information is too scattered to practically implement SMTP AUTH right now. :/ The complete set of changes for allowing SMTP AUTH to relay is in the sendmail.mc file. Mine includes the following: dnl --- STARTTLS/SMTP-AUTH options --- TRUST_AUTH_MECH(`LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl define(`confAUTH_OPTIONS', `A,p')dnl define(`confCACERT_PATH', `/etc/mail/certs')dnl define(`confCACERT', `/etc/mail/certs/ca-deepnet.crt')dnl define(`confSERVER_CERT', `/etc/mail/certs/smtp.deepnet.crt')dnl define(`confSERVER_KEY', `/etc/mail/certs/rock.key.insecure')dnl This specifies, in respecitve order: - Trust LOGIN or PLAIN SMTP AUTH mechanisms for relay - Allow LOGIN and PLAIN authentication - Only allow easily-sniffed/bypassed/cracked AUTH mechanisms after successful STARTTLS or similar security layer - Where to find server/client certs - What to use as the CA cert - What to use as the TLS cert for this host - Which key to use for the TLS cert Unfortunately I seem to have lost the original reference I used to put this together, and that system is still running RedHat 7.3. :( Checking for Debian shows there are useful sections in /usr/share/doc/cf.README (from sendmail-doc). http://www.ofb.net/~jheiss/sendmail/tlsandrelay.shtml should be useful in getting TLS going. If you're going to be doing much sendmail adinistration, you should probably pick up a copy of the current (3rd) edition of the Bat Book. Many references assume that you're installing sendmail from source; you should just be able to skip the first few steps relating to compile options as most packaged sendmail installs include at least *potential* support for all of its options. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Outlook and Qmail
Anil Gupte wrote: > I am having a problem with one of my customers who is using Outlook > 2000 SP-3 to connect to our Qmail server. When downloading messages > from his POP account, Outlook will hang. It is most likely a > corrupted message, since he can delete the messages using a webmail > interface, and then continue to download messages. Possible but unlikely- at one point I found a message which would *consistently* hang Outlook Express, but NOT Pegasus Mail, Netscape, or any other MUA I tried. Viewing the message in the webmail system in use at the time worked fine as well. Since then I've had cusomters calling in with similar behaviour from the occasional message - more commonly a large message with several large images, or a video file attached, but occasionally just a short text message as well. Again, Outlook Express (and in some cases, the customer's MS Outlook) will hang on one particular message, but no other MUA does. This has happened across Novell IMS, qpopper, UW ipop3d, and Teapop. (In fact, that one Hotmail-originated message that *always* hung OE did so across all but qpopper (which was not in use at the time) *every* time.) Examining the raw message in the mailbox has turned up absolutely NOTHING any time I've met this. >:( > Has anyone run into this problem? I know at least one other ISP > having the same problem with some of his customers, but we have not > found a solution yet. Any pointers will be appreciated. The only thing I (or my boss) could ever even vaguely point to as a cause for the problem was OE's handling of attachments while it's downloading the message. We never found a real "solution", except "Don't do that". (ie, "Warn people not to send you big attachments") -kgd support/sysadmin for ViaNet Pembroke (formerly WebHart Internet) -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent being a 'bouncer' of evil mail?
Yves Junqueira wrote: > In one of my implementations, I have a gateway that filters messages, > removing most spam and viruses, than redirect them to the appropriate > servers. Thus, I do not have a record of user accounts for those > domains. What usually happens is that I get messages for > "[EMAIL PROTECTED]", from "[EMAIL PROTECTED]", and after the > final server gets the message, it bounces to yahoo. > > I don't want to cause any trouble to other admins. I understand the > way that smtp works, and that I must issue DSN's for undelivered > messages. But is there any mixture of techniques to avoid bugging > yahoo or other servers? Or have I missed the idea of DSN's? Figure out how to get a list of valid final recipients to your gateway- then that machine can reject recipients that doesn't exist. Further processing is up to the sending server- or, in the case of most spam and viruses, the spamware or virus SMTP engine (which most likely will just discard that recipient for that run). The details of how to get such a list to into your gateway's SMTP software depend on what your final delivery servers are running, and what you're running on your gateway. >From what you've described, you're stuck with one or more hideous SMTP systems like Exchange that insists on accepting everything before rejecting unknown users with a *new* message (rather than an SMTP rejection code) as the final server. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent being a 'bouncer' of evil mail?
Yves Junqueira wrote: > That would be a possible sollution, yes. I'll research further (see > below). The point is this is not just my case. Most BIG mail > providers seem to have a gateway mailer in the front that is not > aware of mail accounts. Do they bounce every fake message? If their front-line MXes don't know which accounts are valid... yes, they send out fresh messages in response to spam and viruses sent to nonexistent accounts. Beyond AV scans, and a *very* limited spam-scan, they can't really do much else without taking a big risk on silently discarding *legitimate* email sent to a misspelled or recently-deactivated email address. It's the administrator's choice, and at one time not too long ago it would have been perfectly acceptable- little or no spam and viruses. You'll probably see very vocal arguments on both sides, but most people I've seen comment on the subject agree that "Accept everything then bounce" is a Bad Thing. > Anyway, now I figured that I don't need to get all account > information from the "other server". I don't need passwords, just a > list of valid logins. And then use that as a filter, at the 'smart' > gateway. Yep. I've never set up exactly such a system, but for a while I had a Linux box acting as a gateway for a Novell IMS machine that had some related stupidity (DNS resolution speed issues, IIRC). I was able to just open a connection to the Novell box and issue RCPT TO: for each recipient, because it wasn't *quite* so stupid as to accept mail for nonexistent users. I've been lucky enough to only work with *nix mail servers except for that one Novell system- and it had some advantages I've yet to see in any *nix system. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to prevent being a 'bouncer' of evil mail?
Yves Junqueira wrote: > On Fri, 25 Jun 2004 18:21:20 -0400, Kris Deugau <[EMAIL PROTECTED]> > wrote: > > I've been lucky enough to only work with *nix mail servers except > > for that one Novell system- and it had some advantages I've yet to > > see in any *nix system. > Interesting. Was that Novell server old? In what architecture did it > run on? x86 Novell Netware 4.11, supporting Novell's "Internet Messaging System" mail package. It had some truly *peculiar* behaviour in some respects, and some horrible bugs with respect to some DNS-related operations, but it integrated *very* nicely with the Netware administration system and was ideal for a small ISP. > Exchange 2003, the final server in the case I said, is ok. It is not > that stupid. The problem is with Norton for Gateways. In our current > setting, it gets the message before Exchange does, and it is very > dumb. Ah. You'd think that a tool designed to integrate in some way with Exchange would be able to hook in to things like a recipient check. > We will be removing NAV in the future, when we are more > confident on Clamav (it still misses some old MS Word "Macro > viruses"). I can't say I've seen much trouble with Clam, and the most recent release (0.73) has fixed the problems I've had. > But, hmmm..., even we didn't have NAV, it wouldn't help much. Let's > say Postfix (the gateway) delivers the message to Exchange, which is > "smart". Even so, AFAIR, we would have another e-mail created > notifying the failure, instead of a so desired SMTP error code. After > Postfix gets the message, it sends a success reply to the client, and > just then tries to send the mail to the destination, that will give > postfix a failure reply code. Postfix will then have to send a DSN, > right? As a fresh new message, yes. At least, that's what happens by default on any MTA I've ever met, in such a setup. > Or could you issue the RCPT TO command to the other server > BEFORE sending the final result to the client, in the front server? Hmm. I know sendmail doesn't support anything like this out of the box; but I don't know for sure about any other MTAs. I've used a very nice milter for sendmail (MIMEDefang) to do exactly this- check a recipient against the next server in the chain when the remote "client" server attempts RCPT TO:- and it worked very well. > The world would be so much easier if Debian ruled from the > beginning... *shrug* I've had some problems using Debian for email handling; I've ended up having to build custom .deb's for a number of Perl modules, and use packages from backports.org to get the functionality I wanted. It didn't help that in one case I was converting from a RedHat system in production use. :/ On the other hand, apt-get is *very* nice... -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nat ipchains on debian woody
Francisco Castillo wrote:
> I'm novice on debian, i have decided recently to change from redhat
> or mandrake (fatal experiencie in two years), so excuse my ignorance.
Having recently gone through a similar change, I may be able to help a
little more.
> First i dont know how to do this step "The first thinng you must do
> is to install a kernel with IPTABLES support"
Debian "Woody" (aka stable, currently), installs with a 2.2.x kernel by
default. You'll need to find a 2.4.x kernel- either installed from
source, or from a stock kernel package.
First, install aptitude. It makes life much easier searching for a
particular package IMO.
# apt-get install aptitude
This may bring in a number of other dependencies; some of them will
definitely look a little odd. :/
Run aptitude. Search for kernel packages: press "/", then enter
"kernel" in the search box. Hit Enter. You'll see the display change
in the top section to show a kernel-{something} package. This is
*probably* either the installed kernel, or a kernel-source package. Hit
"\" to repeat the search until you find a whole series of
"kernel-image-2.{something}" packages. You should also be able to use
the arrow keys here to select a package.
I can't offer any particular advice on which 2.4 kernel to install;
I've been using "kernel-image-2.4.18-1-686", but there are three or four
others that appear to be IDENTICAL. (WTF? Maybe someone else can
explain that!)
You *may* be able to get a suitable 2.4.x kernel image installed with
"apt-get install kernel-image-2.4", but I can't comment on whether that
would actually install a usable kernel for you.
> How can I do it ? How can i test if it is on my server?
dpkg -l |grep kern should list any packages with "kern" in the name or
short description.
> Second, I have see this on my server
>
> morpheo:~# apt-get install iptables
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Sorry, iptables is already the newest version.
> It seems to be iptables installed but the previos errors said that
> iptables where not avaliable.
iptables is not usually available in 2.2-series kernels; ipchains is.
The original error message you got with iptables:
> modprobe: Can't locate module ip_tables
> iptables v1.2.6a: can't initialize iptables table `nat': iptables
> who? (do you need to insmod?)
> Perhaps iptables or your kernel needs to be upgraded.
indicates that modprobe was unable to load the kernel module ip_tables.
I've long since switched all systems I administer over to a 2.4-series
kernel; iptables is more flexible than ipchains, and allows (for
instance) connection state tracking for SSH sessions that just go
*through* the NAT host (rather than starting or ending there).
-kgd
--
"Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
- Unknown
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nat ipchains on debian woody
Francisco Castillo wrote: > But my problem now is another different. When I installed my woody i > put a floppy disk bootting system in order to load my debian woody > kernel (this is a large history because i have 2 hard disk on this > machine and I cant start debian in a classic lilo) Why not? Does LILO just exit with an error trying to install itself? Does GRUB work (assuming you can find it and get it installed...)? I've yet to meet a system that wouldn't boot off the hard drive eventually, although one or two have had trouble booting certain kernels from CD. > , so my bootting > disk gone to run my old kernel (2.2) and i dont now how i can create > a new floppy disk in order to load the new kernel You need to run mkboot. man mkboot for more details. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nat ipchains on debian woody
Francisco Castillo wrote: > Then i do a apt-get install kernel-image-2.18.14-686, and this > installations works fine. Then it puts me a entry on the lilo in > order to load the new kernel (the old kernel is a 2.2 original woody, > it has a 686 ) but the problem for me now is that when i reboot the > kernel can´t load. It give me a kernel panic message , unable to load > the boot.1006. It seems like this new kernel dont works on my hard > plataform, but it happens the same with the > kernel-image.2.18-14-586tsc. > > This could be true? I've heard of this happening (typically with Compaq servers, for some reason), but I've yet to have it happen to me. If you really want to run a 2.4 kernel, or you really want iptables, you'll probably have to compile a custom kernel. :/ IIRC you *can* use iptables with a 2.2 kernel, but it's a pain to get up and running. > How can i Knew what is the soft or version of kernel-image i must use > in my hard system? Anyone else? I've found stock kernels work fine for me, but I've occasionally run into hardware that doesn't run with them. > Could be posible to has a kernel 2.2 of woody and a nat configuration > (ipmasquerade) ? > Could i do it with ipchanis? It can be done; it also has some very specific flaws and limitations that make it less flexible than iptables. > What could be this procedure to setup this configuration? Here's a very trimmed-down version of a firewall script I used to use; for a variety of reasons I no longer use this particular script or anything like it on most of my systems. (Among other reasons, all my systems are running 2.4 kernels, and so I'm using iptables instead of ipchains.) You'll need to modify interface names and IPs to your setup, and decide whether to use the kernel TCP tuning listed here (I've never seen problems with it, but...) =BEGIN rc.firewall= #!/bin/sh case $1 in start|stop|restart) # Setting up firewall variables #External Interface EXT_IF="eth0" EXT_IP="10.10.10.24" #Internal Interface INT_IF="eth1" INT_IP="192.168.2.1" #Network stuff INT_NET="192.168.0.0/16" BROADCAST_SRC="0.0.0.0" BROADCAST_DEST="255.255.255.255" CWD=`pwd` echo -n "Doing assorted network shiznit..." #Disable TCP source routing for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f; done #Turn on source address verification for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done #Disable ICMP redirection for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f; done #Turn on packet forwarding (for masquerading) echo 1 > /proc/sys/net/ipv4/ip_forward #Turn OFF ICMP replies #echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all #Use TCP SYN cookies echo 1 > /proc/sys/net/ipv4/tcp_syncookies #Assorted TCP/IP crap (turning off unused extensions, etc.) echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time echo 0 > /proc/sys/net/ipv4/tcp_window_scaling echo 0 > /proc/sys/net/ipv4/tcp_sack echo 0 > /proc/sys/net/ipv4/tcp_timestamps echo "done." #Adding masquerading modules to make life easier. echo -n "Adding masquerading modules..." /sbin/modprobe ip_masq_ftp.o /sbin/modprobe ip_masq_irc.o /sbin/modprobe ip_masq_quake.o /sbin/modprobe ip_masq_raudio.o /sbin/modprobe ip_masq_vdolive.o /sbin/modprobe ip_masq_portfw.o /sbin/modprobe ip_masq_autofw.o /sbin/modprobe ip_masq_user.o echo "done." # Check to see how this script was called. case "$1" in stop) echo "Stopping FIREWALL services." echo -n " Flushing chains..." /sbin/ipchains -F echo "done." echo "FIREWALL services stopped." ;; start) echo "Starting FIREWALL services." echo -n " Setting forwarding rules..." /sbin/ipchains -A forward -j MASQ -s $INT_NET echo "done." echo " Setting input filter rules..." echo -n " regular input rules..." /sbin/ipchains -A input -j ACCEPT -s any/0 domain -p tcp -i $EXT_IF /sbin/ipchains -A input -j ACCEPT -s any/0 domain -p udp -i $EXT_IF /sbin/ipchains -A input -j ACCEPT -s any/0 time -p tcp -i $INT_IF /sbin/ipchains -A input -j ACCEPT -s any/0 time -p udp -i $INT_IF /sbin/ipchains -A input -j REJECT -d $EXT_IP tftp -p udp -i $EXT_IF -l /sbin/ipchains -A input -j REJECT -d $EXT_IP sunrpc -p tcp -i $EXT_IF -l /sbin/ipchains -A input -j REJECT -d $EXT_IP auth -p tcp -i $EXT_IF -l # Since we don't use nntp anyway... /sbin/ipchains -A input -j REJECT -d $EXT_IP nntp -p tcp -i $EXT_IF -l # Samba and friends; we don't want to have anything to do with # these over the public interface /sbin/ipchains -A input -j REJECT -d $EXT_IP 134 -p tcp -i $EXT_IF -
Re: Outlook and Qmail
Craig Sanders wrote: > the problem is that outlook is broken. it's broken in many ways but > this specific problem is due to the fact that outlook locks up when > downloading "large" messages. it doesn't have to be an attachment, > if the message is too large, then outlook will hang. i don't recall > exactly what the definition of "large" is, but in my experience even > medium-length messages will trigger the bug. Mmmh.. If it's inherently Outlook/Outlook Express, why do I have 3 or 4 customers who seem to spend their time sending and receiving ~5-7M video files by email? I've yet to find any one consistent "This WILL cause a problem" factor, although Outlook/OE are more likely to have trouble, and single large attachments or messages with several medium-large images attached are more likely to have trouble. The one exception I noted in my original reply was one particular message which even caused problems for the Novell IMS webmail client, caused Netscape 4.something to lock up when the message was opened- either via IMAP, or downloaded by POP3 and opened from a local folder, and even caused Pegasus Mail to behave a little oddly. That message happened to have been sent from a Hotmail account, but manual inspection showed absolutely NOTHING that should have caused this behaviour. > the only solution is to use a decent mail client. point customer at > mozilla thunderbird (IIRC there *IS* a windoze version) - nice GUI > mail client without outlook's stupid bugs and without outlook's > stupid security holes. and it's free. if they don't like > thunderbird there are many others to choose from, but the Golden Rule > is "Anything But Outlook!". Indeed. One minor advantage I've found to Outlook Express (please note, very definitely *NOT* Outlook!) is that it does a *very* tidy job of sending email messages as attachments- right-click the message, "Forward as attachment", and it creates a very well-formed MIME message suitable for extracting the original to feed back into a spam filter. The other advantage, from an ISP perspective, is that it's usually already there on a user's computer, and anything else requires hours and hours of download time, or a software CD for dialup users. :/ > alternatively, get used to occasionally having to manually delete > "large" messages from the mailboxes of people who use outlook. Or directing them to the webmail interface and letting them sort out their own mail. -kgd -- Get your mouse off of there! You don't know where that email has been! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tracking down i/o sucking process
Dan MacNeil wrote: > I can hear the discs on the server going wild, I run: > > sar -d 2 120 > > ...and disc utilization is indeed higher than normal. How do I find > what process is driving up the i/o load? Not sure about I/O load specifically... but try lsof and see what processes have which files open. You'll probably want to grep -v a lot of stuff- I get 664 lines on a pretty barebones NAT firewall box. :/ HTH, -kgd -- hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
Re: /etc/lilo.conf and system.map mismatches -- my syntax ?
> An unidentified someone repsonded to the original question:
> > Try putting the map=... Line in the specific to kernel section.
Theodore Knab wrote:
[snip]
I think what the response at the top refers to is removing this line:
> map=/boot/map
and placing separate map= lines in *EACH* of the image= sections
below: (Making sure the kernel versions match in each section. )
> #2nd build try
> #smp himem xfs
> image=/boot/vmlinuz-2.4.19-xfs2
> label=Linux
> read-only
--> map=/boot/map-{kernel-version}
> #first build try
> #smp himem xfs
> image=/boot/vmlinuz-2.4.19
> label=Linux_older
> read-only
--> map=/boot/map-{kernel-version}
> #smp himem xfs
> #high mem with io stuff
> image=/boot/vmlinuz-2.4.22
> label=Linux_22_notest
> read-only
--> map=/boot/map-{kernel-version}
> image=/vmlinuz.old
> label=LinuxOLD
> read-only
> optional
--> map=/boot/map-{kernel-version}
However, a recent woody install I did with the 2.2 kernel, and later
installed 2.4, only seems to have the one map= line- and IIRC both
kernels boot cleanly. It is NOT an SMP machine however.
HTH,
-kgd
--
"Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
- Unknown
How do you manage Perl modules?
I'm currently working on replacing a few RedHat 7.3 boxen with Debian systems- Debian primarily because it's what head office is using. Due to some of the software in Debian stable being really *badly* outdated (ie, SpamAssassin), and some just plain missing (ClamAV, MIMEDefang, and an assortment of Perl bits), I've set up apt sources pointing to backports.org, but there's nothing there for MIMEDefang. I've since managed to reasonably quickly and cleanly backport MIMEDefang from testing- with a few tweaks I consider NECESSARY- compile options, so post-install tweaking isn't really an option. :/ However, I've just discovered that there's also a bad version mismatch between the "default" libdb version used by DB_File in RedHat, and the one in Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that this has been included as a part of the monolithic perl-5.6.1 package, and I *really* don't want to go anywhere near backporting that myself or using a third-party backport. I discovered this in trying to get the SA2.63 install (from backports.org) to recognize the ~40M global Bayes dbs and per-user AWL files; instead I discover pairs of .dir + .pag files for AWL (which I vaguely recall are an artifact of db1) and SA won't open the existing bayes_* files. Is there something like cpan2rpm or cpanflute for Debian? I'd like to pull in current versions of Perl modules (or even just recompile the stable version against different libs). Among other things, I've very carefully made sure that there is NOT a C compiler on the new production boxen. Otherwise, I'd just use CPAN and put up with two package management systems instead of one. :( I *could* hack together some bits to force db3 to work by building on RedHat, and using alien to install... but that's just plain ugly and as I've already discovered it *will* break because of differences in how RedHat and Debian handle the core Perl install and addon modules. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: How do you manage Perl modules?
Angus D Madden wrote:
> Assuming you have a working cpan cofniguration, you can use
> dh-make-perl.
>
> dh-make-perl --cpan module
Ah! Excellent. (Actually, you need to do
dh-make-perl --build --cpan {module}
to get a .deb out of it.)
> I have used this before and it just worked. ymmv.
Looks good; that's one less problem to deal with... All I have to do
is make sure to not blindly upgrade the core Perl package. :/
-kgd
--
"Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
- Unknown
Re: How do you manage Perl modules?
Dan MacNeil wrote: > For you a (maybe painful) alternative to going to unstable is to > discard your older Bayes and automatic whitelist files. *shudder* And suffer a ~20% (or more) decrease in spam filter efficiency as seen by the people paying for the service? No thanks. :/ There's about a year's worth of autolearned ham in that db, and I don't have any convenient way to relearn most of that. > btw, the first time you ran sa-learn did you get an error? Never got that far; I'm still making sure the new box is set up and working "correctly" (ie, the same as the current RedHat box). For testing, I've just been feeding some test messages through the system and seeing what comes out, as well as running # spamassassin -D --lint 2>&1 |more to see what might be going toes-up. > something like like: > "whatsits_foo.a not in @INC --needed for Digest::SHA1" > I tried to make the problem go away with apt-get but got something > like: > "blah is already the current version" > I succeeded in making the problem go away w/ > /usr/bin/perl -MCPAN -e install Digest::SHA1 Hmm.. Just checked on this, and I don't get any errors about Digest::SHA1. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: managing quotas on Ext3 FS
Robert Cates wrote: > I'm hoping to get some insight on how to setup and manage account > quotas with Debian 3.0 in an ISP environment. > I have a Debian 3.0 server running, with ext3 file systems, and as I > understand it the quota (3.04-1) package does not or cannot fully > work with ext3 file systems. I'm in the process of migrating a server from RedHat to Debian, and this is something that is Required. I checked out the install I'm testing right now, and (after the usual hair-pulling to ACTIVATE the [EMAIL PROTECTED] quotas in the first place) they seem to be functioning correctly. This *may* be a kernel-2.2 vs kernel-2.4 issue; I very carefully installed with the bf2.4 kernel, and installed a "full" 2.4 kernel later. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: How do you manage Perl modules?
Michael Wood wrote: > Should have replied to one of your earlier messages, but I've deleted > them... .pag and .dir are not Berkeley DB 1, they're from dbm (or > ndbm or something.) In other words, not DB_File. I don't recall the reasoning exactly, but SA as of v2.6x REQUIRES DB_File vs any of the other hash-file types for the Bayes db. Anything else requires manual hacking of the SA code. :( > You could write a perl/python script to convert from the dbm files to > bdb4 (or whatever you like.) If I understood the hash structure used... Anyway, I've found the information I needed to fix that particular issue; so far as I can tell now the rest of the problems are just simple misconfiguration issues.(Or not-yet-configured issues.) -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: Sendmail & access restrictions
Stephen Gran wrote: > I think I'm being dense, but I can't figure out how to do something > like the following in /etc/mail/access: > > xxx.xxx.xxx.xxx: OK # front-end machine 1 > xxx.xxx.xxx.xxy: OK # front-end machine 2 OK. You'll want to add localhost and 127.0.0.1: localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY otherwise locally-generated mail will fail. Unless you've got a good reason NOT to trust localhost, any sendmail access map should include these or similar lines- the last one is probably all that's required. > AUTH: OK > *: REJECT But these aren't really valid. By default (at least with recent versions of sendmail), relaying is denied UNLESS you have told sendmail otherwise. To allow SMTP-AUTH users to relay mail, add the following to your sendmail.mc: TRUST_AUTH_MECH(`LOGIN PLAIN')dnl You may want to trust additional mechanisms (CRAM-MD5, DIGEST-MD5, there may be others). You'll *probably* also want TLS support, so that roaming users relaying through your server don't send password-ish information in the clear. If you go this route, you can also issue certificates to individual users and include that information in the access map. I set this up on my personal server, but not the ISP servers I admin. User information is too scattered to practically implement SMTP AUTH right now. :/ The complete set of changes for allowing SMTP AUTH to relay is in the sendmail.mc file. Mine includes the following: dnl --- STARTTLS/SMTP-AUTH options --- TRUST_AUTH_MECH(`LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `LOGIN PLAIN')dnl define(`confAUTH_OPTIONS', `A,p')dnl define(`confCACERT_PATH', `/etc/mail/certs')dnl define(`confCACERT', `/etc/mail/certs/ca-deepnet.crt')dnl define(`confSERVER_CERT', `/etc/mail/certs/smtp.deepnet.crt')dnl define(`confSERVER_KEY', `/etc/mail/certs/rock.key.insecure')dnl This specifies, in respecitve order: - Trust LOGIN or PLAIN SMTP AUTH mechanisms for relay - Allow LOGIN and PLAIN authentication - Only allow easily-sniffed/bypassed/cracked AUTH mechanisms after successful STARTTLS or similar security layer - Where to find server/client certs - What to use as the CA cert - What to use as the TLS cert for this host - Which key to use for the TLS cert Unfortunately I seem to have lost the original reference I used to put this together, and that system is still running RedHat 7.3. :( Checking for Debian shows there are useful sections in /usr/share/doc/cf.README (from sendmail-doc). http://www.ofb.net/~jheiss/sendmail/tlsandrelay.shtml should be useful in getting TLS going. If you're going to be doing much sendmail adinistration, you should probably pick up a copy of the current (3rd) edition of the Bat Book. Many references assume that you're installing sendmail from source; you should just be able to skip the first few steps relating to compile options as most packaged sendmail installs include at least *potential* support for all of its options. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: Outlook and Qmail
Anil Gupte wrote: > I am having a problem with one of my customers who is using Outlook > 2000 SP-3 to connect to our Qmail server. When downloading messages > from his POP account, Outlook will hang. It is most likely a > corrupted message, since he can delete the messages using a webmail > interface, and then continue to download messages. Possible but unlikely- at one point I found a message which would *consistently* hang Outlook Express, but NOT Pegasus Mail, Netscape, or any other MUA I tried. Viewing the message in the webmail system in use at the time worked fine as well. Since then I've had cusomters calling in with similar behaviour from the occasional message - more commonly a large message with several large images, or a video file attached, but occasionally just a short text message as well. Again, Outlook Express (and in some cases, the customer's MS Outlook) will hang on one particular message, but no other MUA does. This has happened across Novell IMS, qpopper, UW ipop3d, and Teapop. (In fact, that one Hotmail-originated message that *always* hung OE did so across all but qpopper (which was not in use at the time) *every* time.) Examining the raw message in the mailbox has turned up absolutely NOTHING any time I've met this. >:( > Has anyone run into this problem? I know at least one other ISP > having the same problem with some of his customers, but we have not > found a solution yet. Any pointers will be appreciated. The only thing I (or my boss) could ever even vaguely point to as a cause for the problem was OE's handling of attachments while it's downloading the message. We never found a real "solution", except "Don't do that". (ie, "Warn people not to send you big attachments") -kgd support/sysadmin for ViaNet Pembroke (formerly WebHart Internet) -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: How to prevent being a 'bouncer' of evil mail?
Yves Junqueira wrote: > In one of my implementations, I have a gateway that filters messages, > removing most spam and viruses, than redirect them to the appropriate > servers. Thus, I do not have a record of user accounts for those > domains. What usually happens is that I get messages for > "[EMAIL PROTECTED]", from "[EMAIL PROTECTED]", and after the > final server gets the message, it bounces to yahoo. > > I don't want to cause any trouble to other admins. I understand the > way that smtp works, and that I must issue DSN's for undelivered > messages. But is there any mixture of techniques to avoid bugging > yahoo or other servers? Or have I missed the idea of DSN's? Figure out how to get a list of valid final recipients to your gateway- then that machine can reject recipients that doesn't exist. Further processing is up to the sending server- or, in the case of most spam and viruses, the spamware or virus SMTP engine (which most likely will just discard that recipient for that run). The details of how to get such a list to into your gateway's SMTP software depend on what your final delivery servers are running, and what you're running on your gateway. >From what you've described, you're stuck with one or more hideous SMTP systems like Exchange that insists on accepting everything before rejecting unknown users with a *new* message (rather than an SMTP rejection code) as the final server. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: How to prevent being a 'bouncer' of evil mail?
Yves Junqueira wrote: > That would be a possible sollution, yes. I'll research further (see > below). The point is this is not just my case. Most BIG mail > providers seem to have a gateway mailer in the front that is not > aware of mail accounts. Do they bounce every fake message? If their front-line MXes don't know which accounts are valid... yes, they send out fresh messages in response to spam and viruses sent to nonexistent accounts. Beyond AV scans, and a *very* limited spam-scan, they can't really do much else without taking a big risk on silently discarding *legitimate* email sent to a misspelled or recently-deactivated email address. It's the administrator's choice, and at one time not too long ago it would have been perfectly acceptable- little or no spam and viruses. You'll probably see very vocal arguments on both sides, but most people I've seen comment on the subject agree that "Accept everything then bounce" is a Bad Thing. > Anyway, now I figured that I don't need to get all account > information from the "other server". I don't need passwords, just a > list of valid logins. And then use that as a filter, at the 'smart' > gateway. Yep. I've never set up exactly such a system, but for a while I had a Linux box acting as a gateway for a Novell IMS machine that had some related stupidity (DNS resolution speed issues, IIRC). I was able to just open a connection to the Novell box and issue RCPT TO: for each recipient, because it wasn't *quite* so stupid as to accept mail for nonexistent users. I've been lucky enough to only work with *nix mail servers except for that one Novell system- and it had some advantages I've yet to see in any *nix system. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: How to prevent being a 'bouncer' of evil mail?
Yves Junqueira wrote: > On Fri, 25 Jun 2004 18:21:20 -0400, Kris Deugau <[EMAIL PROTECTED]> > wrote: > > I've been lucky enough to only work with *nix mail servers except > > for that one Novell system- and it had some advantages I've yet to > > see in any *nix system. > Interesting. Was that Novell server old? In what architecture did it > run on? x86 Novell Netware 4.11, supporting Novell's "Internet Messaging System" mail package. It had some truly *peculiar* behaviour in some respects, and some horrible bugs with respect to some DNS-related operations, but it integrated *very* nicely with the Netware administration system and was ideal for a small ISP. > Exchange 2003, the final server in the case I said, is ok. It is not > that stupid. The problem is with Norton for Gateways. In our current > setting, it gets the message before Exchange does, and it is very > dumb. Ah. You'd think that a tool designed to integrate in some way with Exchange would be able to hook in to things like a recipient check. > We will be removing NAV in the future, when we are more > confident on Clamav (it still misses some old MS Word "Macro > viruses"). I can't say I've seen much trouble with Clam, and the most recent release (0.73) has fixed the problems I've had. > But, hmmm..., even we didn't have NAV, it wouldn't help much. Let's > say Postfix (the gateway) delivers the message to Exchange, which is > "smart". Even so, AFAIR, we would have another e-mail created > notifying the failure, instead of a so desired SMTP error code. After > Postfix gets the message, it sends a success reply to the client, and > just then tries to send the mail to the destination, that will give > postfix a failure reply code. Postfix will then have to send a DSN, > right? As a fresh new message, yes. At least, that's what happens by default on any MTA I've ever met, in such a setup. > Or could you issue the RCPT TO command to the other server > BEFORE sending the final result to the client, in the front server? Hmm. I know sendmail doesn't support anything like this out of the box; but I don't know for sure about any other MTAs. I've used a very nice milter for sendmail (MIMEDefang) to do exactly this- check a recipient against the next server in the chain when the remote "client" server attempts RCPT TO:- and it worked very well. > The world would be so much easier if Debian ruled from the > beginning... *shrug* I've had some problems using Debian for email handling; I've ended up having to build custom .deb's for a number of Perl modules, and use packages from backports.org to get the functionality I wanted. It didn't help that in one case I was converting from a RedHat system in production use. :/ On the other hand, apt-get is *very* nice... -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: nat ipchains on debian woody
Francisco Castillo wrote:
> I'm novice on debian, i have decided recently to change from redhat
> or mandrake (fatal experiencie in two years), so excuse my ignorance.
Having recently gone through a similar change, I may be able to help a
little more.
> First i dont know how to do this step "The first thinng you must do
> is to install a kernel with IPTABLES support"
Debian "Woody" (aka stable, currently), installs with a 2.2.x kernel by
default. You'll need to find a 2.4.x kernel- either installed from
source, or from a stock kernel package.
First, install aptitude. It makes life much easier searching for a
particular package IMO.
# apt-get install aptitude
This may bring in a number of other dependencies; some of them will
definitely look a little odd. :/
Run aptitude. Search for kernel packages: press "/", then enter
"kernel" in the search box. Hit Enter. You'll see the display change
in the top section to show a kernel-{something} package. This is
*probably* either the installed kernel, or a kernel-source package. Hit
"\" to repeat the search until you find a whole series of
"kernel-image-2.{something}" packages. You should also be able to use
the arrow keys here to select a package.
I can't offer any particular advice on which 2.4 kernel to install;
I've been using "kernel-image-2.4.18-1-686", but there are three or four
others that appear to be IDENTICAL. (WTF? Maybe someone else can
explain that!)
You *may* be able to get a suitable 2.4.x kernel image installed with
"apt-get install kernel-image-2.4", but I can't comment on whether that
would actually install a usable kernel for you.
> How can I do it ? How can i test if it is on my server?
dpkg -l |grep kern should list any packages with "kern" in the name or
short description.
> Second, I have see this on my server
>
> morpheo:~# apt-get install iptables
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Sorry, iptables is already the newest version.
> It seems to be iptables installed but the previos errors said that
> iptables where not avaliable.
iptables is not usually available in 2.2-series kernels; ipchains is.
The original error message you got with iptables:
> modprobe: Can't locate module ip_tables
> iptables v1.2.6a: can't initialize iptables table `nat': iptables
> who? (do you need to insmod?)
> Perhaps iptables or your kernel needs to be upgraded.
indicates that modprobe was unable to load the kernel module ip_tables.
I've long since switched all systems I administer over to a 2.4-series
kernel; iptables is more flexible than ipchains, and allows (for
instance) connection state tracking for SSH sessions that just go
*through* the NAT host (rather than starting or ending there).
-kgd
--
"Sendmail administration is not black magic. There are legitimate
technical reasons why it requires the sacrificing of a live chicken."
- Unknown
Re: nat ipchains on debian woody
Francisco Castillo wrote: > But my problem now is another different. When I installed my woody i > put a floppy disk bootting system in order to load my debian woody > kernel (this is a large history because i have 2 hard disk on this > machine and I cant start debian in a classic lilo) Why not? Does LILO just exit with an error trying to install itself? Does GRUB work (assuming you can find it and get it installed...)? I've yet to meet a system that wouldn't boot off the hard drive eventually, although one or two have had trouble booting certain kernels from CD. > , so my bootting > disk gone to run my old kernel (2.2) and i dont now how i can create > a new floppy disk in order to load the new kernel You need to run mkboot. man mkboot for more details. -kgd -- "Sendmail administration is not black magic. There are legitimate technical reasons why it requires the sacrificing of a live chicken." - Unknown
Re: nat ipchains on debian woody
Francisco Castillo wrote: > Then i do a apt-get install kernel-image-2.18.14-686, and this > installations works fine. Then it puts me a entry on the lilo in > order to load the new kernel (the old kernel is a 2.2 original woody, > it has a 686 ) but the problem for me now is that when i reboot the > kernel can´t load. It give me a kernel panic message , unable to load > the boot.1006. It seems like this new kernel dont works on my hard > plataform, but it happens the same with the > kernel-image.2.18-14-586tsc. > > This could be true? I've heard of this happening (typically with Compaq servers, for some reason), but I've yet to have it happen to me. If you really want to run a 2.4 kernel, or you really want iptables, you'll probably have to compile a custom kernel. :/ IIRC you *can* use iptables with a 2.2 kernel, but it's a pain to get up and running. > How can i Knew what is the soft or version of kernel-image i must use > in my hard system? Anyone else? I've found stock kernels work fine for me, but I've occasionally run into hardware that doesn't run with them. > Could be posible to has a kernel 2.2 of woody and a nat configuration > (ipmasquerade) ? > Could i do it with ipchanis? It can be done; it also has some very specific flaws and limitations that make it less flexible than iptables. > What could be this procedure to setup this configuration? Here's a very trimmed-down version of a firewall script I used to use; for a variety of reasons I no longer use this particular script or anything like it on most of my systems. (Among other reasons, all my systems are running 2.4 kernels, and so I'm using iptables instead of ipchains.) You'll need to modify interface names and IPs to your setup, and decide whether to use the kernel TCP tuning listed here (I've never seen problems with it, but...) =BEGIN rc.firewall= #!/bin/sh case $1 in start|stop|restart) # Setting up firewall variables #External Interface EXT_IF="eth0" EXT_IP="10.10.10.24" #Internal Interface INT_IF="eth1" INT_IP="192.168.2.1" #Network stuff INT_NET="192.168.0.0/16" BROADCAST_SRC="0.0.0.0" BROADCAST_DEST="255.255.255.255" CWD=`pwd` echo -n "Doing assorted network shiznit..." #Disable TCP source routing for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f; done #Turn on source address verification for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done #Disable ICMP redirection for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f; done #Turn on packet forwarding (for masquerading) echo 1 > /proc/sys/net/ipv4/ip_forward #Turn OFF ICMP replies #echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all #Use TCP SYN cookies echo 1 > /proc/sys/net/ipv4/tcp_syncookies #Assorted TCP/IP crap (turning off unused extensions, etc.) echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time echo 0 > /proc/sys/net/ipv4/tcp_window_scaling echo 0 > /proc/sys/net/ipv4/tcp_sack echo 0 > /proc/sys/net/ipv4/tcp_timestamps echo "done." #Adding masquerading modules to make life easier. echo -n "Adding masquerading modules..." /sbin/modprobe ip_masq_ftp.o /sbin/modprobe ip_masq_irc.o /sbin/modprobe ip_masq_quake.o /sbin/modprobe ip_masq_raudio.o /sbin/modprobe ip_masq_vdolive.o /sbin/modprobe ip_masq_portfw.o /sbin/modprobe ip_masq_autofw.o /sbin/modprobe ip_masq_user.o echo "done." # Check to see how this script was called. case "$1" in stop) echo "Stopping FIREWALL services." echo -n " Flushing chains..." /sbin/ipchains -F echo "done." echo "FIREWALL services stopped." ;; start) echo "Starting FIREWALL services." echo -n " Setting forwarding rules..." /sbin/ipchains -A forward -j MASQ -s $INT_NET echo "done." echo " Setting input filter rules..." echo -n " regular input rules..." /sbin/ipchains -A input -j ACCEPT -s any/0 domain -p tcp -i $EXT_IF /sbin/ipchains -A input -j ACCEPT -s any/0 domain -p udp -i $EXT_IF /sbin/ipchains -A input -j ACCEPT -s any/0 time -p tcp -i $INT_IF /sbin/ipchains -A input -j ACCEPT -s any/0 time -p udp -i $INT_IF /sbin/ipchains -A input -j REJECT -d $EXT_IP tftp -p udp -i $EXT_IF -l /sbin/ipchains -A input -j REJECT -d $EXT_IP sunrpc -p tcp -i $EXT_IF -l /sbin/ipchains -A input -j REJECT -d $EXT_IP auth -p tcp -i $EXT_IF -l # Since we don't use nntp anyway... /sbin/ipchains -A input -j REJECT -d $EXT_IP nntp -p tcp -i $EXT_IF -l # Samba and friends; we don't want to have anything to do with # these over the public interface /sbin/ipchains -A input -j REJECT -d $EXT_IP 134 -p tcp -i
