• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Redhat 7.2 running a firewall with all services turned on. What type of attacks should I be wary of?

S

sandmanwake

Golden Member
For the final phase of a network security class, we're going to turn on all the services that could possibly run on Redhat 7.2 and run a firewall. What type of vulnerabilities and attacks should I expect from this type of setup?
 
No matter the precautions taken, short of disconnecting a computer from the outside world, if someone wants to get into your system...they will, given enough time. While the *nix derivatives are more secure than some other systems, they too have faults and vulnerabilities (OpenBSD excluded n0c!)
 
if someone wants to get into your system...they will, given enough time

Yes, but what is the most likely points of attack with this type of set up? Hum, I suppose it would also depend on the type of firewall used. Doesn't Redhat come with a built in firewall? We're probably going to use that one then.

Let's see, I can already see the possibility of someone using a backdoor they put in previously. Someone turning off the firewall and hoping no one notices. Is plain text still vulnerable to packet sniffing with a firewall running? Anyone have any other suggestions?
 
Yes, plaintext is still vulnerable assuming they can get to a point on your network where they can sniff it.

I belive redhat 7.2 comes with exploitable versions of WuFTP, and OpenSSH.
The WuFTP exploit requres a valid login on the system, but I'm pretty sure they defaultly leavea 'anonymous' on, and therefore anyone can log in that way and run the exploit.

at the command line type "netstat -a" and look to see what "internet connections" are in the "LISTENING" state. Those are what you'll get hacked through (if an exploit exists for them) so figure out what piece of software is doing the 'LISTEN'ing and check around to see if it is up to date and secure.

bart
 
For the final phase of a network security class, we're going to turn on all the services that could possibly run on Redhat 7.2 and run a firewall. What type of vulnerabilities and attacks should I expect from this type of setup?

You have to be aware of every service's problem (i.e. FTP plaintext passwords, wu-ftpd exploits,etc) because if they can reach it, it'll be the easiest way in.

Instead of using the built in firewall, you could try the free PMFirewall from pointman

PMFirewall is just a configtool for the real firewalling in the 2.2 kernel, ipchains, which was superceded by iptables in the 2.4.x kernels anyway.
 


<< (OpenBSD excluded n0c!) >>



No its not.

rpc is a big one, but I dont see a lot of 515 out there. Port 80 is big right now, but less of a deal on Linux. wu-ftp is stupid. Watch that one like a hawk. Most of the OpenSSH vulnerabilities are local exploits, so that shouldnt be a concern for the admin unless you have an account.
 
TCP 111 and TCP 515 usually come from outside the US. TCP 515 is related to a Sun vulnerability that may exist in other Unix flavors. I see more TCP 111 probes. I didn't mention TCP port 80 since I thought it was mainly a windows based problem.
 
Well, all services except telnet have been activated. The ipchain for the firewall is configured to drop all UDP traffic and allow only incoming TCP ssh connections. Any other type of communication has to be initiated by the localhost first. 🙂
 
As a unix sysadmin, who's done research on IDS, I'll toss in a few points:

For your purpose, what you've done looks acceptable (drop all incoming udp, all incoming tcp except ssh), you might also want to drop all incoming icmp packets (its mostly a DoS countermeasure, it hides the box a little, too)

If you were REALLY going to do this, you can't just block all incoming traffic, so in real life you'd want to do something
like this:

The basic firewall rule will be to allow incoming connections with valid syn flags to ports you know are in use and should accept outside connections, and allow packets part of any of these already established connections, dropping anything else. This keeps random malformed packets from hitting your services, which is how a large percentage of exploits work.

If they're going to make you turn on "all services", NFS will probably be included, so RPC is a valid concern. First, make sure you enable TCP Wrappers (/etc/hosts.allow, /etc/hosts.deny), and deny it to almost everyone.

Second, if you have to run a webserver, run a very simple one (apache, no mod_perl, no mod_php, just apache). It should install itself as the user "www", "nobody", or "wwwserv", as a precaution, but make sure that that user can NOT log in normally.

