Slackware Server On The Internet.

Drakeo · 06-15-2014, 06:04 AM

Quote:

Giving users a 'solution' is not a good practice. You're spoon feeding them that is so dangerous, destructive and insecure in the long term as closing the code. I had to work teaching, the typical thing you do when you're a newbie teaching is giving the other 'all' the information. Wrong. Draw an ear, a nose, some hair and let the pupil to complete the face. The other must put some from him, not to be passive.

I have learned so much here through the years. I come here with a linuxquestion to get an answer that I am unable to Google search etc etc .
Not to have some one give answer without saying please modify script for your use. Let me get my chalk board out and write on it.

Sarcasm is not the answer in linux questions. and I did not see this thread under tutorials. I have read your posts before and have gained knowledge that I thank you for. But I come to a thread to solve a problem so please next time you want to school some one be upfront say yo. this is a basic example. Please modify for your server. language is hard enough.

spoon feeding dangerous destructive insecure information. Wrong. that's not typical but that is what the search engine will pick up.
set my chalk down.

kikinovak · 06-15-2014, 09:09 AM

Quote:

Originally Posted by eloi

I understand just reading the rules about the limit. My doubt is if your last rule doesn't override the others. I am not a iptables expert that's why I ask.

Try to SSH into 88.191.189.120, a few times in a row. Then see what happens.

onebuck · 06-15-2014, 09:46 AM

Hi,

I have read this thread with concern for the information presented.

Personally, I do setup a DMZ configuration;

Quote:

In the military sense, a DMZ is not seen as belonging to either party bordering it. This concept applies to the computing use of the metaphor in that a DMZ which is, for example, acting as a gateway to the public Internet, is neither as secure as the internal network, nor as insecure as the public Internet.
In this case, the hosts most vulnerable to attack are those that provide services to users outside of the local area network, such as e-mail, web and Domain Name System (DNS) servers. Because of the increased potential of these hosts suffering an attack, they are placed into this specific sub-network in order to protect the rest of the network if an intruder were to successfully compromise any of them.
Hosts in the DMZ are permitted to have only limited connectivity to specific hosts in the internal network, as the content of DMZ is not as secure as the internal network. Similarly communication between hosts in the DMZ and to the external network is also restricted, to make the DMZ more secure than the Internet, and suitable for housing these special purpose services. This allows hosts in the DMZ to communicate with both the internal and external network, while an intervening firewall controls the traffic between the DMZ servers and the internal network clients, and another firewall would perform some level of control to protect the DMZ from the external network.
A DMZ configuration provides security from external attacks, but it typically has no bearing on internal attacks such as sniffing communication via a packet analyzer or spoofing such as e-mail spoofing.
It is also sometimes good practice to configure separate Classified Militarized Zone (CMZ), a highly monitored militarized zone comprising mostly of web servers (and similar servers that interface to the external world i.e. the internet) that are not in the DMZ but contain sensitive information about accessing servers within LAN (like the database servers). In such architecture, the DMZ usually has the application firewall and the FTP whilst the CMZ hosts the web servers. (The database servers could be in the CMZ or in the LAN or in a separate VLAN altogether.)

I use a Dual firewall setup that is secure when proof tested;

Quote:

https://upload.wikimedia.org/wikiped...rewall.svg.png https://bits.wikimedia.org/static-1....gnify-clip.png
Diagram of a typical network employing DMZ using dual firewalls.

A more secure approach is to use two firewalls to create a DMZ. The first firewall (also called the "front-end" or "perimeter" [1] firewall) must be configured to allow traffic destined to the DMZ only. The second firewall (also called "back-end" or "internal" firewall) only allows traffic from the DMZ to the internal network.
This setup is considered more secure since two devices would need to be compromised. There is even more protection if the two firewalls are provided by two different vendors, because it makes it less likely that both devices suffer from the same security vulnerabilities. For example, accidental misconfiguration is less likely to occur the same way across the configuration interfaces of two different vendors, and a security hole found to exist in one vendor's system is less likely to occur in the other one. The drawback of this architecture is that it's more costly. The practice of using different firewalls from different vendors is sometimes described as a component of a "defense in depth" security strategy.

