A Fast Dike































Fastwall: A Shorewall within 2 Minutes


Fastwall :
Recently i created a dynamic firewall script based on rudd-o's "Hardening a Linux Server in 10 Minutes" (See below) and how shorewall stores its firewall settings.

Scenario :
The philosophy is like this. I have this Linux server hooked up somehow onto the Internet on some LOCAL LAN. The DSL router is doing the routing and port-forwarding to my machine, but somehow fine-tuning the DSL router's filtering rules is a mess. I just need to have my web-server, email and DNS accessible from the Internet. The rest of my network applications should only be accessible on the LOCAL LAN. So i wrote a script just doing that. I called it fastwall, see the downloads below.

Dynamic approach :
Fastwall computes from the shorewall rules and 'netstat -ltunp' the TCP and UDP ports which need to be closed on the NETWORKS which aren't local. This may seem like a hack, but it sure makes life easier with getting some complicated application working. It's in particular handy if your Linux PC is NOT the router but only doing the fire-walling.

Mode of operation :
Figure out which udp and tcp ports need to be opened for public Internet use, like HTTP port 80 or SMTP port 25. Make sure these udp and tcp ports are listed inside /etc/shorewall/rules.drakx .. :
example :


[mx1:root]:(~)# cat /etc/shorewall/rules.drakx
ACCEPT  net     fw      udp     53,110,1194     -
ACCEPT  net     fw      tcp     80,443,53,22,20,21,25,109,110,143,110   -
[mail:root]:(~)# 

Make sure that inside fastwall-on.sh (or fastwall) the values for IPTABLES, RULES and LOCALNET are adjusted to your own network setup, and ..

Check fastwall from the Internet :
Next run fastwall-on.sh (or fastwall as a chkconfig service) after which you check from the Internet with nmap if the desired result is obtained :


[mx2:root]:(~)# nmap -v -sT -O mx1.foobar.org

Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2008-07-16 20:25 CEST
Host xdsl-64-238-254-71.dslprovider.net (64.238.254.71) appears to be up ... good.
Initiating Connect() Scan against xdsl-64-238-254-71.dslprovider.net (64.238.254.71) a
t 20:25
Adding open port 110/tcp
Adding open port 8080/tcp
Adding open port 443/tcp
Adding open port 53/tcp
Adding open port 21/tcp
Adding open port 22/tcp
Adding open port 80/tcp
Adding open port 25/tcp
The Connect() Scan took 7 seconds to scan 1660 ports.
For OSScan assuming that port 21 is open and port 1 is closed and neither are fi
rewalled
For OSScan assuming that port 21 is open and port 1 is closed and neither are fi
rewalled
For OSScan assuming that port 21 is open and port 1 is closed and neither are fi
rewalled
Interesting ports on xdsl-64-238-254-71.dslprovider.net (64.238.254.71):
(The 1651 ports scanned but not shown below are in state: closed)
PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   open     smtp
53/tcp   open     domain
80/tcp   open     http
110/tcp  open     pop3
443/tcp  open     https
1720/tcp filtered H.323/Q.931
8080/tcp open     http-proxy
No exact OS matches for host (If you know what OS is running on it, see http://w
ww.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.55%P=x86_64-mandrake-linux-gnu%D=7/16%Time=487E3D38%O=21%C=1)
TSeq(Class=TR%IPID=Z%TS=1000HZ)
T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)


Uptime 3.235 days (since Sun Jul 13 14:47:21 2008)
TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
IPID Sequence Generation: All zeros

Nmap run completed -- 1 IP address (1 host up) scanned in 24.146 seconds
[mx2:root]:(~)# 

All i needed was to fill-out my outward accessible UDP and TCP ports inside /etc/shorewall/rules.drakx, and even my openvpn tunnel was working out of the box. A thing which shorewall and many other firewall scripts simply cannot do, and certainly not within 2 minutes.

