Tillbaka till svenska Fidonet
English   Information   Debug  
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   9299/22090
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   924
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4786
OSDEBATE   0/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1121
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   3205
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13258
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2056
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4288
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   32677
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2053
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33888
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24094
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4393
FN_SYSOP   41678
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13598
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16069
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
Möte LINUX, 22090 texter
 lista första sista föregående nästa
Text 7704, 271 rader
Skriven 2006-10-26 09:32:00 av MARTIN ATKINS (1:123/140)
     Kommentar till en text av PAUL ROGERS
Ärende: Latest firewall script
==============================
-=> PAUL ROGERS wrote to MARTIN ATKINS <=-

 MA> If the statefull side of your table is working then it might be better
 MA> to leave it alone. After all it's not ugly.

 PR> I thought you said it was.

No. I said it was ok if those addresses connect you to the outside
world. 

 PR>>   LOOPBACK="127.0.0.0/8"
 MA> Yea but it adds to the complexity of the script. No offense meant
 MA> but KISS allows you to quickly read a table and identify any anomalies.

 PR> What's hard about a CIDR like that?  "127.anything", that's simple.

It's not needed. The way i suggested does away with three lines of 
script and why open up more addresses than you need?

 PR> KISS isn't an issue.  Security is.  The way I try to make it
 PR> "easy" to identify anomalies is by using lots of obvious
 PR> patterns.

 MA> Your knowledge of networking far exceeds mine so be forgiving if

 PR> I don't ever give that a thought, because the attackers out there
 PR> far exceed me!  If I ever thought "I finally got it," I'd be
 PR> exposing myself to the next trick.

Fair enough. Complacancy can bite you on the bum. :-}

 MA> i seem nieve but:-
 MA> iptables -A INPUT  -p tcp --sport $EPHEM --dport $EPHEM -m state
 MA> --state ESTABLISHED,RELATED -j ACCEPT
 MA> iptables -A OUTPUT -p tcp --sport $EPHEM --dport $EPHEM -m state
 MA> --state ESTABLISHED,RELATED -j ACCEPT

 MA> Here you are accepting $EPHEM (1024:65535) under established rules so
 MA> these two definitions are not neccasary. Unless of course traceroute
 MA> doesn't comply with the above rules.

 PR> It doesn't allow a NEW connection, so I couldn't start a
 PR> traceroute.  I wouldn't even consider allowing a NEW connection
 PR> from any port to any port.  Sayonara, security!

Ok. I will have to study traceroute one day.

 PR> These rules are required by FTP.  It's unfortunate, but FTP
 PR> doesn't play well with firewalls.  Seems strange the TCP/IP
 PR> protocols designed for the ARPANET didn't have better security,
 PR> but we'll have to wait for the changeover to IPv6, I guess.

 PR>>   TR_SRC_PORTS="32769:65535"
 PR>>   TR_DEST_PORTS="33434:33523"
 MA> You will need try and explian if you will why traceroute needs it's

 PR> That was from the original source.  It was something that didn't
 PR> seem to be broke, so I left it.

Why not just comment them out and see if traceroute still works the way 
you want?

 MA> own rules. Also notice that if the output policy was ACCEPT then
 MA> the second line of the tcp rule is redundant.

 PR> We've got different goals.  I'm not trying to minimize the number
 PR> of rules.  Rather than fewer broad rules, I want narrow rules, as
 PR> many as I need.

I don't think we have different goals, just different attitudes. I'm
driven to perfection even if i can never achieve it.

 PR> I see firewalls that aren't concerned with what goes out.  But
 PR> that not only lets a malicious webpage set something up, but it
 PR> lets anything that did infect my workstation to attack any port
 PR> on any other computer on my LAN.  

If you didn't stop something malicious coming in then you won't stop 
it going out.

 PR> Lots of web sites use ports 81
 PR> or 8080 for certain benign services, but I can't be sure WHAT
 PR> might be going on with some side-channel like that, so I
 PR> explicitly drop those.  Maybe something benign won't work.  I
 PR> accept that.  But at the top of my script I warn it's "tight".
 PR> If you don't want a tight firewall, it isn't for you.

Ok fine. If those two ports make you nervious then IMO there is 
nothing wrong with you writing a rule for them, but why use the
OUTPUT table? I note you are loging those ports for any activity
with:-

iptables -A OUTPUT -p tcp --dport 81 -j log-it
iptables -A OUTPUT -p tcp --dport 8080 -j log-it

This does exactly the same.

iptables -A INPUT -p tcp --dport 81 -j log-it
iptables -A INPUT -p tcp --dport 8080 -j log-it
 
It may not matter to you but to me it does because throughout the
script, by dealing with things at the front door, i may be able to
do away with superfluous rules. 

 PR>>   LOCAL_NET=$BASEIP.0/24
 MA>> This doesn't make sense to me. $BASEIP has not been defined in this
 MA>> script nor has $network_devices/ifconfig.eth0$network_devices
 MA>> /ifconfig.eth0
 PR> It is on my LFS systems.  It's there as part of my installation
 MA> Hmm I don't "think" it belongs in the firewall script. I'm at a

 PR> What belongs?  You think I should define LOCAL_NET in
 PR> ifconfig.eth0?  I suppose one could do it that way.  I think
 PR> just the network root, the first 3 octets, is more versatile.

Are we talking $IP or LOCAL_NET?

IP="192.168.0.1" # Or what's appropriate.

LOCAL_NET="192.168.0.0/16" # Ditto.

Actually you have it defined in your script as $CLASS_C and have
it commented out in one of the rules.
  