Science DMZ

Quote:

The term Science DMZ refers to a computer subnetwork that is structured to be secure, but without the performance limits that would otherwise result from passing data through a stateful firewall.[1] The Science DMZ is designed to handle high volume data transfers, typical with scientific and high-performance computing, by creating a special DMZ to accommodate those transfers. It is typically deployed at or near the local network perimeter, and is optimized for a moderate number of high-speed flows, rather than for general-purpose business systems or enterprise computing.[2]
The term Science DMZ was coined by collaborators at the US Department of Energy's ESnet in 2010.[3] A number of universities and laboratories have deployed or are deploying a Science DMZ. In 2012 the National Science Foundation funded the creation or improvement of Science DMZs on several university campuses in the United States.[4][5][6]
The Science DMZ[7] is a network architecture to support Big Data. The so-called information explosion has been discussed since the mid 1960s, and more recently the term data deluge [8] has been used to describe the exponential growth in many types of data sets. These huge data sets, often need to be copied from one location to another using the Internet. The movement of data sets of this magnitude in a reasonable amount of time should be possible on modern networks. For example, it should only take less than 4 hours to transfer 10 TeraBytes of data on a 10-gigabit Ethernet network path, assuming disk performance is adequate[9] The problem is that this requires networks that are free from packet loss and middleboxes such as traffic shapers or firewalls that slow network performance.

Don't take my word but look at Justification;

Quote:

The Science DMZ provides a well-configured location for the networking, systems, and security infrastructure that supports high-performance data movement. In data-intensive science environments, data sets have outgrown portable media, and the default configurations used by many equipment and software vendors are inadequate for high performance applications. The components of the Science DMZ are specifically configured to support high performance applications, and to facilitate the rapid diagnosis of performance problems. Without the deployment of dedicated infrastructure, it is often impossible to achieve acceptable performance. Simply increasing network bandwidth is usually not good enough, as performance problems are caused by many factors, ranging from underpowered firewalls to dirty fiber optics to untuned operating systems.
The Science DMZ is the codification of a set of shared best practices—concepts that have been developed over the years—from the scientific networking and systems community. The Science DMZ model describes the essential components of high-performance data transfer infrastructure in a way that is accessible to non-experts and scalable across any size of institution or experiment.

Most modern routers will provide a firewall that can be customized then you can provide a DMZ via another working firewall that you can personally create or use a distribution specific, Slackware user do use a modified EasyFirewall (mod by Alien_Bob);

Quote:

This program generates an iptables firewall script for use with the 2.4 or later linux kernel. It is intended for use on a single system connected to the Internet or a gateway system for a private, internal network. It provides a range of options, but is not intended to cover every possible situation. Make sure you understand what each option in the generator does and take the time to read the comments in the resulting firewall. This generator will not, for example, generate a firewall suitable for use with a DMZ, but it can provide a starting point. For the most common uses the generator should produce a firewall ready for use.
Read here for more information on iptables firewalls.
Easy Firewall Generator implements several ideas presented in Oskar Andreasson's iptables-tutorial. The link to his tutorial is maintained on the resources page below.
Links to additional firewall resources.

Users can easily modify to suit local needs. Which I do.

Another example: Linux Demilitarized Zone (DMZ) Ethernet Interface Requirements and Configuration

Quote:

Q. Can you tell me more about Linux Demilitarized Zone and Ethernet Interface Card Requirements for typical DMZ implementation? How can a rule be set to route traffic to certain machines on a DMZ for HTTP or SMTP?
A. Demilitarized zone, used to secure an internal network from external access. You can use Linux firewall to create DMZ easily. There are many different ways to design a network with a DMZ. The basic method is to use a single Linux firewall with 3 Ethernet cards. The following simple example discusses DMZ setup and forwarding public traffic to internal servers.

Not really that complicated for someone who will do their research and willing to get their hands dirty.

Hope this helps.
Have fun!

eloi · 06-15-2014, 12:05 PM

Quote:

Originally Posted by kikinovak

Try to SSH into 88.191.189.120, a few times in a row. Then see what happens.

If you tested it yourself I believe you. I marked your original post like useful.