Third, they'll make you run sendmail. Fine. Download the latest source, compile from scratch, and read up on how to shut off everything and everything you'll never use, like uucp. Then block access to it from everyone except the firewall (tcp wrappers again), and make sure you only allow valid syn packets and established connections to go to it from the firewall.

Fourth, FTPD. Redhat comes with wu-ftpd. Delete it. Period. It's more complex than you'll ever need, unless you really care about having members of group a allowed to anonymously download from one directory, while members of group b only have access to their home directory, blah blah blah. It's too much. Look into either one of the BSD ftpd's or something like ProFTPD. Again, tcp wrappers and firewall.

SSH / Telnet. If they MAKE you install and allow telnet ... that's dumb. Nobody except college students uses it in real life. I suppose you should just make sure it's current (there was a big bsd telnet hole a while back, I'm not sure if it affected linux), and secure it like above. SSH has had a series of holes recently, so you'll want to download the new RPM for that and install (again, tcp wrappers everywhere, and set the firewall rather restrictively). (Contrary to n0c's opinion, there was at least one REMOTE ROOT security hole in OpenSSH in the last year or so... you really do need to update it before putting the box live).

Things like MySQL (and apache, telnet, if you can get away with it) : always try to make them bind to only the local interface (lo0 on bsd, I think it's lo0 on linux as well). Then block them completely at the firewall, nobody will need it except the local machine.


You seem to be in good shape for your assignment, but in real life, you'll have to open things up a bit more
 
Wow, thanks kellygirlbeads. I'm saving your reply for future reference. By the way, to the blonde babe on your website: "How ya doing?"😉
 
#!/bin/sh
echo "Initializing modules..."
cd /lib/modules/2.4.1/kernel/net/ipv4/netfilter
insmod ip_tables
insmod ip_conntrack
insmod ipt_state
insmod ipt_limit
#insmod iptable_mangle
#insmod ipt_PERS
echo "Flushing rules.."
#iptables -F PREROUTING
#iptables -t mangle -F OUTPUT
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
if [ "$1" == "start" ]; then
echo "Setting up spoof protection..."
for blah in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo "1" > $blah
done
echo "Setting default routes..."
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
echo "Configuring external interface rulesets..."
#iptables -t mangle -A PREROUTING -j PERS --local --tweak dst --conf /etc/win9x.conf
#iptables -t mangle -A OUTPUT -j PERS --local --tweak src --conf /etc/win9x.conf
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 255.255.255.255/32 -j DROP
iptables -A INPUT -i eth0 -s 0.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 169.254.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 192.0.2.0/24 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 224.0.0.0/4 -j DROP
iptables -A INPUT -i eth0 -s 240.0.0.0/5 -j DROP
iptables -A INPUT -i eth0 -s 248.0.0.0/5 -j DROP
iptables -A INPUT -i eth0 -f -j DROP
iptables -A INPUT -i eth0 -p TCP -m state --state INVALID -j DROP
iptables -A INPUT -i eth0 -p TCP --syn -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 20 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 23 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 113 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 1024:5000 --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP -s 0/0 --sport 1024:5000 -d 0/0 --dport 1998 -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP -s 0/0 --sport 1024:5000 -d 0/0 --dport 1999 -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --dport 32768:61000 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 20 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 23 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 113 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 1998 -j ACCEPT
#iptables -A INPUT -i eth0 -p TCP --sport 32768:61000 --dport 1999 -j ACCEPT
#iptables -A INPUT -i eth0 -p UDP -j DENY
iptables -A INPUT -i eth0 -p UDP -s 0/0 --sport 53 -j ACCEPT
#iptables -A INPUT -i eth0 -p UDP -s 0/0 --dport 53 -j ACCEPT
#iptables -A INPUT -i eth0 -p UDP -s 0/0 --sport 161 -j ACCEPT
iptables -A INPUT -i eth0 -p UDP -s 0/0 --sport ntp -j ACCEPT
iptables -A INPUT -i eth0 -p UDP -s 0/0 --dport ntp -j ACCEPT
iptables -A INPUT -i eth0 -p ICMP --icmp-type echo-reply -j ACCEPT
echo "Configuring routing rulesets..."
iptables -A FORWARD -i eth0 -d 205.188.153.139/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.153.140/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.153.141/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.168/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.164/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.178/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.172/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.7.176/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.5.208/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.4.159/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.3.160/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.3.176/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.5.204/32 -j DROP
iptables -A FORWARD -i eth0 -d 205.188.153.139/32 -j DROP
iptables -A FORWARD -i eth0 -d 209.185.128.132/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.241.128/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.242.24/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.242.28/32 -j DROP
iptables -A FORWARD -i eth0 -d 152.163.241.120/32 -j DROP
iptables -A FORWARD -i eth0 -p TCP --sport 1024: --dport 9898 -j DROP
iptables -A FORWARD -i eth0 -d 10.0.0.0/8 -j DROP
iptables -A FORWARD -i eth0 -d 127.0.0.0/8 -j DROP
iptables -A FORWARD -i eth0 -p igmp -j DROP
iptables -A FORWARD -i eth0 -p TCP --syn -m limit --limit 10/s -j ACCEPT
iptables -A FORWARD -i eth0 -p TCP --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 10/s -j ACCEPT
echo "Configuring internal interface rulesets..."
iptables -A INPUT -i lo -j ACCEPT
echo "IPtables firewall configuration completed."
fi

try this (shamefully ripped from an iptables howto i found somewhere. notice the rate limiting features of iptables are used fairly extensively and ensuring valid established communications arent disrupted. this by default of course, denies all packets, then it makes specific exceptions for the services u want to run. i run this on my ip nat box and ive had little problems.
 
make sure to adapt those scripts to the redhat environment.

scan yourself with nessus just to make sure you didnt forget something trivial.

my home network is with roadrunner, so i get loads of smb fileshare scans, port 80 scans (looking for iis boxes), and a fair amount of scan for the usual trojans (31337, 12345).

a good little security program i used to use was called portsentry, it uses tripwired ports on the range of generally scanned ports (21,53, 80, trojan ports, etc), but can be adapted to any ports youd like. it will detect port scans unto those ports, and either add them to a tcp wrappers script, pam, or hosts.deny (im not sure of all its features, i used the last one for over 6 months). you can set thresholds you will allow.

and if youre gonna run redhat, try bastille linux (i dont know if its available for your version).

and did i mention, keep your self with the latest updates from redhat?
 
[offtopic]
kelly, i looked at those beads on your site. those are realy nice.

so when youre not sysadminning, you manufacture and sell beads? damn youre multitalented.
[/offtopic]
 


<< (Contrary to n0c's opinion, there was at least one REMOTE ROOT security hole in OpenSSH in the last year or so... . . .) >>



Everything I can find points to local root holes, no remote root holes.

I checked openbsd.org and security focus. Im still going through the security focus site though. If you have any proof that there was a remote root hole in the default installation of openssh, please either post a link or pm me a link. I dont think I have seen an exploit like that and would love to take a look at it.

Four years without a remote hole in the default install! (which includes OpenSSH 😉)
 
I guess you're right.

Not default, but definitely a security risk anyway (also requires valid user, which *IS* still a valid security risk - never trust your users!)

- 2002-12-02



<<

III. Impact

Hostile but otherwise legitimate users that can successfully
authenticate using public key authentication may cause /usr/bin/login
to run arbitrary code as the superuser.

If you have not enabled the 'UseLogin' directive in the sshd
configuration file, you are not vulnerable to this problem.

 >>



Another OpenSSH Hole ... (It's worth noting that this bug was patched by the OpenBSD team, but the bug itself could have affected freebsd and linux users - once again, requires a valid user account to log in)

- 2002-03-07:



<< III. Impact


An authorized remote user (i.e. a user that can successfully
authenticate on the target system) may be able to cause sshd to
execute arbitrary code with superuser privileges.

 >>



( yea, I'm a freebsd admin 😉 I appreciate openbsd, but I still believe that a well administered freebsd box is every bit as secure as an openbsd box )

Again, these would both take a valid account on the machine, but the existence of any hole is still something of a concern. Not much you can do about blocking all access to SSH, though. Just wrap it with tcp wrappers from everywhere you know you'll never need to touch it from, would be my suggestion.
 


<< I guess you're right.

Not default, but definitely a security risk anyway (also requires valid user, which *IS* still a valid security risk - never trust your users!)

- 2002-12-02



<<

III. Impact

Hostile but otherwise legitimate users that can successfully
authenticate using public key authentication may cause /usr/bin/login
to run arbitrary code as the superuser.

If you have not enabled the 'UseLogin' directive in the sshd
configuration file, you are not vulnerable to this problem.

 >>



Another OpenSSH Hole ... (It's worth noting that this bug was patched by the OpenBSD team, but the bug itself could have affected freebsd and linux users - once again, requires a valid user account to log in)

- 2002-03-07:



<< III. Impact


An authorized remote user (i.e. a user that can successfully
authenticate on the target system) may be able to cause sshd to
execute arbitrary code with superuser privileges.

 >>



( yea, I'm a freebsd admin 😉 I appreciate openbsd, but I still believe that a well administered freebsd box is every bit as secure as an openbsd box ) >>



I disagree, but Im biased (OpenBSD user/admin, paranoid freak, lazy) 😉



<< Again, these would both take a valid account on the machine, but the existence of any hole is still something of a concern. Not much you can do about blocking all access to SSH, though. Just wrap it with tcp wrappers from everywhere you know you'll never need to touch it from, would be my suggestion. >>



I agreed that there have been holes (and quick patches, plus OpenSSH is being worked on to prevent all this). And you definitely need to work to keep it from being a problem. Anyhow, nothing is perfect.
 


<< I disagree, but Im biased (OpenBSD user/admin, paranoid freak, lazy) >>




I can understand the bias, but just because you run OpenBSD, that's no excuse to be lazy *shame on you 😛 * . How many non-default services do you run? 😉 Odds are, you NEED more than the default install for anything more than a firewall/router.

I'm in the process of buying new dell servers for mail servers in a 1000 user environment. When those come in, and I install FreeBSD, I'll have to add things like IMAP and APOP - non default, but nearly essential for this situation. If there's a hole in either of these (and there will be, given enough time), laziness will cause problems 🙂

 


<<

<< I disagree, but Im biased (OpenBSD user/admin, paranoid freak, lazy) >>




I can understand the bias, but just because you run OpenBSD, that's no excuse to be lazy *shame on you 😛 * >>



I know mom 😉



<< How many non-default services do you run? 😉 Odds are, you NEED more than the default install for anything more than a firewall/router. >>



I do run non-default services. But only one of them is accessible to the outside world.. I did do atleast some basic reading on securing it, so its not so bad.



<< I'm in the process of buying new dell servers for mail servers in a 1000 user environment. When those come in, and I install FreeBSD, I'll have to add things like IMAP and APOP - non default, but nearly essential for this situation. If there's a hole in either of these (and there will be, given enough time), laziness will cause problems 🙂 >>



My paranoia outweighs my laziness. I keep up with vendor patches. Using the services installed on OpenBSD is much easier though because I can check one place. I use one service (that I can think of off the top of my head (on my home network)) that was not shipped with OpenBSD. And that is qmail. If an exploit is discovered for qmail it will be covered *EVERYWHERE* and I will definitely hear about it 😉
 


<<

<< I know mom >>



😉 I'm probably cuter than your mom 😉 >>



You're also probably 20 years younger than her. (give or take a few years since I dont know how old you are or how old my mom is...)
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top