# Refuse packets claiming to be from a Class C private network.
# iptables -A INPUT -s $CLASS_C -j DROP
# PGR Can't do that, our LAN is a Class C private network 

It was never gonna work. :) I think though you where on the right 
track. Does your local net and the inet hook up to your machine
through one etho? We may be able to do something with this. 

 MA> disadvantage here as LFS is forign to me. Normaly these things
 MA> are done in /etc/rc.d/init.d or /etc/xinetd.d but even if i'm
 MA> wrong it looks to me an ugly iplimtation of what you are trying to
 MA> achieve.

 PR> init.d/firewall saves & restores--init isn't the place to have
 PR> any glitches.  I put the script posted here in
 PR> /usr/local/sbin/firewall.

Yea well i like my firewall to come up on boot.

 MA> Nooo it's the wrong way of doing it and it is not just my opinion.
 MA> I subscribe to the netfilter list and time and time again those with
 MA> greater knowledge than i (just about everyone) say that filtering
 MA> on the output policy is seldom if ever needed.

 PR> They may not consider it necessary, I do.  The motto of LFS is:
 PR> "Your distro, your rules."  Obviously I think output filtering
 PR> IS necessary.  

Obviously i don't think output filtering IS necessary. :-}

 PR> I've got an OUTPUT rule for virtually every INPUT
 PR> rule.  And it's not causing me problems.

Yes it is. And here is an example from your script:-

#   Input packets are logged & forgotten

iptables -A INPUT -s $BAD_BOY -j log-it

#   Output packets from internal processes receive an error code,
#   but they still don't go through.

iptables -A OUTPUT -d $BAD_BOY -j REJECT --reject-with icmp-host-unreachable

What you appear to be trying achieve is to block known bad IP's from
your system be it local or the internet. If so then it is not doing
what you think it is doing. In fact worse still $BAD_BOY is logged but
still gets into your system. What it actually does is block you and
anything going through your firewall (local net) from communicating
with $BAD_BOY. What you will and your terminals will get is
icmp-host-unreachable. Now this may be desirable but not what i 
think you where after.

#   Input packets are logged 

iptables -A INPUT -s $BAD_BOY -j log-it

# We've seen you sonofabitch now die.

iptables -A INPUT -s $BAD_BOY -j REJECT --reject-with icmp-host-unreachable

 MA> By filtering on the input policy (DROP) you are affectivly dealing
 MA> with situations before they hit the rest of the chain. This saves

 PR> Not necessarily.  People can get tricked into inviting malware
 PR> in.  The packets they come in on can pass filtering.  They may
 PR> come in by other means.  Just filtering the INPUT chain isn't
 PR> enough, IMO.  

Yes it is. If it doesn't get past the input chain it is dead in the 
water.

 PR> I filter the OUTPUT chain so that it doesn't get
 PR> in MY way, but gets in the way of everything else.

What kind of attutude is that? Suppose you where SNAT/DNATing or
FORWARDING. You let the damn thing in the front door. It could go
anywere.

 MA> Yes but do you think anyone can make an informed comment on you script
 MA> when they have to deal with externel definitions on your machine?

 PR> It isn't clear what $IP means?  Would $MY_IP_ADDR be better?
 PR> That means changing several other scripts, but I'll consider
 PR> it.  Maybe a comment here will help.

If $IP was defined in the script it would be self explanatory.

 MA> Your IP address is the etho card (or what ever) that links your machine
 MA> to the network. It is not the loopback address.

 PR> Hello?  You may not have run into it yet, but I had packets
 PR> being dropped because I also thought only 127.0.0.0/8 addresses
 PR> ever used the loopback interface.  Packets addressed with the IP
 PR> address will also appear on the loopback!  (I didn't make it a
 PR> point to remember which service did it after I found it and
 PR> fixed it.)

I would be highly suspicious of anything attempting to use something
outside 127.0.0.1 for loopback or local machine. It runs counter
to your philosophy of running a tight firewall. 

 MA> Ah yes. The old "if it ain't broke don't fix it" philosophy. I

 PR> Yeah, it's sorta like the KISS philosophy.  ;-)

 MA> well crafted script is a pleasure when achieved and a wonder for others

 PR> It's got to please me.  This is open-source--others can change
 PR> it to satisfy themselves, and will.

 MA> iptables -L -v
 MA> This is an after thought from my last message. If run from a terminal
 MA> it will give you a better output.

 PR> Not unless there is a network connection at the time.  If not
 PR> then -L hangs until it times out, and it still only reports the
 PR> numeric addresses.  -L -n doesn't delay.  I only have a network
 PR> connection when I need to use it.  It goes through another
 PR> computer that isn't always on.

Huh? If "iptables -L -v" hangs then so would "iptables -L -n" and
it doesn't only report numerical output it does as the -v option
suggests and reports verbose. The -n option is as it suggests 
numerical.

iptables -L -v

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in   out source    destination         
0     0 ACCEPT    all  --  lo   any anywhere  anywhere            
0     0 ACCEPT    all  --  eth0 any anywhere  anywhere            
0     0 ACCEPT    tcp  --  eth1 any anywhere  anywhere tcp dpts:32768:61000 
0     0 ACCEPT    udp  --  eth1 any anywhere  anywhere udp dpts:32768:61000 
0     0 ACCEPT    icmp --  eth1 any anywhere  anywhere icmp echo-request 
0     0 ACCEPT    icmp --  eth1 any anywhere  anywhere icmp echo-reply limit: 
avg 2/min burst 5 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in   out   source  destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in   out   source  destination         

 
--- MultiMail/Linux v0.47
 * Origin: Try Our Web Based QWK: DOCSPLACE.ORG (1:123/140)