Thanks.

eloi · 06-15-2014, 01:14 PM

Quote:

Originally Posted by onebuck

Personally, I do setup a DMZ configuration

Agree. That's what I'd do in a home server using a firewall in my router.

kikinovak · 06-15-2014, 01:18 PM

Quote:

Originally Posted by eloi

If you tested it yourself I believe you. I marked your original post like useful.

Thanks.

In short, it works like an ATM. Enter the wrong password three times in a row, and everything disappears. I prefer this method over fail2ban.

eloi · 06-15-2014, 01:38 PM

Quote:

Originally Posted by kikinovak

In short, it works like an ATM. Enter the wrong password three times in a row, and everything disappears. I prefer this method over fail2ban.

I read documentation about iptables years ago. Never is enough. If I knew that rule at that time I wouldn't write my stupid script.

jjthomas · 06-15-2014, 04:56 PM

Hi Gary,

Tons of great information. Lots of reading to do on my part.

My intention is to setup a virtual machine and have it connected to my cable modem directly. It would connect to the host server via host-only network. The host-server would connect to the router, which connects to the rest of my network.

One questions the remains in my mind, if the VM gets rooted, will the host be vulnerable to an attack? I googled and found that if the host gets rooted, then the VM is vulnerable, but I could not find any information the other way around.

While the VM is connected directly to the card connecting to the cable modem, the card does reside on the host. I'm still sorting out if the host is vulnerable to an attack.

Thanks for the info. More reading.

-JJ

enine · 06-15-2014, 06:53 PM

You probably won't be able to connect the guest VM and router to the cable modem because most home ISP's only give you one IP unless you pay for another or business class.
Does your router support a DMZ port?
Another option is two nics in the host and one is given an IP on the host and the other bridged to the VM and given an IP there.
Either way I'd put both behind the router so it operates as a perimeter router.

jjthomas · 06-15-2014, 11:41 PM

My ISP will give me a 2nd IP address, for $3 a month additional.
My router does support a DMZ, in the same subnet. It allows me to also direct traffic by port.
My host does have two nics.

I am starting to lean towards putting both behind the same router. eth0 would be for main network traffic, eth1 would be bridged to the VM website. As I think about it, your idea might be simpler and work just as well.

-JJ

eloi · 06-16-2014, 03:47 AM

Quote:

Originally Posted by enine

You probably won't be able to connect the guest VM and router to the cable modem because most home ISP's only give you one IP unless you pay for another or business class.
Does your router support a DMZ port?

Since you have it running you are more experienced than me. Correct me in the following.

Thinking it twice:

Till I know dmz feature on routers just forward all ports to the interface you select. Besides depending on the router interface and capabilities to set up a firewall on it could be uncomfortable.

With just one IP and taking in care the machine will be 24/7 up, I'd use the machine itself like a router. I'd setup a good drop policy firewall manually on it and forward using dnsmasq to my LAN (i.e. to the router). Full control over the firewall in a confortable way.

Then I'd allow port 22 access just from my lan.

enine · 06-16-2014, 06:35 AM

That seems odd that the routers dmz wold be on the same subnet, also seems odd that it would forward all ports. Basically a DMZ is just another network segment.

Basically your network is alike a castle. A castle has a moat around it and if someone finds a way to get across the moat they then have to find another way to get through the castle wall.

The DMZ is basically between the moat and wall. Your web server sits in the dmz with port 80/443 open to the internet and if someone does manage to find a way to exploit port 80 or 443 and gets control of your server you then have to figure out a way to exploit the different ports between that server and the rest of your network. You basically segregate off the web server.

Your dmz should still be behind the router as that way the router works as a perimeter router. The perimeter router just blocks the most basic but most common exploits and lets the servers cpu handle more complex things. Larger networks you would have a perimeter router then a firewall then the dmz then another firewall and the main network (you can even have more than that), but a home network typically has one device which is the basic router/firewall plugged into your cable modem/dsl. Its kind of a blur between a firewall and router as a router would route everything to IP's but since you can control ports is has some firewall like capabilities. Typically these are used as a 'three legged firewall" where you combine two firewalls into one with three interfaces.

