iptables, port scan, sendmail overload - Security

This is a discussion on iptables, port scan, sendmail overload - Security ; Hi everyone, I am more of a novice than an expert when it comes to linux problems, but last night I decided to do a port scan on our server at work, to make sure it was fit to handle ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: iptables, port scan, sendmail overload

  1. iptables, port scan, sendmail overload

    Hi everyone,

    I am more of a novice than an expert when it comes to linux problems,
    but last night I decided to do a port scan on our server at work, to
    make sure it was fit to handle the Christmas holidays all alone.

    So when i got home, i started the port scan off using AATools Port
    Scanner for windows and went out. When i got back, it was showing me
    that there was around 15 ports open (all UDP) on weird ports... as you
    can imagine i started getting worried. I had rewritten the rules that
    day to make sure they was all ok.

    Anyway, to cut it a little short, Got to work this morning, to find
    that sendmail had died with the following error messages:

    Dec 21 08:14:53 mail sendmail[8672]: rejecting connections on daemon
    MSA: load average: 129
    Dec 21 08:15:08 mail sendmail[8672]: rejecting connections on daemon
    MTA: load average: 129
    Dec 21 08:15:08 mail sendmail[8672]: rejecting connections on daemon
    MSA: load average: 129
    Dec 21 08:15:23 mail sendmail[8672]: rejecting connections on daemon
    MTA: load average: 129

    After surfing the internet to find the cause of this, with people
    suggesting it might be apache, I shut apache down. Even though the CPU
    was not showing any load for apache, this did not solve the problem. So
    back to searching google, i eventually found someone who suggested it
    was a network problem. So i turned my firewall off, thinking it might
    have been the port scan i did the night before.

    Straight away the load started coming down, and within a few minutes
    returned to normal.

    Does anyone know why this sort of thing should happen. I thought that a
    firewall should just ignore this sort of thing, not crash and fall
    over. If anyone could shed any light on this, i would be most grateful.

    Thanks

    Dave.


  2. Re: iptables, port scan, sendmail overload

    On 21 Dec 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <1166691757.194963.140340@80g2000cwy.googlegroups.c om>, Dave wrote:

    >I am more of a novice than an expert when it comes to linux problems,
    >but last night I decided to do a port scan on our server at work, to
    >make sure it was fit to handle the Christmas holidays all alone.


    Normally, before I do the portscan, I like to look at the output of
    /bin/netstat -anptu to see what the system knows is flapping in the
    breeze.

    >So when i got home, i started the port scan off using AATools Port
    >Scanner for windows and went out. When i got back, it was showing me
    >that there was around 15 ports open (all UDP) on weird ports... as you
    >can imagine i started getting worried. I had rewritten the rules that
    >day to make sure they was all ok.


    Not using windoze, I have no idea what 'AATools' may have tried. Most
    people use 'nmap'. Does netstat show these ports open now? If so, what
    process has them open?

    >Anyway, to cut it a little short, Got to work this morning, to find
    >that sendmail had died with the following error messages:
    >
    >Dec 21 08:14:53 mail sendmail[8672]: rejecting connections on daemon
    >MSA: load average: 129
    >Dec 21 08:15:08 mail sendmail[8672]: rejecting connections on daemon
    >MTA: load average: 129


    OK - something running around in circles hogging all the CPU cycles,
    and sendmail rightly decided not to add to the bonfire. Well, you've at
    least discovered you've got a DOS problem.

    >So i turned my firewall off, thinking it might have been the port scan
    >i did the night before.
    >Straight away the load started coming down, and within a few minutes
    >returned to normal.


    Ok, so what is/was your firewall ruleset looking like?

    >Does anyone know why this sort of thing should happen. I thought that a
    >firewall should just ignore this sort of thing, not crash and fall
    >over. If anyone could shed any light on this, i would be most grateful.


    Well, first off I prefer not to run the firewall on the same box as the
    mail or web server. This may be OK for a home setup, but a business
    shouldn't be doing that. Secondly, what have you got the firewall doing?
    Based on your post to comp.os.linux.networking on the 18th, and your
    statement above, you've changed the firewall setup. What was hogging the
    CPU cycles? Was this some 'reactive' firewall function (if "attacked",
    do "this")? Obviously, a lot depends on your perceived threat that
    you have configured the firewall to block, and what services you are
    offering to how much of the world, but I like to see comparatively
    simple firewall setups.

    Lessee, I only see two responses to your c.o.l.n post - Bit pointed you
    to netfilter.org and iptables-tutorial.frozentux.net. I like to refer
    people to Rusty Russell's (author of the firewall code in the kernel)
    site at http://www.iptables.org/documentation/HOWTO/

    Old guy

  3. Re: iptables, port scan, sendmail overload


    Moe Trin wrote:
    > On 21 Dec 2006, in the Usenet newsgroup comp.os.linux.security, in article
    > <1166691757.194963.140340@80g2000cwy.googlegroups.c om>, Dave wrote:
    >
    > >I am more of a novice than an expert when it comes to linux problems,
    > >but last night I decided to do a port scan on our server at work, to
    > >make sure it was fit to handle the Christmas holidays all alone.

    >
    > Normally, before I do the portscan, I like to look at the output of
    > /bin/netstat -anptu to see what the system knows is flapping in the
    > breeze.
    >
    > >So when i got home, i started the port scan off using AATools Port
    > >Scanner for windows and went out. When i got back, it was showing me
    > >that there was around 15 ports open (all UDP) on weird ports... as you
    > >can imagine i started getting worried. I had rewritten the rules that
    > >day to make sure they was all ok.

    >
    > Not using windoze, I have no idea what 'AATools' may have tried. Most
    > people use 'nmap'. Does netstat show these ports open now? If so, what
    > process has them open?
    >
    > >Anyway, to cut it a little short, Got to work this morning, to find
    > >that sendmail had died with the following error messages:
    > >
    > >Dec 21 08:14:53 mail sendmail[8672]: rejecting connections on daemon
    > >MSA: load average: 129
    > >Dec 21 08:15:08 mail sendmail[8672]: rejecting connections on daemon
    > >MTA: load average: 129

    >
    > OK - something running around in circles hogging all the CPU cycles,
    > and sendmail rightly decided not to add to the bonfire. Well, you've at
    > least discovered you've got a DOS problem.
    >
    > >So i turned my firewall off, thinking it might have been the port scan
    > >i did the night before.
    > >Straight away the load started coming down, and within a few minutes
    > >returned to normal.

    >
    > Ok, so what is/was your firewall ruleset looking like?
    >
    > >Does anyone know why this sort of thing should happen. I thought that a
    > >firewall should just ignore this sort of thing, not crash and fall
    > >over. If anyone could shed any light on this, i would be most grateful.

    >
    > Well, first off I prefer not to run the firewall on the same box as the
    > mail or web server. This may be OK for a home setup, but a business
    > shouldn't be doing that. Secondly, what have you got the firewall doing?
    > Based on your post to comp.os.linux.networking on the 18th, and your
    > statement above, you've changed the firewall setup. What was hogging the
    > CPU cycles? Was this some 'reactive' firewall function (if "attacked",
    > do "this")? Obviously, a lot depends on your perceived threat that
    > you have configured the firewall to block, and what services you are
    > offering to how much of the world, but I like to see comparatively
    > simple firewall setups.
    >
    > Lessee, I only see two responses to your c.o.l.n post - Bit pointed you
    > to netfilter.org and iptables-tutorial.frozentux.net. I like to refer
    > people to Rusty Russell's (author of the firewall code in the kernel)
    > site at http://www.iptables.org/documentation/HOWTO/
    >
    > Old guy


    Thanks for the reply,

    Yes i did change the firewall settings, but still using webmin /
    turtlefirewall (I have not mastered doing it manually in iptables yet)

    The machine has 3 network cards in it 1 external and 2 internal.
    The firewall was setup to do the following:
    firewall to external (all services)
    external to firewall (smtp, http)
    firewall to localnetwork (all services)
    external to firewall (reject all)

    Dave.


  4. Re: iptables, port scan, sendmail overload

    On 21 Dec 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <1166770262.348868.120520@48g2000cwx.googlegroups.c om>, Dave wrote:

    >Yes i did change the firewall settings, but still using webmin /
    >turtlefirewall (I have not mastered doing it manually in iptables yet)


    Assuming this is a firewall problem (likely, but may not be the only
    cause), the usual cause is an overly complex rule-set. You should be
    able to see that has been created by running the command

    /sbin/iptables -L

    I suspect you have some form of logging enabled, perhaps with name
    resolution, and the portscan quite overloaded this mechanism. You
    really do want to solve this problem, as you have created a 'shoot
    yourself in the wobbly-bits' situation. As for logging, I tend to
    use it quite sparingly. As you probably are all to well aware, there
    is no Internet Police that will do anything useful. Abuse reports to
    many ISPs are simply ignored, even assuming there is someone who can
    understand your language. A simpler solution is to simply block abusive
    address ranges. Quick thought - you don't have the firewall trying to
    mail you anything, do you?

    >The machine has 3 network cards in it 1 external and 2 internal.


    and is also running two or three servers (web, mail, and DNS)?

    >The firewall was setup to do the following:
    >firewall to external (all services)
    >external to firewall (smtp, http)
    >firewall to localnetwork (all services)
    >external to firewall (reject all)


    It's difficult to translate that into desired rule-sets, but this
    _probably_ shouldn't generate more than something like 20 rules, but
    that's just a guess.

    Old guy

  5. Re: iptables, port scan, sendmail overload


    Moe Trin wrote:
    > On 21 Dec 2006, in the Usenet newsgroup comp.os.linux.security, in article
    > <1166770262.348868.120520@48g2000cwx.googlegroups.c om>, Dave wrote:
    >
    > >Yes i did change the firewall settings, but still using webmin /
    > >turtlefirewall (I have not mastered doing it manually in iptables yet)

    >
    > Assuming this is a firewall problem (likely, but may not be the only
    > cause), the usual cause is an overly complex rule-set. You should be
    > able to see that has been created by running the command
    >
    > /sbin/iptables -L
    >
    > I suspect you have some form of logging enabled, perhaps with name
    > resolution, and the portscan quite overloaded this mechanism. You
    > really do want to solve this problem, as you have created a 'shoot
    > yourself in the wobbly-bits' situation. As for logging, I tend to
    > use it quite sparingly. As you probably are all to well aware, there
    > is no Internet Police that will do anything useful. Abuse reports to
    > many ISPs are simply ignored, even assuming there is someone who can
    > understand your language. A simpler solution is to simply block abusive
    > address ranges. Quick thought - you don't have the firewall trying to
    > mail you anything, do you?
    >
    > >The machine has 3 network cards in it 1 external and 2 internal.

    >
    > and is also running two or three servers (web, mail, and DNS)?
    >
    > >The firewall was setup to do the following:
    > >firewall to external (all services)
    > >external to firewall (smtp, http)
    > >firewall to localnetwork (all services)
    > >external to firewall (reject all)

    >
    > It's difficult to translate that into desired rule-sets, but this
    > _probably_ shouldn't generate more than something like 20 rules, but
    > that's just a guess.
    >
    > Old guy


    I really do appreciate the help you are giving me, and as you probably
    saw in the other newsgroup I am trying to get away from turtlefirewall,
    and use iptables directly so i can understand the way it works. The
    firewall is running web, samba and mail servers but the load has never
    got over 7% before.

    As far as I am aware, the firewall is not set to email me anything, and
    we have never had emails from it.

    I have done the iptables -L and posted the outcome below. If you are
    correct that there should only be around 20 rules, then I really have
    to get away from this turtlefirewall, cause there looks a lot more than
    20 to me!!!

    When i view the rules in turtlefirewall it only shows the 4 rules i set
    up (as previously posted)

    > /sbin/iptables -L

    Chain BACK (8 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere state
    RELATED,ESTABLISHED
    RETURN all -- anywhere anywhere

    Chain CHECK_INVALID (3 references)
    target prot opt source destination
    INVALID all -- anywhere anywhere state
    INVALID
    INVALID tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
    INVALID tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,PSH,ACK,URG/NONE
    INVALID tcp -- anywhere anywhere tcp
    flags:FIN,ACK/FIN
    INVALID tcp -- anywhere anywhere tcp
    flags:FIN,SYN/FIN,SYN
    INVALID tcp -- anywhere anywhere tcp
    flags:SYN,RST/SYN,RST
    INVALID all -f anywhere anywhere
    RETURN all -- anywhere anywhere

    Chain EXTERNAL-EXTERNAL (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW EXTERNAL-EXTERNAL:'
    DROP all -- anywhere anywhere

    Chain EXTERNAL-FIREWALL (1 references)
    target prot opt source destination
    BACK all -- anywhere anywhere
    ACCEPT tcp -- anywhere anywhere tcp
    dpt:http
    ACCEPT tcp -- anywhere anywhere tcp
    dpt:smtp
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW EXTERNAL-FIREWALL(REJ):'
    REJECT all -- anywhere anywhere
    reject-with icmp-port-unreachable
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW EXTERNAL-FIREWALL:'
    DROP all -- anywhere anywhere

    Chain EXTERNAL-SAMBA1 (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW EXTERNAL-SAMBA1:'
    DROP all -- anywhere anywhere

    Chain EXTERNAL-SAMBA2 (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW EXTERNAL-SAMBA2:'
    DROP all -- anywhere anywhere

    Chain FIREWALL-EXTERNAL (1 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    BACK tcp -- anywhere anywhere tcp
    spt:http
    BACK tcp -- anywhere anywhere tcp
    spt:smtp
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW FIREWALL-EXTERNAL:'
    DROP all -- anywhere anywhere

    Chain FIREWALL-SAMBA1 (1 references)
    target prot opt source destination
    BACK all -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW FIREWALL-SAMBA1:'
    DROP all -- anywhere anywhere

    Chain FIREWALL-SAMBA2 (1 references)
    target prot opt source destination
    BACK all -- anywhere anywhere
    ACCEPT all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW FIREWALL-SAMBA2:'
    DROP all -- anywhere anywhere

    Chain ICMP-ACC (0 references)
    target prot opt source destination
    ACCEPT icmp -- anywhere anywhere icmp
    destination-unreachable
    ACCEPT icmp -- anywhere anywhere icmp
    source-quench
    ACCEPT icmp -- anywhere anywhere icmp
    time-exceeded
    ACCEPT icmp -- anywhere anywhere icmp
    parameter-problem
    RETURN all -- anywhere anywhere

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    CHECK_INVALID all -- anywhere anywhere
    EXTERNAL-FIREWALL all -- anywhere anywhere
    SAMBA1-FIREWALL all -- anywhere anywhere
    SAMBA2-FIREWALL all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW INPUT:'

    Chain FORWARD (policy DROP)
    target prot opt source destination
    CHECK_INVALID all -- anywhere anywhere
    EXTERNAL-EXTERNAL all -- anywhere anywhere
    EXTERNAL-SAMBA1 all -- anywhere anywhere
    EXTERNAL-SAMBA2 all -- anywhere anywhere
    SAMBA1-EXTERNAL all -- anywhere anywhere
    SAMBA1-SAMBA1 all -- anywhere anywhere
    SAMBA1-SAMBA2 all -- anywhere anywhere
    SAMBA2-EXTERNAL all -- anywhere anywhere
    SAMBA2-SAMBA1 all -- anywhere anywhere
    SAMBA2-SAMBA2 all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW FORWARD:'

    Chain INVALID (7 references)
    target prot opt source destination
    LOG all -- anywhere anywhere state
    INVALID limit: avg 1/hour burst 2 LOG level warning prefix `TFW INVALID
    STATE:'
    LOG tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG limit: avg 1/hour
    burst 2 LOG level warning prefix `TFW INVALID ALL:'
    LOG tcp -- anywhere anywhere tcp
    flags:FIN,SYN,RST,PSH,ACK,URG/NONE limit: avg 1/hour burst 2 LOG level
    warning prefix `TFW INVALID NONE:'
    LOG tcp -- anywhere anywhere tcp
    flags:FIN,ACK/FIN limit: avg 1/hour burst 2 LOG level warning prefix
    `TFW INVALID FIN,!ACK:'
    LOG tcp -- anywhere anywhere tcp
    flags:FIN,SYN/FIN,SYN limit: avg 1/hour burst 2 LOG level warning
    prefix `TFW INVALID SYN,FIN:'
    LOG tcp -- anywhere anywhere tcp
    flags:SYN,RST/SYN,RST limit: avg 1/hour burst 2 LOG level warning
    prefix `TFW INVALID SYN,RST:'
    LOG all -f anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW INVALID fragment:'
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW INVALID PACKET:'
    DROP all -- anywhere anywhere

    Chain OUTPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    CHECK_INVALID all -- anywhere anywhere
    FIREWALL-EXTERNAL all -- anywhere anywhere
    FIREWALL-SAMBA1 all -- anywhere anywhere
    FIREWALL-SAMBA2 all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW OUTPUT:'

    Chain SAMBA1-EXTERNAL (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA1-EXTERNAL:'
    DROP all -- anywhere anywhere

    Chain SAMBA1-FIREWALL (1 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    BACK all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA1-FIREWALL:'
    DROP all -- anywhere anywhere

    Chain SAMBA1-SAMBA1 (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA1-SAMBA1:'
    DROP all -- anywhere anywhere

    Chain SAMBA1-SAMBA2 (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA1-SAMBA2:'
    DROP all -- anywhere anywhere

    Chain SAMBA2-EXTERNAL (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA2-EXTERNAL:'
    DROP all -- anywhere anywhere

    Chain SAMBA2-FIREWALL (1 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    BACK all -- anywhere anywhere
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA2-FIREWALL:'
    DROP all -- anywhere anywhere

    Chain SAMBA2-SAMBA1 (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA2-SAMBA1:'
    DROP all -- anywhere anywhere

    Chain SAMBA2-SAMBA2 (1 references)
    target prot opt source destination
    LOG all -- anywhere anywhere limit: avg
    1/hour burst 2 LOG level warning prefix `TFW SAMBA2-SAMBA2:'
    DROP all -- anywhere anywhere


  6. Re: iptables, port scan, sendmail overload

    On 22 Dec 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <1166823480.095067.294940@a3g2000cwd.googlegroups.c om>, Dave wrote:

    >I really do appreciate the help you are giving me, and as you probably
    >saw in the other newsgroup I am trying to get away from turtlefirewall,
    >and use iptables directly so i can understand the way it works.


    There is a lot of documentation out there. In the HOWTOs that should be
    installed on your system, check

    -rw-rw-r-- 1 gferg ldp 85507 Aug 20 2001 Firewall-HOWTO
    -rw-rw-r-- 1 gferg ldp 708351 Nov 14 2005 IP-Masquerade-HOWTO
    -rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO
    -rw-rw-r-- 1 gferg ldp 278012 Jul 23 2002 Security-Quickstart-HOWTO

    but the real authoritative documents are on Rusty Russell's site at
    http://www.iptables.org/documentation/HOWTO/ I would recommend
    starting with the 'packet-filtering-HOWTO' and then see if there is
    anything interesting/useful in the 'netfilter-extensions-HOWTO'.

    >The firewall is running web, samba and mail servers but the load has
    >never got over 7% before.


    Had you tried to port scan the box before?

    >As far as I am aware, the firewall is not set to email me anything, and
    >we have never had emails from it.


    That was only a 'what-if' type of question - was the firewall adding load
    to the MTA as well. The output you show indicates that it's only sticking
    stuff into the logs. In theory, syslog could be set to mail this, but I
    don't know of anyone doing it that way.

    >I have done the iptables -L and posted the outcome below. If you are
    >correct that there should only be around 20 rules, then I really have
    >to get away from this turtlefirewall, cause there looks a lot more than
    >20 to me!!!


    Not only that, they look somewhat different from what I'm used to seeing.
    The one thing that catches my eye is the log limits are set lower than
    normal which should limit (to some extent) a denial of service condition.
    (If you look at the 'LOG' lines, they all have 1/hour average limits, and
    a burst of 2 before the limit kicks in - the defaults are 3 and 5.) You
    may want to look at /etc/syslog.conf to see where 'kernel:warning' messages
    are going ('man syslog.conf' if you aren't familiar with the file syntax),
    and see what the port scan produced in that log. Look for stuff with a
    'TFW' message prefix in the logs - should be quite obvious to find. Other
    than that, I don't see anything obvious.

    You may also want to look at that windoze port-scanner and see exactly
    what it was doing. You mentioned "it was showing me that there was around
    15 ports open (all UDP) on weird ports". How was it determining this?
    Most scanners I'm aware of declare a UDP port is open if they don't get
    an ICMP Destination Unreachable (Type 3, usually Port [code 3],
    occasionally Protocol [code 2]) when they try a connect. Your iptables -L
    output shows the default input policy to be DROP rather than REJECT, so
    it wouldn't return an ICMP Type 3. (Comment: I do DROP UDP to ports 1025
    to 1050, because that's usually windoze messenger spam and often has
    obviously spoofed source addresses - no need to try to tell some innocent
    host to FOAD. For the rest. I simply REJECT.)

    Most port scanners don't (by default) hit every port or every protocol or
    the exotic combinations of IP flags. 'nmap' for example defaults to 1-1024
    and those ports listed in the /usr/local/share/nmap/nmap-services file
    (which may add another 1100 ports). Given that there are 65535 TCP and
    UDP ports, and nearly 140 protocols that can be found in an IP packet,
    and the RFC1812 recommendation to limit the rate of ICMP packets, a "full"
    port scan can take a long time. But then, knowing what you've got
    installed on your system usually alleviates the need to do a full scan.

    >When i view the rules in turtlefirewall it only shows the 4 rules i set
    >up (as previously posted)


    In one of your comp.mail.sendmail posts, you mention Solaris, so I'm
    sure you are aware of system administrative "helper" tools, such as
    'admintool', 'useradd, and so on. A major problem is that these tools
    hide details, such that you're really not sure what they are doing.
    When the cheese gets binding (as in this case), the helper tool is less
    than helpful.

    The actual firewall code is a part of the kernel. Tools like
    turtlefirewall (there are hundreds of different ones) are helpers trying
    to simplify the task of setting up a firewall. But it all can be done
    with a relatively simple script, as shown in the various HOWTOs. You
    haven't mentioned which distribution/release this is, but some come with
    their own helper tools, while others may simply run the firewall out of
    a relatively crude boot script (perhaps named something like
    /etc/init.d/firewall or /etc/rc.d/init.d/firewall).

    Old guy

+ Reply to Thread