Pitfall :
If you add new network applications on your Linux machine, you always need to rerun fastwall, but that's the case with any dynamic fire-walling appliance.

The R Zone

The R Zone: Hardening a Linux Server in 10 Minutes


Wed Mar  1 16:14:18 CET 2006
(as copied from :
http://rudd-o.com/archives/2006/02/27/hardening-a-linux-server-in-10-minutes/ )

Did you know that a freshly installed Linux server can be hardened in 
less than 10 minutes? Heres how!

Print these instructions out, and keep them posted on a wall in your 
office or home. Before plugging a freshly installed network server, 
simply remember to follow these instructions. Make these instructions 
second nature to you.

Youll need a bit of experience with the Linux command-line environment, 
as the following commands are usually issued in a terminal. You will 
need root access on your server as well. By the way, the following 
instructions apply to any LSB-compliant Linux distribution, but Ill use 
Fedora Core as an example.



Step 1: turn all unneeded services off


There are two kinds of network services:

those that get started as init.d services
those that get started by xinetd

This distinction is important, as xinetd can start services on demand, 
while services started through init.d run all the time.


Okay, time to start securing your server. On a terminal, as root (and, 
for the purposes of this tutorial, assume this from now on) run netstat 
-ltunp. You should see a listing like this one:


[root@andrea rudd-o]# netstat -ltunp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:3493                0.0.0.0:*                   LISTEN      30562/upsd
tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN      12461/mysqld
tcp        0      0 0.0.0.0:6543                0.0.0.0:*                   LISTEN      12490/mythbackend
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      1771/portmap
tcp        0      0 0.0.0.0:6544                0.0.0.0:*                   LISTEN      12490/mythbackend
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      31537/cupsd
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      2143/sendmail: acce
tcp        0      0 :::80                       :::*                        LISTEN      5024/httpd
tcp        0      0 :::22                       :::*                        LISTEN      2009/sshd
tcp        0      0 0.0.0.0:19                  0.0.0.0:*                   LISTEN      2019/xinetd


Those are all processes listening to specific ports. As you can see, 
the PID (process ID) and the program name are displayed as well.

Make two lists: - one for the services you absolutely need (which you 
should already know by heart), and - one for the services that are 
expendable or you can start manually when theyre needed (tip: each 
program name usually ships with a man page).

Shutdown each service on the second list (except for xinetd) Thats a 
pretty straightforward task. Each one of those services are started by 
init.d. To find out the name of the service control script, just hop to 
/etc/rc.d/init.d and look for a file with a name similar to the program 
name.

Example: suppose I dont need mythbackend. To stop it: 
/etc/rc.d/init.d/mythbackend stop (some distributions provide the 
service mythbackend stop command, which is easier on your fingers). 
Now, to disable it: chkconfig --del mythbackend. After doing this, you 
should check to see if the offending service went away, with the same 
netstat -ltunp command.

That pesky xinetd

Great. So you got rid of the unneeded services. But theres more. As we 
saw earlier, xinetd has its own ways. In practice, this means that some 
services will be started on demand  thus, you wont see them under your 
netstat -ltunp listing.

To find out which services xinetd manages, hop to /etc/xinetd.d and do 
a directory listing. You should see some service configuration files. 
Identify the ones you wont be using, and edit each one of them, adding 
a line that says disable = yes between the curly braces.

Note that some services already ship with disable = yes, but some ship 
with disable = no. If one of the configuration files says disable = no, 
just change it to disable = yes. Now reload xinetd with the famous 
/etc/rc.d/init.d/xinetd reload, and run netstat -ltunp again, just to 
be sure.

Thats step 1. With a bit of practice, you should be doing this in five 
minutes or less.



Step 2: limit access to running services using iptables


Great, our server now runs the absolutely required services, and no 
more. But some of those services arent meant to be accessed from 
everywhere, right? For example: I may have a MySQL database server 
running, but that doesnt mean MySQL should be accessible from any 
random IP address on the Internet, right?

So, well use the firewall to stop evil at the door. Again, make a list 
of services. For each item on the list, identify which IP addresses 
should be able to reach the service. For each service on your list, 
write down the TCP/UDP port(s) they use.

In my example, MySQL uses TCP port 3306, and should only be accessible 
by localhost (127.0.0.1).

Time to compose and activate the iptables rules. Doing a quick check 
with iptables -L, I can see that my INPUT chain (the one Ill be working 
with, since I want to disallow INPUTs to my server) is empty:


[root@andrea xinetd.d]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination


Your mileage may vary, because your distribution may already have set 
up some basic iptables rules; to make these instructions foolproof, I 
will be inserting rules at the beginning of the INPUT chain.

In this case, I want to allow access to 127.0.0.1:3306, and deny access 
to everyone else on port 3306, in that order. So two rules are needed. 
Ill add the allow rule into position 1 (the very first):


[root@andrea xinetd.d]# iptables -I INPUT 1 --protocol tcp --destination-port 3306 -s 127.0.0.1 -j ACCEPT
[root@andrea xinetd.d]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  localhost.localdomain  anywhere            tcp dpt:mysql


Great. Im telling the firewall to -j ACCEPT all --protocol tcp 
connections to --destination-port 3306 from the address -s 127.0.0.1. 
Now, Ill insert the deny rule into position 2:


[root@andrea xinetd.d]# iptables -I INPUT 2 --protocol tcp --destination-port 3306 -j REJECT
[root@andrea xinetd.d]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  localhost.localdomain  anywhere            tcp dpt:mysql
REJECT     tcp  --  anywhere             anywhere            tcp dpt:mysql reject-with icmp-port-unreachable


See how easy it is? Let me explain: rule 2 tells the firewall to -j 
REJECT all --protocol tcp connections to --destination-port 3306 from 
any address (since I omitted the address). Since rules are processed 
top-down (from 1 to n), the first one that matches an incoming 
connection is applied. If no rules match, then the default policy 
(which is normally ACCEPT) kicks in.

Lather. Rinse. Repeat for every service that you want to secure.

Finally, save the rules. For this, youll need to use your distributions 
tools. For Fedora Core, thats as easy as issuing the command service 
iptables save and ensuring that the iptables service runs at boot time: 
chkconfig --add iptables.

Its worth noting that some people prefer to -j DROP instead of DENYing. 
DROP means that your server will ignore connection attempts (neither 
denying connections nor accepting them). I prefer DENY, because its 
easier to pinpoint a problem with iptables rules that way, and (most 
importantly) DROP rules make those ports appear as filtered to a 
hostile port scanner (which hints to the attacker that a service is 
running).

So thats it, from insecure to secure in 10 minutes! If you have any 
suggestions or questions, please leave them as comments below. Happy 
hacking!

 If you found this useful, please leave a donation for the author. 

This entry was posted on Monday, February 27th, 2006 at 18:55 and is 
filed under Publicaciones, Software libre, Linux. You can follow any 
responses to this entry through the RSS 2.0 feed. You can leave a 
response, or trackback from your own site. You can also share and 
bookmark this article on the following services:          . 

 Except where expressly acknowledged, this work is distributed and 
licensed to you under the terms of this license. For other licenses, 
contact Rudd-O.

No Responses to Hardening a Linux server in 10 minutes

You can subscribe to the RSS feed for comments on this post. You can 
also reply to this post directly in your weblog, and take advantage of 
the TrackBack URI to record your reply in this post.

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, 

references :

total 140
-rwxr-xr-x    1 root     root         6414 Jul 16 01:04 fastwall
-rwxr-xr-x    1 root     root         1006 Jul 15 16:57 fastwall-off.sh
-rwxr-xr-x    1 root     root         2674 Jul 15 17:00 fastwall-on.sh
-rw-r--r--    1 root     root          475 Jul 16 01:04 MD5SUM