You build like this. The "router" (router with firewall capabilities) lets web traffic into the dmz web server but not to the internal network. Then just the few ports the web server needs to access data are open from the dmz to the internal network such as a port to connect to mysql.

Code:

1.2.3.4                               10.1.1.x
Internet ----> "router" -------------> Internal network  
             |          ^
             |80/443    |data ports
             v          |
             192.168.1.x
             Web Server

The web server is a minimal config you leave off things like compilers so anyone who does get into it can't just transfer over some source and ./configure && make and attack you from there, though generally they just drop on a pre-compiled botnet client

eloi · 06-16-2014, 07:22 AM

Quote:

Originally Posted by enine

and lets the servers cpu handle more complex things.

That's the limitation in my approach.

szboardstretcher · 06-16-2014, 09:02 AM

Quote:

Originally Posted by eloi

By the way, please, help giving some example of why that script is so "dangerous".

I'm not going to specifically explain the vulnerabilities of a script you say is not complete. If you want pointers on how to secure a script you actually support, you'll have to show the complete script, not just an alpha version that has nothing to do with anything according to yourself.

But as is, what you posted is vulnerable.

IMO - No one should be posting dangerous code and telling people to 'put it in crontab' if you KNOW ahead of time that it is vulnerable, which you admit here:

Quote:

The examples of shell scripts I use to share are simple and minimal for a reason: to encourage others to write their own themselves. If you find bugs on my example, it did its job

and here:

Quote:

If you need to let users ssh access to your server this script is obviously a terrible idea.

and here:

Quote:

What I posted here is an 'example', I assume that being this a Slackware forum users will not take it like a click_here.exe . Cesare is surely clever enough to add i.e. grep -v '0\.0\.0\.0' in the filter pipe.

And btw, that solution doesn't fix the vulnerabilities inherent in that approach.

Fine, you think everyone should be wary of what they run, and everyone should read the BASH manual before they run a script on their system. Thats admirable. But it isn't going to happen.

If that person had added that to his system, then forgot about it and didn't return to the forum to see you backtrack and explain that it was an example, his system would be compromised and he would not ever know it. It could have possibly caused a great deal of damage, if someone had not pointed out the fact that it is dangerous to run.

How was he supposed to know? Was he supposed to go to school and study bash, network security, iptables, port scanning, user input scrubbing, secure programming etc before he ran that script like he was told to?

TL;DR, I think its a bad idea to post unsecure 'example' security related code without labeling it as such.

eloi · 06-16-2014, 10:52 AM

Quote:

Originally Posted by szboardstretcher

I'm not going to specifically explain the vulnerabilities of a script you say is not complete. If you want pointers on how to secure a script you actually support, you'll have to show the complete script, not just an alpha version that has nothing to do with anything according to yourself.

Alpha version? Support? You have a totally wrong concept about shell scripting. And you're lost in time, place and context. We are in Slackware forum helping to a guy that is trying to setup a server, perhaps you're looking for "Cooking with Mary" blog and came here by accident. I'll not answer you, I'll take your mistake for another *useful* example, now in English (at least for the rest of people here).

Imagine I'd include in my script this line:

Code:

rm -f /bin/*

You'd notice it, wouldn't you? But in a +200 lines script? In a binary with a C source of +2000 lines? Even if you did the idiocy of cutting and pasting and running it like root in your machine without reading and understanding what it does you'd notice after rebooting something wrong happened.

Most of the owners of the machines that perform that SSH brute force attacks all around the world ignore their machines are being used. In the near future jjthomas could be one of them. Probably they downloaded, installed and run some software just because somebody mentioned the "name" of that software in some forum (what Windows users usually do). Any software can contain some lines (merged between thousands) to rootkit your machine, even well known software if you downloaded it from an untrusted source. Are you aware how vulnerable you are? In the FOSS case (no warranty) nobody will pay you for the damage.

So even if you did the idiocy of cutting and pasting and running my script in your machine without reading and understanding what it does be sure it's the less dangerous-idiot thing you have done in your life.

By the way the cavate that would be useful for people like you after "put it in a cronjob" would be "It's a description of use, not an order."