IPTables : Stealth except SMTP
Transmute
Hello all,
I've been trying to set up a very basic IPTable script, which mimicks a NAT router for
not accepting new connections from the Internet, if that's the right technology, but
allows SMTP inbound and outbound. I also want normal web activity too.
I went to http://scan.sygate.com/ in order to test my script, and was pleased to see
that all ports were stealthed, according to that scan. However, my smtp capabilities
also seem to be stealthed, which isn't what I wanted.
Could someone have a look at my script and maybe give me a pointer as to why the smtp
port, for inbound and outbound, is stealthed along with the rest of the ports
#Basic IPTables script
#Flush chain rules
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
#Set Default Policy
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
#Allow SMTP
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --sport 25 -j ACCEPT
#Prevent outside initiated connections
#iptables -A INPUT -m state --state NEW -i eth0 -j DROP
#iptables -A FORWARD -m state --state NEW -i eth0 -j DROP
#End of rules
I've commented out the last couple of rules, to allow my mail server to work in the meantime.
My way of looking at the above script at present, makes me think that the smtp port would be
opened up as it's before the 'drop new connections' rules. I can't see a way forward in this
script if rules are not read from top to bottom, as I'm used to thinking of them.
I realise my script is pretty basic, and probably has things in it that don't need to be there,
but my reasoning was that if I can just stop unsolicited incoming connections, and give my
mail server access to the Internet, that would be enough for me.
Thanks for your time and any information you might have.
Regards,
Pete.
Joost Kremers
> #Allow SMTP
> iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
i'm assuming this must be --sport
> iptables -A INPUT -p tcp --sport 25 -j ACCEPT
and this --dport.
--
Joost Kremers joostk...@yahoo.com
since when is vi an editor? a discussion on vi belongs in
comp.tools.unusable or something... ;-)
/dev/rob0
In article <af6dnbq0Drb...@giganews.com>, Transmute wrote:
> Could someone have a look at my script and maybe give me a pointer as to why the smtp
> port, for inbound and outbound, is stealthed along with the rest of the ports
It's possible that your ISP is blocking SMTP in or out. Many do both.
> #Basic IPTables script
#include=<joost-reply.h> // Mind your d's and s's!
With these rules commented:
> #Prevent outside initiated connections
> #iptables -A INPUT -m state --state NEW -i eth0 -j DROP
> #iptables -A FORWARD -m state --state NEW -i eth0 -j DROP
This script blocks nothing. Every packet will land on an ACCEPT rule.
> Thanks for your time and any information you might have.
The iptables-HOWTO at www.netfilter.org (I think I heard tldp.org is
publishing it as well, finally) has some simple and easy-to-understand
examples which will get you going very quickly. You should have a rule
to ACCEPT all "--state RELATED,ESTABLISHED" connections. Is this box
acting as a router for others? If not, block off the FORWARD chain
altogether. If so, the FORWARD chain has a great potential for confusion
because it gets both packets from internal and external sources.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply
Transmute
> Please adjust your word wrap settings. Thanks.
Sorry about that. I'm just experimenting with the configuration of
vim, via vimrc, and I hadn't quite got it set up right there.
> It's possible that your ISP is blocking SMTP in or out. Many do both.
I've heard of this, but it isn't the case here. It's my lack of skill
with the script. But there is a light at the end of this particularly
short tunnel. :)
> #include=<joost-reply.h> // Mind your d's and s's!
Sorry, I don't understand this.
> With these rules commented:
>> #Prevent outside initiated connections
>> #iptables -A INPUT -m state --state NEW -i eth0 -j DROP
>> #iptables -A FORWARD -m state --state NEW -i eth0 -j DROP
> This script blocks nothing. Every packet will land on an ACCEPT rule.
Not surprised, I forgot to add the any protocols didn't I ? Thanks for
the pointer anyway.
> The iptables-HOWTO at www.netfilter.org (I think I heard tldp.org is
> publishing it as well, finally) has some simple and easy-to-understand
> examples which will get you going very quickly. You should have a rule
> to ACCEPT all "--state RELATED,ESTABLISHED" connections. Is this box
> acting as a router for others? If not, block off the FORWARD chain
> altogether. If so, the FORWARD chain has a great potential for confusion
> because it gets both packets from internal and external sources.
Thanks for the tip about RELATED,ESTABLISHED. This box isn't acting as
any kind of router or gateway. It's just connected straight to a cable
modem.
I've re-written the script, shown below, taking into account what was
said in the responses to my original question. Many thanks to all
posters.
The following script now appears to do what I want. On both the
Shields Up test at http://www.grc.com, and the scans available at
http://scan.sygate.com, I have found that all new (SYN) packets for
TCP/UDP are dropped (stealthed/blocked), whilst my smtp port is open
for business. I've denied incoming ICMP (AFAIK) but allowed myself to
do stuff like ping out. See what you think.
#Basic IPTables Script
#Created on 19/11/03 by Pete.
#This script denies new incoming TCP/UDP/ICMP connections, whilst
#allowing any established or related TCP/UDP/ICMP connections. Port 25
#(smtp) is opened for the mail server.
#This script is run on a workstation PC, running Slackware 9.1, that
#is
#connected directly to a cable modem. No forwarding is required.
#Flush chain rules
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
#Set Default Policy
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
#Prevent new TCP connections whilst allowing port 25, and all related/
#established connections
iptables -A INPUT -m state --state NEW -i eth0 -p tcp ! --dport smtp
-j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p tcp
-j ACCEPT
#Prevent new UDP connections whilst allowing all related/established
#connections
iptables -A INPUT -m state --state NEW -i eth0 -p udp -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p udp
-j ACCEPT
#Prevent all new ICMP connections, whilst allowing related/established
#connections
iptables -A INPUT -m state --state NEW -i eth0 -p icmp -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p icmp
-j ACCEPT
This script works very well now. If there's any gaping holes I've left
out, I'd be grateful for any pointers about them. My mail server is
set up correctly (tested at http://www.abuse.net/relay.html) and is
not acting as an open relay.
I'm very pleased with the set up here now. All that was needed to 'put
the icing on the cake' was to add a little line to rc.local, purely
for 'pose' factor. :)
echo "Firewall is up ! Shields established !"
/usr/bin/myscript
Regards,
Pete.
AthlonRob
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
On Wed, 19 Nov 2003 13:51:42 -0600, Transmute <user...@host.domain> wrote:
>> #include=<joost-reply.h> // Mind your d's and s's!
>
> Sorry, I don't understand this.
I don't think many compilers will parse that, either...
Does-
#include <joost-reply>
using namespace std;
help? :-)
He's just saying mind your d's and s's, as per the response Joost gave
to your post.
> echo "Firewall is up ! Shields established !"
> /usr/bin/myscript
I think it would be more standard to put your firewall in
/etc/rc.d/rc.firewall rather than /usr/bin/myscript... not that it
really matters much.
Also, it would probably be more appropriate to switch the two lines
around, so you aren't announcing the firewall is up until it has
actually run. Better yet, put some echo lines in your firewall script
so the user can follow what's happening and when.
--
Rob | If not safe,
Email and Jabber: | one can never be free.
athlonrob at axpr dot net |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/u87Qhm6KEoOOAe0RAthSAKCWsWGi5V4oHHEMuw3yZ0qHbjfhCACg2SoG
S5jPf+8fMxa6l2RU0tbeGIg=
=9DY9
-----END PGP SIGNATURE-----
Joost Kremers
> #Prevent new TCP connections whilst allowing port 25, and all related/
> #established connections
> iptables -A INPUT -m state --state NEW -i eth0 -p tcp ! --dport smtp
> -j DROP
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p tcp
> -j ACCEPT
one tip: use full paths to binaries in scripts. so don't say 'iptables' but
'/usr/sbin/iptables', or wherever the binary is.
perhaps someone with more knowledge of iptables will correct me, but AFAIK
you can create a much simpler script. i set my default policy for INPUT to
DROP, so you don't need to specify it for each protocol. also, if you
specify '-p all' you capture tcp, icmp and udp all at once. (and since that
is the default for -p, you can even leave it out altogether.)
so you basically just need this, which is the core of my rc.firewall:
#v+
echo "Setting up firewall..."
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#$IPTABLES -A INPUT -p tcp --dport ssh -j ACCEPT
#v-
(where IPTABLES contains the full path to the iptables binary.)
well, i've commented out ssh, because i don't use it ATM. in your case, you
would add a similar rule to allow incoming smtp connections.
like i said, i'm no iptables expert, so perhaps i'm doing something very
daft, but AFAIK this works well.
Transmute
>>> #include=<joost-reply.h> // Mind your d's and s's!
>>
>> Sorry, I don't understand this.
>
> I don't think many compilers will parse that, either...
>
> Does-
>
> #include <joost-reply>
> using namespace std;
>
> help? :-)
Sort of. :)
> He's just saying mind your d's and s's, as per the response Joost gave
> to your post.
Ah, I see. Thanks.
> I think it would be more standard to put your firewall in
> /etc/rc.d/rc.firewall rather than /usr/bin/myscript... not that it
> really matters much.
Done.
> Also, it would probably be more appropriate to switch the two lines
> around, so you aren't announcing the firewall is up until it has
> actually run. Better yet, put some echo lines in your firewall script
> so the user can follow what's happening and when.
My only line in rc.local :
/etc/rc.d/rc.firewall
Here is the new remixed version of my basic IPTables script (sorry for
the wrap) :
#Basic IPTables Script
#Created on 19/11/03 by Pete.
#This script denies new incoming TCP/UDP/ICMP connections, whilst
#allowing any established or related TCP/UDP/ICMP connections. Port 25
#(smtp) is opened for the mail server.
#This script is run on a workstation PC, running Slackware 9.1, that
is
#connected directly to a cable modem. No forwarding is required.
echo "Applying iptables script in /etc/rc.d/rc.firewall"
#Flush chain rules
echo "Flushing chain rules ..."
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
#Set Default Policy
echo "Setting default policy. INPUT/OUTPUT=ACCEPT , FORWARD=DROP"
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
#Prevent new TCP connections whilst allowing port 25, and all related/
#established connections
echo "Stealthing TCP ports, allowing SMTP incoming and established or
related connections"
iptables -A INPUT -m state --state NEW -i eth0 -p tcp ! --dport smtp
-j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p tcp
-j ACCEPT
#Prevent new UDP connections whilst allowing all related/established
#connections
echo "Stealthing UDP ports, whilst allowing established or related
connections"
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p udp
-j ACCEPT
#Prevent all new ICMP connections, whilst allowing related/established
#connections
echo "Stealthing ICMP ports, whilst allowing established or related
connections"
iptables -A INPUT -m state --state NEW -i eth0 -p icmp -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p icmp
-j ACCEPT
echo
"***********************************************************************"
echo "*Shields established. Firewall configuration complete. Now
running ...*"
echo
"***********************************************************************"
#EOF
Heh, my first script ever ! Guinness anyone ?
Regards,
Pete.
Transmute
Many thanks for the information there. I read your reply right after I
posted my new 'updated' firewall. I will 'weed' mine another day to
make it simpler, applying some of your settings.
Thanks for the tip about the binary path.
Regards,
Pete.
chud
> Hello all,
>
> I've been trying to set up a very basic IPTable script, which mimicks a
> NAT router for not accepting new connections from the Internet, if
> that's the right technology, but allows SMTP inbound and outbound. I
> also want normal web activity too.
"Linux Firewalls" by Robert Ziegler is an excellent reference if you want
to learn more about iptables specifically and firewalls in general.
/dev/rob0
>> #include=<joost-reply.h> // Mind your d's and s's!
>
> Sorry, I don't understand this.
Supposed to be a cute (C-ish) way to say Joost was right in his reply
(which I read before posting my own.) I think you had the -d and -s
reversed.
> #Basic IPTables Script [snip]
> iptables -P INPUT ACCEPT
I'd do DROP here.
> iptables -A INPUT -m state --state NEW -i eth0 -p tcp ! --dport smtp
> -j DROP
You're explicitly only dropping NEW packets. I'd take this out ...
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -i eth0 -p tcp
> -j ACCEPT
... take out the "-p tcp" here, then put ...
# iptables -A INPUT -i eth0 -p tcp --dport smtp -j ACCEPT
# iptables -A INPUT -i ! eth0 -j ACCEPT
It's good to have the RELATED,ESTABLISHED rule first because that covers
most of your traffic. Then you'll get a nice count of all your inbound
SMTP connections in the iptables packet counter. The "-i ! eth0" rule
lets in all your lo traffic.
> #Prevent new UDP connections whilst allowing all related/established
> #connections
Superfluous with a DROP policy and an all-prococol RELATED,ESTABLISHED
rule above. Same with the ICMP rules.
> This script works very well now.
Yes, it should. These are stylistic suggestions (which I'll bet make
sense to you now, right?) for the most part.
> If there's any gaping holes I've left
> out, I'd be grateful for any pointers about them.
Some say you should always drop all state INVALID packets at the top.
I'm no expert, but I think that only dropping NEW could be a risk. <Off
to check "man iptables"> Okay, maybe not, since you're only letting in
ESTABLISHED, INVALID and RELATED.
I don't know of any harm from not dropping INVALID packets, except you
might be open to some sort of attack on the TCP/IP stack. Surely there
is no reason NOT to drop them.
> echo "Firewall is up ! Shields established !"
> /usr/bin/myscript
1. It's better form to run the firewall first, then brag about it being
up. When you get fancier in your scripting it's fun to check for the
exit code and give a variable message based upon that.
2. /usr/bin is the wrong place for this. Why? 2 reasons: Only root can
change netfilter rules, and it's a local script. If I were you I'd
put the script in /usr/local/sbin and make /etc/rc.d/rc.firewall a
symbolic link to it. (Then it will be called from rc.inet2.)
Good luck, congratulations, and HTH. You've got a big learning curve
ahead: enjoy every bit of it. :)
Summary (some fanciness added):
#v+
#!/bin/sh
# Basic IPTables Script
# to make this more portable let's use variables; I hope it's easy
# enough to understand this way!
EXTIF=eth0 # the external interface
IPT=/usr/sbin/iptables # path to iptables binary
EXITCODE=0 # we'll add to this on errors
# this is how you'd check for errors; just call this function after each
# iptables command.
#function check4error() {
# EXITCODE=$((EXITCODE + $?)) # $? is the last command's exit value
#}
# Actually it would be cleaner to substitute a function for $IPT:
#function IPT() {
# /usr/sbin/iptables $@ # $@ means all parameters given
# EXITCODE=$((EXITCODE + $?))
#}
$IPT -F
$IPT -X
$IPT -P OUTPUT ACCEPT
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -i $EXTIF -j ACCEPT
$IPT -A INPUT -i $EXTIF -p tcp --dport smtp -j ACCEPT
$IPT -A INPUT -i ! $EXTIF -j ACCEPT
# if this is nonzero your rc.local could warn you
exit $EXITCODE
#v-
Jack S. Lai
Hash: SHA1
Transmute wrote:
<snip>
> My only line in rc.local :
>
> /etc/rc.d/rc.firewall
Depending on which Slackware your running (>=9.0?) you don't need that in
rc.local as rc.inet2 runs it if found and executable.
- --
Jack S. Lai - Senior Systems Analyst
http://www.datagraphinc.com
Slackware Tips & Tricks
http://members.cox.net/laitcg/slack.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/vEFH9/VKdZrnv3YRAtYDAJ9CjM9w6I5oTvSMiqPW0lX9VzfXBQCeL8BK
7U0JonCO4rk23Ygy0gylC18=
=u6ev
-----END PGP SIGNATURE-----
Transmute
> ahead: enjoy every bit of it. :)
Many thanks for the extra info and the time spent posting it here. I
knew this wasn't going to be an easy process, but it's an enjoyable
one, so I don't mind if it takes me a while to understand stuff.
BTW, the last 'version' of my script had an error, or rather, an
omission in it. During editing of it last night, I must've somehow
deleted a whole line !
In the section dealing with UDP packets, I missed/deleted the line :
iptables -A INPUT -m state --state NEW -i eth0 -p udp -j DROP
It's back in there now, but I'm going to review this script, taking
into consideration all what people have said here. Thanks to you all
for your time and effort.
Regards,
Pete.
Menno Duursma
> On 2003-11-19, AthlonRob <junk...@axpr.net> said:
>>>> #include=<joost-reply.h> // Mind your d's and s's!
>>>
>>> Sorry, I don't understand this.
>>
>> I don't think many compilers will parse that, either...
>>
>> Does-
>>
>> #include <joost-reply>
>> using namespace std;
>>
>> help? :-)
>
> Sort of. :)
That'd be C++.
For C just (and any C++ compiler will swallow this as well):
#include <joost-reply.h> /* Mind your d's and s's! */
But gcc will let you can get away with:
#include <joost-reply.h> // Mind your d's and s's!
Unless you feed it "-pedantic" as well.
--
-Menno.
Menno Duursma
>
> perhaps someone with more knowledge of iptables will correct me, but AFAIK
> you can create a much simpler script.
I don't know if i have "more knowledge of iptables". But yes, you can.
> i set my default policy for INPUT to
> DROP, so you don't need to specify it for each protocol. [...]
I do that for OUTPUT and FORWARD as well.
However, in such a setup you have to explicitly allow anything you want to
pass. The upside though, is you have better control and the "firewall"
will fail-closed (as opposed to fail-open) with should be more secure.
[ Snip ]
> $IPTABLES -P INPUT DROP
> $IPTABLES -F INPUT
> $IPTABLES -P OUTPUT ACCEPT
> $IPTABLES -F OUTPUT
> $IPTABLES -P FORWARD DROP
> $IPTABLES -F FORWARD
This could be shortend to:
# Clean any old stuff (build-in and home-grown (if any))
${IPTABLES} -F
${IPTABLES} -X
# Set default policy
${IPTABLES} -P INPUT DROP
${IPTABLES} -P FORWARD DROP
${IPTABLES} -P OUTPUT ACCEPT
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> #$IPTABLES -A INPUT -p tcp --dport ssh -j ACCEPT
This will brake some commen used protocols. That might not be a problem
for ya'll, however i'll point some out anyways:
(Non of the code is tested BTW.)
Being a DHCP client. You will need to allow `ping' comming in from the
server. As well as UDP packets from port 67 directed at your port 68.
${IPTABLES} -A INPUT -i ${EXT_IF} -d ${EXT_IP} -p icmp \
--icmp-type echo-request -s ${DHCP_SRV} -j ACCEPT
${IPTABLES} -A INPUT -i ${EXT_IF} -p udp \
--dp 68 -s ${DHCP_SRV} --sp 67 -j ACCEPT
Ident/auth, used on many IRC, FTP and mail servers. Some will let you
connect (if it fails) anyways however most will try 3 times before doing
so, and thus initial connecting will be slower. This may fix:
${IPTABLES} -A INPUT -i ${EXT_IF} -d ${EXT_IP} -p tcp \
--dp 113 -j REJECT --reject-with tcp-reset
(You might have to run identd and allow query's for some sites - still.)
And some protocols which might be less common, such as "ftps" (ie: SSL/TLS
secured FTP) and H.323 (ie: Netmeeting) and others.
> (where IPTABLES contains the full path to the iptables binary.)
That is always good advice. However you could set the PATH in the script.
> well, i've commented out ssh, because i don't use it ATM. in your case, you
> would add a similar rule to allow incoming smtp connections.
>
> like i said, i'm no iptables expert, so perhaps i'm doing something very
> daft, but AFAIK this works well.
You might want to disallow fragmented and invalid packets before doing any
processing on them. Because netfilter may act funny encontering them at
some stages (and can't know where they came from anyways).
${IPTABLES} -A INPUT -i ${EXT_IF} -f -j DROP
${IPTABLES} -A INPUT -i ${EXT_IF} -m state --state INVALID -j DROP
HTH.
--
-Menno.
AthlonRob
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
On Thu, 20 Nov 2003 09:21:43 GMT, Menno Duursma <me...@desktop.lan> wrote:
>>> #include <joost-reply>
>>> using namespace std;
>
> That'd be C++.
Yep, very good. :-)
Could put:
source joost-reply.sh
to make it bash, too. :-)
> For C just (and any C++ compiler will swallow this as well):
>
> #include <joost-reply.h> /* Mind your d's and s's! */
>
> But gcc will let you can get away with:
>
> #include <joost-reply.h> // Mind your d's and s's!
>
> Unless you feed it "-pedantic" as well.
Using includes like that, with C++ (the commenting works fine), results
in some compiler warnings if you're using an up-to-date GCC. They
prefer the way I wrote it, above.
--
Rob | If not safe,
Email and Jabber: | one can never be free.
athlonrob at axpr dot net |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/vPHahm6KEoOOAe0RAnsVAKCkm27IaZWiIjEaNMgyPPKmioo+zQCg4XB9
1aDTTzLzZ9q6G/OYQpo85NY=
=z/pB
-----END PGP SIGNATURE-----
Joost Kremers
> Being a DHCP client. You will need to allow `ping' comming in from the
> server. As well as UDP packets from port 67 directed at your port 68.
mmm... i don't seem to have any problems with this. are you sure it's
necessary, or could it perhaps be covered by the conntrack modules?
> Ident/auth, used on many IRC, FTP and mail servers. Some will let you
well, i don't use IRC, nor a mail server. (mail is sent to a smart host and
received through IMAP.) i do notice slow log-ins for FTP at times, though...
thanks for the tips!
Menno Duursma
> Menno Duursma wrote:
>> Being a DHCP client. You will need to allow `ping' comming in from the
>> server. As well as UDP packets from port 67 directed at your port 68.
>
> mmm... i don't seem to have any problems with this.
In that case you connect via an ISP who do proper house-keep'n of
leases they have open (and of which the IP range is broad enough - for
all the clients they provide access for).
However, RFC 2131 paragraph 3.1 states:
"When allocating a new address, servers SHOULD check that the offered
network address is not already in use; e.g., the server may probe the
offered address with an ICMP Echo Request."
And i know from working at an ISP (if there short on leases) they might
just ping a client, and give out the adress to a newley connecting
machine upon getting no response, from it...
> are you sure it's necessary,
Yes.
> or could it perhaps be covered by the conntrack modules?
No. The normal releaseing will work fine (as you connect to them) but it
brakes upon them connecting to you - intermediate the lease-time.
Problem however here is, you don't realy know which DHCP-server is going
to try and connect to you (most ISP' use 2 IP/MAC aresses to provde leases
from) so it might be a good idee even to sniff the network for a while and
filter on both MAC and IP adresses you find (if indeed there are two).
Also, on initial connect, your box broadcasts it's MAC adress to try
and get a lease. And your firewall should either allow for that, or be
enabled only after the fact.
>> Ident/auth, used on many IRC, FTP and mail servers. Some will let you
>
> well, i don't use IRC, nor a mail server. (mail is sent to a smart host
> and received through IMAP.)
Ok, some don't even probe though.
> i do notice slow log-ins for FTP at times, though...
This is probably do "tcpwrapper" settings ion there side. And they may
probe to see if user "joost" (or whatever) does indeed exist on your box.
A TCP reset should speed up connecting to most. Though you might want to
run and "bugus answer identd" which just responds "yes - there is indeed a
user /whatever/ on this host" no matter what username they probe for.
Such as:
http://www.guru-group.fi/~too/sw/releases/identd.c
> thanks for the tips!
Sure thing.
--
-Menno.
Menno Duursma
> On Thu, 20 Nov 2003 09:21:43 GMT, Menno Duursma <me...@desktop.lan> wrote:
>>>> #include <joost-reply>
>>>> using namespace std;
>>
>> That'd be C++.
>
> Yep, very good. :-)
>
> Could put:
>
> source joost-reply.sh
>
> to make it bash, too. :-)
Yeah, or:
@INC = '/path/to/something';
To make it Prul.
[..]
>> #include <joost-reply.h> // Mind your d's and s's!
>>
>> Unless you feed it "-pedantic" as well.
>
> Using includes like that, with C++ (the commenting works fine), results
> in some compiler warnings if you're using an up-to-date GCC.
Didn't know that. Works fine with "-Wall" as C code.
But it gives a warning if you use "-pedantic".
However i was wrong on it erroring out on that, you'd need
"-pedantic-errors" if you want it to realy fail :-).
> They prefer the way I wrote it, above.
Ok, see i learn - tanks.
However, what puzzled me about this:
Is the file joost-reply.h in /usr/include or some such?
Or, the gcc/g++ modified to look elsewere?
Do you need to -L/something/lib -I/something/include -l/joost-reply
to make this work (or some such)?
Or is it in the $CWD and he ment:
#include "joost-reply.h" // Mind your d's and s's!
Heh.
--
-Menno.
Joost Kremers
> On Thu, 20 Nov 2003 08:54:51 -0800, AthlonRob wrote:
>> On Thu, 20 Nov 2003 09:21:43 GMT, Menno Duursma <me...@desktop.lan> wrote:
>>>>> #include <joost-reply>
>>>>> using namespace std;
>>>
>>> That'd be C++.
>>
>> Yep, very good. :-)
>>
>> Could put:
>>
>> source joost-reply.sh
>>
>> to make it bash, too. :-)
>
> Yeah, or:
> @INC = '/path/to/something';
(load "joost-reply")
if you want lisp. and
from joost-reply import *
or (depending on how exactly you want to import it)
import joost-reply
for python. and
[joost-reply].
should do for prolog.
> To make it Prul.
perhaps for those not fortunate enough to speak dutch, you should add that
'prul' means something like 'a piece of rubbish'. ;-)
Joost Kremers
> Ident/auth, used on many IRC, FTP and mail servers. Some will let you
> connect (if it fails) anyways however most will try 3 times before doing
> so, and thus initial connecting will be slower. This may fix:
>
> ${IPTABLES} -A INPUT -i ${EXT_IF} -d ${EXT_IP} -p tcp \
> --dp 113 -j REJECT --reject-with tcp-reset
another question about this: IIUC this basically means that auth requests
always receive a REJECT reply. what would actually be the harm in allowing
these requests? (i.e., setting -j ACCEPT?)
Menno Duursma
> Menno Duursma wrote:
>> ${IPTABLES} -A INPUT -i ${EXT_IF} -d ${EXT_IP} -p tcp \
>> --dp 113 -j REJECT --reject-with tcp-reset
>
> another question about this: IIUC this basically means that auth requests
> always receive a REJECT reply.
Yes. The reply being a TCP packet with the ACK/RST flags set.
> what would actually be the harm in allowing these requests?
Not much harm, unless you have a identd running (bond to the out-side
IP/interface) and don't want some people to have access to it. However you
could redirect it to some other closed port in that case as well.
> (i.e., setting -j ACCEPT?)
Read above.
HTH.
--
-Menno.
Transmute
> Menno Duursma wrote:
>> Being a DHCP client. You will need to allow `ping' comming in from the
>> server. As well as UDP packets from port 67 directed at your port 68.
>
> mmm... i don't seem to have any problems with this. are you sure it's
> necessary, or could it perhaps be covered by the conntrack modules?
No problems here either.
>> Ident/auth, used on many IRC, FTP and mail servers. Some will let you
>
> well, i don't use IRC, nor a mail server. (mail is sent to a smart host and
> received through IMAP.) i do notice slow log-ins for FTP at times, though...
>
> thanks for the tips!
I was aware of the issue with irc servers, I have to wait 30 seconds
instead of an instant connection, typically. My mail goes out via a
smart host too, but is sent directly to me via MX. No relaying is
allowed, except for me, and I try to keep this 'under surveillance' to
make sure I'm not being used as a 'spam station'.
I haven't tried FTP since I applied my script.
Regards,
Pete.
Transmute
Thanks Chud. Exactly what I was after. I was looking at 'Building
Internet Firewalls' (2nd edition ?), but this looks better as it is
just to do with Linux firewalls. I'll check amazon.co.uk tomorrow.
Thanks again.
Regards,
Pete.
chud
> On Thu, 20 Nov 2003 20:40:13 +0000, Joost Kremers wrote:
>
>> Menno Duursma wrote:
>>> Being a DHCP client. You will need to allow `ping' comming in from the
>>> server. As well as UDP packets from port 67 directed at your port 68.
>>
>> mmm... i don't seem to have any problems with this.
>
> In that case you connect via an ISP who do proper house-keep'n of
> leases they have open (and of which the IP range is broad enough - for
> all the clients they provide access for).
>
> However, RFC 2131 paragraph 3.1 states:
> "When allocating a new address, servers SHOULD check that the offered
> network address is not already in use; e.g., the server may probe the
> offered address with an ICMP Echo Request."
>
> And i know from working at an ISP (if there short on leases) they might
> just ping a client, and give out the adress to a newley connecting
> machine upon getting no response, from it...
>
Interesting point. I drop all incoming ping requests on my firewall, and
rarely get disconnected from my ISP. But then they may not ping their DHCP
clients for the reason you stated above.
I guess you could try dropping all ICMP ping requests, and if you get
disconnected by your ISP too often, just open the firewall to incoming
ping requests. Or, better yet, open it only to incoming pings from your
ISP's address(s).